CVE-2026-83627: Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN <= 3.21.0 - Unauthenticated Remote Code Execution via Cookie Name in Page Cache Debug Log
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 logmsg() 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 classexists( 'Filesystem' ), which can never match because classexists() 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. getcookies() then writes the raw name of any cookie matching the wphbcache 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Hummingbird – Speed Optimization, Caching, Minify, Compress & CDNto a version that resolves this vulnerability.Fixed in 3.21.0 - Configuration
Ensure Page Caching Debug Log (non-default) is disabled so that the page-cache debug log (wp-content/wphb-logs/page-caching-log.php) is not created/updated during front-end requests.
Hummingbird page-cache debug logging Page Caching with Debug Log option = disable - Compensating control
Because wp-content/wphb-logs/page-caching-log.php is directly web-accessible, prevent direct web access to that path (e.g., via server configuration/deny rules/ACL/other web-tier control) until the plugin is upgraded.
- Operational
After disabling page-cache Debug Log and upgrading, clean up any potentially injected content by removing/resetting the existing file at wp-content/wphb-logs/page-caching-log.php and its log contents.
Event History
Frequently Asked Questions
Are sites using the plugin exposed by default?
No. Exploitation requires Page Caching and its Debug Log option to be enabled; this is a non-default configuration. The page-cache debug log must also be created during a front-end request.
What does an attacker need to exploit this issue?
An attacker needs only anonymous network access to the site once the required Page Caching and Debug Log configuration is enabled. They can supply a cookie name beginning with wphb_cache_ to place unsanitized PHP in the log, then request the directly web-accessible log file to execute it.
How can administrators determine whether their site is affected?
Check whether the plugin version is 3.21.0 or earlier and whether Page Caching with Debug Log is enabled. Also inspect for wp-content/wphb-logs/page-caching-log.php, particularly if it was generated by a front-end request.
What can be done if patching cannot happen immediately?
Disable the Page Caching Debug Log option, and disable Page Caching if necessary to ensure the vulnerable log is not generated. Remove or restrict direct web access to wp-content/wphb-logs/page-caching-log.php and review the file for unexpected PHP content.