CVE-2026-83627: Hummingbird WordPress Plugin RCE Vulnerability

CVE-2026-83627 Overview

CVE-2026-83627 is a remote code execution vulnerability in the Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN plugin for WordPress. All versions up to and including 3.21.0 are affected. The flaw resides in the log_msg() function within core/modules/class-page-cache.php, which writes the page-cache debug log to wp-content/wphb-logs/page-caching-log.php. A broken class_exists() guard prevents a <?php die(); ?> protective header from being written to that file, exposing it as a directly web-accessible PHP file that attackers can populate and execute.

Critical Impact
Unauthenticated attackers can write arbitrary PHP code into a web-accessible log file with a single anonymous request and execute it, achieving full remote code execution on the target WordPress site.

Affected Products

Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN plugin for WordPress
All versions up to and including 3.21.0
Sites with Page Caching enabled together with the Debug Log option

Discovery Timeline

2026-09-05 - CVE-2026-83627 published to the National Vulnerability Database (NVD)
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-83627

Vulnerability Analysis

The Hummingbird plugin writes page-cache debug entries to wp-content/wphb-logs/page-caching-log.php. Because the file ends in .php and is stored under wp-content, it is directly reachable through the web server. To neutralize direct execution, the plugin is designed to prepend a <?php die(); ?> header at file creation.

The protective header is only written when class_exists( 'Filesystem' ) evaluates true. This check fails at runtime because class_exists() resolves unqualified string names against the global namespace, while the actual class is Hummingbird\Core\Filesystem. When the log file is created during a front-end request, the header is silently omitted, leaving a writable and executable PHP file in the web root.

The get_cookies() routine then writes the raw name of any cookie whose name starts with the wphb_cache_ prefix directly into the log file without sanitization. An attacker who sends a request containing a cookie name crafted as PHP code writes that payload into the log and can then request the log URL to execute it. This is a classic code injection flaw tracked under CWE-94.

Root Cause

The root cause is an incorrect namespace reference in a security-critical guard. The plugin queries class_exists( 'Filesystem' ) rather than the fully qualified Hummingbird\Core\Filesystem, so the branch responsible for writing the <?php die(); ?> header never executes. Compounding this, cookie names are written to a .php file without input validation, output encoding, or a .htaccess deny rule.

Attack Vector

Exploitation is unauthenticated and network-based. The attacker only needs the site administrator to have enabled Page Caching with the Debug Log option, and the log file to be created during a front-end request. That state is reached by the plugin's own Clear logs action, any cache flush, or unattended via the daily log-rotation cron, which can strip the protective header from an existing log file. The attacker then issues a normal HTTP request with a Cookie: header containing a PHP payload as the cookie name, followed by a request to /wp-content/wphb-logs/page-caching-log.php to trigger execution.

See the Wordfence Vulnerability Report ID 65c3ca36 and the vendor's changeset 3675836 for the corrected logic.

Detection Methods for CVE-2026-83627

Indicators of Compromise

Presence of wp-content/wphb-logs/page-caching-log.php without a leading <?php die(); ?> header.
Log file entries containing PHP tags, function calls, or base64 payloads embedded within cookie-name fields.
HTTP requests to /wp-content/wphb-logs/page-caching-log.php originating from unexpected IP ranges.
Inbound requests with malformed or unusually long Cookie: header names beginning with wphb_cache_.

Detection Strategies

Inspect the first bytes of every page-caching-log.php file on managed WordPress hosts; flag any file that does not begin with <?php die(); ?>.
Monitor web server access logs for GET requests to any file under /wp-content/wphb-logs/.
Alert on WordPress plugin inventories showing Hummingbird versions at or below 3.21.0 with Page Caching Debug Log enabled.

Monitoring Recommendations

Enable file integrity monitoring on wp-content/wphb-logs/ and on newly created .php files anywhere under wp-content/.
Forward WordPress and web server telemetry into a centralized data lake so that suspicious log-file writes and subsequent direct requests can be correlated.
Track outbound network connections from the PHP process for reverse shells or webshell staging behavior consistent with post-exploitation.

How to Mitigate CVE-2026-83627

Immediate Actions Required

Upgrade the Hummingbird plugin to version 3.21.2 or later on every WordPress site in the estate.
Disable the Page Caching Debug Log option until the upgrade is completed.
Delete any existing wp-content/wphb-logs/page-caching-log.php file and audit it for injected PHP before removal.
Rotate WordPress administrator credentials and secret keys on any host where compromise cannot be ruled out.

Patch Information

The vendor fixed the issue in Hummingbird 3.21.2. The corrected code uses the fully qualified class reference so the <?php die(); ?> header is reliably written at log-file creation, and it sanitizes cookie names before they are recorded. Review the diff between 3.20.0 and 3.21.2 and the vulnerable functions at class-page-cache.php lines 749 and 1973.

Workarounds

Block direct web access to /wp-content/wphb-logs/ at the web server or WAF layer until the plugin is upgraded.
Turn off the Page Caching Debug Log setting to prevent creation of the vulnerable log file.
Set the wp-content/wphb-logs/ directory to read-only for the PHP worker if operationally feasible.

bash

# Apache: deny direct access to the Hummingbird log directory
<Directory "/var/www/html/wp-content/wphb-logs">
    Require all denied
</Directory>

# Nginx: return 403 for any request under the log directory
location ^~ /wp-content/wphb-logs/ {
    deny all;
    return 403;
}