Hummingbird

CVE-2026-83627 affects Hummingbird <= 3.21.0. Wordfence reports an unauthenticated remote code execution issue through cookie-name handling in the page cache debug log. Update to 3.21.2 or newer, clear cache files, and review logs.

CVE-2026-83627 is a newly published unauthenticated remote code execution vulnerability in Hummingbird Performance, the WPMU DEV caching and performance plugin for WordPress. The issue affects Hummingbird versions up to and including 3.21.0.

Hummingbird has 70,000+ active installations on WordPress.org. The current WordPress.org changelog lists Hummingbird 3.21.2 with security hardening, so administrators should update to 3.21.2 or newer and clear generated cache files after the update.

Table of Contents

Vulnerability summary

Plugin: Hummingbird Performance – Cache & Page Speed Optimization
Slug: hummingbird-performance
CVE: CVE-2026-83627
Affected versions: Hummingbird <= 3.21.0
Fixed version: 3.21.2 or newer
Severity: critical remote code execution according to the Wordfence Intelligence record
Attack class: unauthenticated remote code execution through unsafe cookie-name handling in the page cache debug log
Required privilege: none
Likely exposed component: Hummingbird page cache and debug-log handling
CISA KEV: not listed at publication time

Technical cause

The Wordfence Intelligence record describes the vulnerable path as remote code execution via the cookie name written through Hummingbird’s page cache debug log. In practical terms, the risky boundary is any code path that records attacker-controlled request metadata into generated cache/debug output without treating it as untrusted input.

For this class of caching bug, exploitation impact depends on where the generated cache/debug file is written, whether the file can be requested directly, and whether the server interprets that file as executable PHP. Do not rely only on normal WordPress access controls: generated cache files often sit below wp-content and are served directly by the web server.

Immediate remediation

Update Hummingbird to 3.21.2 or newer.
Clear all Hummingbird page cache files after updating.
Temporarily disable Hummingbird page caching and any debug logging if the update cannot be applied immediately.
Confirm that PHP execution is blocked under cache and upload directories.
Search for recently modified PHP files under wp-content, especially cache directories.
Review access logs for unusual requests with abnormal cookie names or repeated cache/debug probes.

WP-CLI checks

Use the WordPress.org slug when checking the installed version:

wp plugin get hummingbird-performance --fields=name,version,status
wp plugin update hummingbird-performance
wp plugin get hummingbird-performance --field=version
wp cache flush

If your host or plugin stack does not expose Hummingbird updates through WP-CLI, update through WordPress admin or WPMU DEV Hub, then re-run the version check.

File-system checks

Search for recently changed executable files below wp-content. Review every result manually before deletion:

find wp-content -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -mtime -14 -print
find wp-content -type f -path '*cache*' -mtime -14 -print
wp core verify-checksums
wp plugin verify-checksums --all

Unexpected PHP files in cache directories should be treated as high-risk. Preserve copies and logs first if the site is under incident response.

Log review

Look for request bursts around Hummingbird cache paths and unusual cookie metadata. These patterns are for defensive review and should be correlated with timestamps and file modification times:

grep -Ei 'hummingbird|wphb|cache|Cookie:' /var/log/nginx/access.log*
grep -Ei 'hummingbird|wphb|cache|Cookie:' /var/log/apache2/access.log*

Temporary mitigation

The correct fix is to update. If patching is delayed, disable Hummingbird page caching and cache debug logging, then purge existing cache files. At the web-server layer, prevent executable files from running below cache and upload directories.

For NGINX, use a deny rule like this after adjusting paths for your site and testing with nginx -t:

location ~* ^/wp-content/(cache|uploads)/.*\.(php|phtml|phar|shtml)$ {
    deny all;
    return 403;
}

For Apache, place an execution deny rule in writable content directories where overrides are honored:

<FilesMatch "\.(php|phtml|phar|shtml)$">
    Require all denied
</FilesMatch>