HTTP2Shell: What CVE-2026-111497 Means for WordPress Hosts, and What to Do Now

HTTP2Shell (also Node2Shell / Brotli2Shell) is Google’s CVE-2026-111497: an out-of-bounds write in the Brotli decoder. Google’s CNA scores it 9.2 critical (CVSS 4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H). CWE CWE-252 and CWE-787. Upstream floors: 1.0.10, 1.1.1, 1.2.1. The 1.2.1 tag is dated 21 October 2026. Despite the nickname, this is not an HTTP/2 bug.[1][2]

CISA added it to KEV on 27 October 2026. dueDate 2026-11-10. knownRansomwareCampaignUse: Unknown. The catalog names Google / Brotli, not WordPress.[9]

On 2 November 2026 Wordfence published that they reproduced unauthenticated remote code execution through WordPress in an isolated lab, via XML-RPC pingback.ping. That is the operator news this week: the decoder is a hosting-stack library, and a stock WordPress feature can feed it attacker-controlled compressed data.[4]

What it is

This is a bug in Brotli’s C decoder, not in WordPress core, not in a plugin, and not in PHP2Shell. A crafted Brotli stream can write past the decoder’s buffer. If a network-facing process decompresses that stream, the result can be a crash, a memory leak, or code execution as that process.[1][4]

WordPress is one delivery path, not the product. Wordfence’s demonstrated route:[4]

An unauthenticated request hits xmlrpc.php and calls pingback.ping with an attacker-controlled source URL.
WordPress fetches that URL to check the link.
The attacker’s server returns a Brotli-compressed body.
If the HTTP client’s decoder is the vulnerable library and the payload matches that PHP/OS image, Wordfence says the PHP process runs attacker code.

xmlrpc.php is this PoC’s trigger, not a requirement of the CVE. Node.js fetch(), inbound Content-Encoding: br on some servers, and other clients that auto-decode Brotli are in the same class. Wordfence’s scoped review of stock WordPress core found pingback.ping as the clear unauthenticated URL-fetch route; other core fetchers needed login or extra privileges. Plugins can add more routes. We did not run the PoC.[4]

How serious is it?

A 9.2 with PR:N and high impact is Google scoring no login on the decoder. The AT:P (attack requires present conditions) is the hedge: attacker-controlled compressed data has to reach a vulnerable decoder.[1]

CISA listing it as known exploited is a separate fact from “WordPress sites are falling over.” CISA’s public row does not name an application, route, or victim. Wordfence, through 2 November, found no independently reviewable public report of a successful production compromise or a compromise through the WordPress XML-RPC path. Sensor vendors report attempts. Treat KEV as “patch now,” not as “your WP box is already owned.”[4][9]

Wordfence’s own lab: the public payload did execute on WordPress 7.1.3, Debian 13.7, Apache 2.4.69, PHP 8.3.36 mod_php, vulnerable libbrotli1 1.1.0-2+b7, ASLR on. The same payload did not execute on PHP 8.3.35; in one vulnerable setup it crashed the worker instead. After they updated only Brotli, it stopped. That is Wordfence’s test, not ours. It means the current public request is not universal, and it also means a matching image (shared hosting templates, official Docker tags) is the realistic mass target.[4]

Who is affected

In scope until the running process loads a fixed decoder:

Any host with Brotli 1.0.3 through 1.2.0 that decompresses untrusted input (PHP curl with encoding, Node, Python, Envoy, containers).[1][2]
WordPress sites where XML-RPC pingbacks still work and the PHP HTTP stack uses a vulnerable libbrotli. Updating WordPress / plugins / themes does not replace that library.[4]
Shared hosting: several copies. CloudLinux documents at least: system brotli/libbrotli, EasyApache ea-brotli, and alt-php pecl-brotli (statically bundled inside brotli.so). Patching one does not patch the others. Apache mod_brotli compresses outbound; CloudLinux says it does not use the vulnerable decoder. The decoder on EA-PHP is reached through curl when CURLOPT_ENCODING is set.[7]

Vendor floors we can cite (check the full NVR, not 1.1.0):

Debian bookworm: 1.0.9-2+deb12u1. Trixie: 1.1.0-2+deb13u1. Unstable: 1.2.0-4.1. Debian still lists nodejs as vulnerable on bookworm/trixie security at the tracker dump we pulled; they note nodejs uses the system library.[5]
Ubuntu: jammy 1.0.9-2ubuntu0.1, noble 1.1.0-2ubuntu0.1, 26.04 1.2.0-3ubuntu0.1, 26.10 1.2.0-4ubuntu0.1 (libbrotli1 / brotli / python3-brotli, USN-8956-1).[6]
CloudLinux 7 / CentOS 7 ELS: brotli-1.0.9-10.el7.tuxcare.els1. ea-brotli-1.0.10-1 on EA4 stable for CL7. alt-php70-85 pecl-brotli 0.21.1-1 (CL7 still in updates-testing when we read the article). CL8/9 pecl-brotli not published yet on that page; watch 0.21.1. alt-php53-brotli-0.5.0 bundles 1.0.1 and is out of the CVE range (vulnerable code starts at 1.0.3).[7]

Out of scope unless you have a second advisory: sites whose every Brotli copy is already the vendor-fixed revision and every worker was restarted or the container rebuilt.

What to do now

The patch is the library. WordPress 7.1.4 does not fix this.

Inventory every Brotli. System package, EA, alt-php pecl, Node, containers, anything that ships libbrotli.

rpm -q brotli libbrotli ea-brotli 2>/dev/null
rpm -qa 'alt-php*-pecl-brotli' 'alt-php53-brotli'
dpkg -l 'libbrotli1' 'brotli' 2>/dev/null
rpm -qa 'ea-php*-php-curl'

Patch the copies you actually run. Compare changelog / full NVR to the vendor notice, not 1.1.0 vs 1.1.1.

# CloudLinux 7 / cPanel EA4 (vendor commands)
yum update brotli libbrotli
yum update ea-brotli
rpm -q --changelog ea-brotli | grep CVE-2026-111497
# expected line: EA-13438: Update ea-brotli from v1.0.9 to v1.0.10 (CVE-2026-111497)

# Ubuntu
apt-get update && apt-get install --only-upgrade libbrotli1 brotli

Restart the process that loaded the old .so. Package install is not enough. PHP-FPM, Apache, LiteSpeed lsphp, Node. Containers: rebuild and redeploy; a restart of the old image keeps the old files.[4][7]

# cPanel
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
# LiteSpeed: restart is not always enough for lsphp
/usr/local/lsws/bin/lswsctrl restart
pkill lsphp

Do not treat XML-RPC toggles as the fix. WordPress’s xmlrpc_enabled filter disables authenticated XML-RPC methods only; it does not disable pingback.ping. Wordfence’s “Disable XML-RPC authentication” option has the same gap. Turning pingbacks off may shrink this WordPress route (and can break legitimate pings). It does not patch Brotli, and it does not cover Node or other clients on the same box.[4][8]
Keep logs. If you patched late, look for unusual xmlrpc.php pingbacks, outbound fetches, PHP/worker crashes. Those signs are not proof. Their absence is not a clean bill of health.[4]

Versions with no clean vendor floor

CloudLinux 8/9 alt-php pecl-brotli: CloudLinux said the 0.21.1 builds were not published when we read the article. Until they are, they tell you to disable the brotli extension in PHP Selector if the sites do not need it. Output compression is not the decoder path; brotli_uncompress() / compress.brotli:// is.[7]
Debian nodejs on older releases: tracker still showed vulnerable node packages that use system brotli - so the system brotli security update is the one that matters there, plus a Node restart.[5]
Anything bundling its own 1.0.3-1.2.0: Envoy, Bun, language wheels, vendor appliances. Ask the vendor. A host yum update brotli will not touch a static copy inside a binary.

How to spot a compromise

Wordfence listed: unexpected XML-RPC pingback traffic, odd outbound connections from the web user, PHP or httpd crashes/restarts. None of those alone proves CVE-2026-111497. If you do find a foothold, isolate first and keep logs before cleanup. We are not publishing exploit steps.[4]

FAQ

Is there a patch? Yes. Upstream 21 Oct 2026: 1.0.10 / 1.1.1 / 1.2.1. Distros backport; read the full package revision.[2][5][6]

Does a WordPress update fix it? No. The decoder is outside WordPress.[4]

Is it exploited? CISA says known exploited as of 27 Oct, without naming WordPress. Wordfence as of 2 Nov: attempts, lab RCE, no public production WP compromise they could independently review. We did not scan the fleet.[4][9]

Does disabling XML-RPC save me? Only maybe this one WordPress trigger, and only if you actually disable pingbacks (not just xmlrpc_enabled). Patch Brotli anyway.[4][8]

Honesty

We did not exploit this and did not replay anyone’s PoC.
Lab RCE on a pinned Debian/PHP image is Wordfence’s result.
CISA KEV does not say the exploited product was WordPress.
CloudLinux 8/9 pecl-brotli availability is as of their article, not a live dnf we ran on your box.
Confirm the library the running worker has mapped, not only rpm -q on a package that another SAPI does not use.

Sources

[1] https://www.cve.org/CVERecord?id=CVE-2026-111497 - Google CNA, CVSS 9.2
[2] https://github.com/google/brotli/releases/tag/v1.2.1 - upstream 1.2.1, 21 Oct 2026
[3] https://www.cisa.gov/known-exploited-vulnerabilities-catalog - KEV catalog
[4] https://www.wordfence.com/blog/2026/11/http2shell-wordpress-brotli/ - Wordfence, 2 Nov 2026
[5] https://security-tracker.debian.org/tracker/CVE-2026-111497 - Debian package table
[6] https://ubuntu.com/security/notices/USN-8956-1 - Ubuntu libbrotli1 floors
[7] https://cloudlinux.zendesk.com/hc/en-us/articles/31345594031132-Brotli-CVE-2026-111497-on-CloudLinux-OS-affected-packages-and-fixed-versions - CloudLinux copies
[8] https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/ - pingbacks still on
[9] https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CVE-2026-111497 row (dateAdded 2026-10-27, dueDate 2026-11-10)