Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-05T06:17:10.080Z",
  "pubdate": "2026-09-05T06:17:10.080Z",
  "executiveSummary": "The Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN WordPress plugin contains a critical Remote Code Execution (RCE) vulnerability in versions up to and including 3.21.0.\nThe flaw originates from an improper implementation of the debug log generation mechanism within core/modules/class-page-cache.php, which fails to securely inject protective headers into the log file.\nBy manipulating cookies with the wphb_cache_ prefix, an unauthenticated attacker can inject arbitrary PHP code into the web-accessible file wp-content/wphb-logs/page-caching-log.php.\nSuccessful exploitation allows for complete site compromise through the execution of malicious scripts. The vulnerability requires the Page Caching and Debug Log options to be enabled by an administrator, which may occur automatically via plugin maintenance tasks such as log rotation or cache flushing.\nThe risk is severe as it provides unauthenticated attackers with full code execution capabilities, potentially leading to unauthorized data access, site defacement, or persistent backdoors.",
  "technicalDetails": "The root cause of the vulnerability lies in the log_msg() function within core/modules/class-page-cache.php. The plugin attempts to protect the log file wp-content/wphb-logs/page-caching-log.php by prepending a '<?php die(); ?>' header to prevent direct PHP execution. However, the logic used to verify this protection relies on class_exists( 'Filesystem' ).\nThis check fails consistently because the class exists in the Hummingbird\\Core namespace rather than the global namespace, causing the check to evaluate to false. Consequently, when the log is generated or recreated—such as during a front-end request triggered by cache flushes or cron-based log rotation—the protective header is omitted from the file.\nThe attack flow leverages the get_cookies() function, which reads and writes the raw contents of cookies prefixed with 'wphb_cache_' directly into the log file. Because this input is not sanitized, an attacker can craft a malicious HTTP request containing a cookie value structured as PHP code (e.g., '<?php system($_GET['cmd']); ?>').\nWhen the plugin processes this request, it writes the malicious cookie string into the log file without the die() statement, effectively turning the log file into a web-accessible shell. The attacker then executes the injected code by sending a direct HTTP request to the location of the log file at wp-content/wphb-logs/page-caching-log.php.\nThis vulnerability is classified as critical because it requires no authentication or special privileges, provided the site administrator has enabled the debug log feature. The attack can be automated or performed via a single anonymous web request. Once executed, the impact includes full remote code execution, allowing the attacker to interact with the server environment, access sensitive configuration files like wp-config.php, or manipulate the database.\nThe exposure is strictly dependent on the existence of the log file and the lack of proper namespace resolution in the plugin's security checks. Once the log file is created in a vulnerable state, it remains a permanent point of entry for the attacker until the log is rotated or the malicious content is manually purged, though subsequent log generation requests can re-trigger the vulnerability."
}