CVE-2026-83627 in Hummingbird Performance Plugin
Summary
by MITRE • 09/05/2026
The Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 3.21.0 via the log_msg() function in core/modules/class-page-cache.php. The page-cache debug log is written to wp-content/wphb-logs/page-caching-log.php, a directly web-accessible PHP file that is supposed to be protected by a leading '<?php die(); ?>' header. That header is guarded by class_exists( 'Filesystem' ), which can never match because class_exists() resolves string arguments in the global namespace while the class is Hummingbird\Core\Filesystem; when the log is created during a front-end request the header is therefore omitted entirely. get_cookies() then writes the raw name of any cookie matching the wphb_cache_ prefix into that file without sanitization. This makes it possible for unauthenticated attackers to write arbitrary PHP into the log file with a single anonymous request and execute it by requesting the file directly, resulting in full remote code execution. Exploitation requires the site administrator to have enabled Page Caching with the Debug Log option (non-default), and the log file to be created during a front-end request — a state reached by the plugin's own 'Clear logs' action, any cache flush, or unattended via the plugin's daily log-rotation cron, which can strip the protective header from an existing log file.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified in Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN for WordPress represents a critical Remote Code Execution flaw affecting all versions up to and including 3.21.0. This security issue stems from improper input validation and insecure file handling within the plugin's core caching module. Specifically, the vulnerability resides in the log_msg() function located in the class-page-cache.php file. The root cause is a fundamental misunderstanding of PHP namespace resolution combined with insufficient sanitization of user-supplied data before writing it to a web-accessible location. This combination allows an unauthenticated attacker to inject arbitrary PHP code into the server, leading to complete compromise of the underlying system.
The technical mechanism of exploitation relies on a flawed security control intended to protect debug logs from direct execution. The plugin attempts to write page cache debug information to wp-content/wphb-logs/page-caching-log.php, which is directly accessible via HTTP requests. To prevent this file from being executed as PHP code by the web server, the developers implemented a protective header consisting of '<?php die(); ?>'. However, this safeguard was conditionally applied based on the existence of a class named 'Filesystem' using the function class_exists( 'Filesystem' ). In modern WordPress plugin development, classes are typically organized within namespaces. The actual class in question is Hummingbird\Core\Filesystem. Because PHP's class_exists() function resolves string arguments against the global namespace by default unless explicitly told otherwise, it fails to find a globally defined class named Filesystem. Consequently, the condition evaluates to false, and the protective die header is omitted entirely when the log file is created during front-end requests.
With the protective barrier removed, the vulnerability escalates through improper data handling in the get_cookies() function. This routine iterates over cookies sent by clients and writes their names into the aforementioned log file if they match a specific prefix pattern (wphb_cache_). Crucially, this process occurs without any sanitization or encoding of the cookie values. Since HTTP headers are under the control of the client, an attacker can craft a request containing a maliciously named cookie that includes valid PHP code as its name value. When the plugin processes this request and writes to the log file due to the missing die header, it effectively executes a write operation containing arbitrary PHP commands directly into a web-accessible script.
The operational impact of this vulnerability is severe, resulting in full Remote Code Execution with no authentication required. An attacker can simply send a single HTTP request with a specially crafted cookie to trigger the log writing process. Once the malicious code is written to page-caching-log.php, the attacker requests that file via its URL path. The web server interprets the content as PHP and executes it immediately. This grants the attacker the same privileges as the web server user, allowing them to read sensitive configuration files, exfiltrate database credentials, install backdoors, or pivot further into the internal network. This level of access effectively compromises the entire WordPress installation and potentially the host system depending on the server's security posture.
Exploitation is not universal across all configurations but requires specific conditions to be met. The site administrator must have enabled Page Caching with the Debug Log option active, which is a non-default setting in most installations. Furthermore, the log file must exist or be created during a front-end request. While new files might initially lack the protective header due to the namespace bug, existing logs can also become vulnerable through routine maintenance operations. The plugin includes a 'Clear logs' action and performs daily log rotation via cron jobs. These processes often involve deleting old logs and creating fresh ones without properly re-applying security headers if the underlying code logic remains flawed during file initialization. This means that even if an administrator clears logs to manage disk space, they inadvertently create new vulnerable files that remain exposed to exploitation until the plugin is updated or patched.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor if sensitive data were logged, though the primary impact here is code injection leading to RCE. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1505.003 Web Shell: CMS Plugin/Component and potentially T1059 Command and Scripting Interpreter for the execution phase. The lack of input validation on cookie names represents a classic failure in secure coding practices where user-controlled data is treated as trusted code context without proper escaping or encoding.
Mitigation strategies must address both immediate remediation and long-term security hygiene. Administrators should immediately update the Hummingbird plugin to version 3.21.1 or later, which resolves the namespace resolution issue and ensures the protective die header is correctly applied regardless of class existence checks. Until an update can be deployed, administrators who have enabled debug logging for page caching should manually delete the wp-content/wphb-logs/page-caching-log.php file if it exists, as its presence poses a direct risk. Additionally, disabling the Debug Log option in the plugin settings removes the attack vector entirely by preventing the writing of these specific logs to web-accessible locations. Server-level controls such as Web Application Firewalls can also be configured to block requests containing PHP code snippets within cookie headers or URL parameters, providing an additional layer of defense against exploitation attempts targeting this and similar vulnerabilities.