Skip to content

WordPress News

Patchstack warns WordPress sites can hit Brotli decoder flaw

Patchstack says WordPress can still reach a Brotli decoder flaw through outbound requests, including unauthenticated pingbacks on many sites.

Source Patchstack (opens in a new tab)
Abstract browser windows and document cards linked to a shield with subtle cracks, gears and server shapes in background.
Illustration for this article. Generated by AI.

Patchstack reported on October 30, 2026 that WordPress sites can still be exposed to CVE-2026-111497 even though WordPress does not include Brotli itself. According to Patchstack, the risk comes from how WordPress makes outbound requests through libcurl and the operating system’s Brotli library.

The report says one unauthenticated POST to xmlrpc.php can crash a PHP worker on a default WordPress install. In the described path, an attacker sends a pingback request, WordPress fetches a source URL controlled by the attacker, and libcurl decompresses a Brotli response before WordPress processes it.

What changed

The issue is tied to CVE-2026-111497, an out-of-bounds write in Google’s Brotli decoder. Patchstack says the flaw affects Brotli 1.0.3 through 1.2.0, was fixed on October 21, 2026 in 1.0.10, 1.1.1, and 1.2.1, and was later added by CISA to its Known Exploited Vulnerabilities catalog.

Patchstack says WordPress is exposed because every outbound request goes through its HTTP stack and cURL transport, which asks libcurl to accept and unpack supported compression types automatically. That means there may be nothing to update inside WordPress itself. The report also says the payload is not visible in the incoming request, because the harmful data comes back from the attacker’s server in the response.

What it means for your website

For site owners, the main short-term concern is downtime. Patchstack says a single request can kill a worker, and repeated requests can keep a site down. The report notes that public WordPress-related tooling currently stops at crashing the worker, while code execution has not been established for this path.

This matters even if you do not use pingbacks. Patchstack says the same decoder path can also be reached when plugins or themes fetch user-supplied URLs server-side, and through some oEmbed and feed requests. It also says a typical web application firewall cannot reliably identify the attack from the inbound request alone, because the dangerous content arrives later in the outbound response.

What to do now

  • Check whether your server’s Brotli package has the security fix. Patchstack says updating Brotli, or taking your distribution’s security update for libbrotli1, is the only change that fixes the vulnerable code.
  • Do not assume XML-RPC is fully disabled. Patchstack says the common xmlrpc_enabled filter does not block pingback.ping, because pingback does not require a login.
  • If you cannot update yet, remove the pingback methods or block xmlrpc.php at the web server. Patchstack says this closes the easiest unauthenticated route, but not every possible path.
  • Review plugins and themes that fetch visitor-supplied URLs on the server side, such as link preview, importer, webhook, avatar proxy, oEmbed, or feed-related features. Patchstack says those paths can still reach the same decoder.
  • If you need a temporary mitigation while arranging the real update, Patchstack says changing cURL behavior so WordPress does not auto-decompress responses can cut off the decoder path more broadly.