WPMU DEV Hummingbird Performance Plugin up to 3.21.0 on WordPress Page Cache class-page-cache.php log_msg code injection

Summaryinfo

A vulnerability was found in WPMU DEV Hummingbird Performance Plugin up to 3.21.0. It has been rated as critical. Impacted is the function log_msg of the file core/modules/class-page-cache.php of the component Page Cache. This manipulation causes code injection. This vulnerability is tracked as CVE-2026-83627. The attack is possible to be carried out remotely. No exploit exists.

Detailsinfo

A vulnerability has been found in WPMU DEV Hummingbird Performance Plugin up to 3.21.0 and classified as critical. Affected by this vulnerability is the function log_msg of the file core/modules/class-page-cache.php of the component Page Cache. The manipulation with an unknown input leads to a code injection vulnerability. The CWE definition for the vulnerability is CWE-94. The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at wordfence.com. This vulnerability is known as CVE-2026-83627 since 08/31/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/05/2026). MITRE ATT&CK project uses the attack technique T1059 for this issue.

By approaching the search of inurl:core/modules/class-page-cache.php it is possible to find vulnerable targets with Google Hacking.

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• WordPress Plugin

Vendor

• WPMU DEV

Name

• Hummingbird Performance Plugin

Version

• 3.0
• 3.1
• 3.2
• 3.3
• 3.4
• 3.5
• 3.6
• 3.7
• 3.8
• 3.9
• 3.10
• 3.11
• 3.12
• 3.13
• 3.14
• 3.15
• 3.16
• 3.17
• 3.18
• 3.19
• 3.20
• 3.21.0

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion