Critical Unauthenticated RCE in Hummingbird WordPress Plugin

Executive Summary

A critical unauthenticated code injection vulnerability (CVE-2026-83627, CVSS 9.8) has been disclosed in Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN, a widely used WordPress performance plugin from WPMU DEV. The flaw affects all versions up to and including 3.21.0 and stems from the log_msg() function in core/modules/class-page-cache.php, which writes attacker-controlled cookie data into a debug log that is directly reachable over HTTP.

CVSS Score: 9.8 (Critical)

Because the file that's supposed to protect that log never gets its safety header written, an attacker who merely sets a crafted cookie can plant PHP code that executes the moment the log file is requested in a browser — no login, no plugin configuration changes, no user interaction.

Vulnerability Overview

How the Bug Works

Hummingbird's page-cache module writes a debug log to wp-content/wphb-logs/page-caching-log.php. That path lives inside the public web root, so it's supposed to be neutralized by a leading <?php die(); ?> guard header written before any log content.

The guard is only written when class_exists('Filesystem') returns true — but the actual class is namespaced as Hummingbird\Core\Filesystem. class_exists() resolves bare string arguments against the global namespace, so the check can never match. On a normal front-end request, the guard header is silently skipped and the log file is created without it.

From there, get_cookies() writes the raw name of any cookie prefixed wphb_cache_ straight into that now-unprotected file, with no sanitization:

1. Attacker sends a request to any page on the target WordPress site
2. Attacker sets a cookie named wphb_cache_<malicious PHP payload>
3. Hummingbird's page-cache logger writes the cookie name verbatim into
   wp-content/wphb-logs/page-caching-log.php
4. Because the die() guard was never written, the file is plain executable PHP
5. Attacker requests the log file's URL directly — the payload executes
6. Full remote code execution as the web server user

This is functionally a log-poisoning-to-RCE chain, but it requires no authentication and no unusual plugin configuration — only that the plugin's page caching be active, which it is by default.

Impact of Successful Exploitation

Immediate Remediation

Step 1: Update to 3.21.1 or Later

# Via WP-CLI
wp plugin update wp-hummingbird
 
# Verify the installed version
wp plugin get wp-hummingbird --field=version

Or via WordPress admin: Plugins > Installed Plugins > Hummingbird > Update Now.

Step 2: Check for Existing Compromise

# Inspect the page-cache log for suspicious cookie-derived filenames
cat wp-content/wphb-logs/page-caching-log.php
 
# Confirm the die() guard is present at the top of the file
head -n 1 wp-content/wphb-logs/page-caching-log.php
 
# Search for recently modified PHP files outside expected paths
find wp-content/ -name "*.php" -newer wp-includes/version.php -type f

If Immediate Patching Is Not Possible

1. Block direct HTTP access to wp-content/wphb-logs/ at the web server level (deny-all rule for that directory)
2. Disable Hummingbird's page caching module until patched
3. Monitor access logs for requests to page-caching-log.php

Post-Remediation Steps

1. Confirm the plugin is updated to 3.21.1 or later
2. Delete any existing wp-content/wphb-logs/page-caching-log.php and let the plugin regenerate it
3. Review recently created admin accounts and file modifications
4. Rotate WordPress secret keys with wp config shuffle-salts
5. Deploy a WAF rule blocking direct access to wphb-logs/

References

• NIST NVD — CVE-2026-83627
• OffSeq Threat Radar — CVE-2026-83627 Analysis

Related Reading

• Critical RCE in WPvivid Backup Plugin Threatens 900,000+
• WordPress Plugin Vulnerability (CVSS 10.0) Under Active