Two critical vulnerabilities dominated our security work this week. Both can be exploited against a WordPress site without logging in, and both landed on CISA's Known Exploited Vulnerabilities (KEV) list, the US government's catalog of flaws confirmed to be under attack in the real world.

A compression bug that reaches WordPress from the outside

CVE-2026-111497 is a memory corruption flaw in Brotli, a compression library used almost everywhere on the modern web, rated 9.2 out of 10 in severity. A compression bug sounds harmless until you ask who does the decompressing. When a WordPress site fetches a remote page (for example to verify a pingback, a comment notification feature that anyone on the internet can trigger), it decodes whatever compression the remote server replies with. A malicious server can answer with a booby-trapped Brotli response and run its own code on the site. A public proof of concept circulated quickly, and CISA added the flaw to the KEV list on October 27.

Ubuntu shipped the fixed library in USN-8956-1. We checked every Linux host we maintain and confirmed all of them were on the fixed version, mostly via automatic security updates that we then verified rather than assumed. One subtlety matters here: a library update protects nothing until the programs using it restart, so we also confirmed that no running process still had the old copy of the library in memory. Most of the WordPress sites we maintain already refuse XML-RPC (the remote access endpoint the public exploit goes through). On the few legacy systems whose operating system no longer receives fixes, we checked whether the vulnerable path was reachable at all, and where it was, we turned off just the pingback method with a single-file, instantly reversible change instead of breaking the whole XML-RPC interface, which some mobile apps and backup tools use legitimately.

PHP execution in WordPress's update scratch directory

CVE-2026-119977 abuses wp-content/upgrade, the temporary folder WordPress uses while installing plugin, theme, and core updates. The flaw lets an attacker plant a PHP file there during an update and then run it by requesting it directly. This one was not theoretical for us: our logs show at least five different IP addresses probing exactly this path across sites we maintain, including one failed exploitation attempt.

Nothing legitimate ever needs the web server to execute PHP out of that folder, so the durable fix is a deny rule in the web server itself. We rolled that rule out to every WordPress host we maintain, five hosts running a mix of nginx and Apache, with configuration backups and a tested rollback, then verified from the outside that every site now returns "403 Forbidden" for PHP under that path while serving pages normally. The rollout finished a day ahead of the November 6 remediation deadline CISA set for US federal agencies, which we treat as a sensible deadline for everyone else too.

If you run WordPress, check three things

• Patch Brotli and restart. On Ubuntu, make sure libbrotli1 is at the version from USN-8956-1 (or newer), then restart long-running services, PHP included, so nothing keeps the old library loaded.
• Close XML-RPC if you do not use it. If nothing you rely on needs xmlrpc.php, block it at the web server. If you do need it, disabling just the pingback method removes the route this exploit uses.
• Deny PHP execution under wp-content/upgrade. It is a one-line rule in nginx or Apache, it breaks nothing, and scanners are actively looking for sites without it.

If your site lives on a managed WordPress platform, operating system patching is your vendor's job, but the XML-RPC and upgrade-directory rules are still worth asking them about.