A reader who looks after forty-odd client installs wrote me yesterday: the new WordPress advisory lists so many preconditions that he was tempted to file it under later. I get the instinct. I also think it points the wrong way. Patch to 7.1.2 today, that part takes minutes. The lesson worth keeping is bigger: this bug only became dangerous because of files and flags most of us never chose and have never once audited.

; Mitigation while you roll out 7.1.2; updating WordPress is the real fix.
register_argc_argv = Off

The dry version first. WordPress 7.1.2 shipped on September 22, 2026 and closes CVE-2026-87902, rated 9.2 Critical under CVSS 4.0. The flaw sits in template resolution around get_page_template(): under the right conditions, an unauthenticated visitor can steer WordPress into including a local PHP file from outside the theme directory, textbook CWE-98. The advisory is GHSA-7hp8-65ch-5whp, and the fix has been backported all the way down to the 4.7 branch, so there is a security release waiting for pretty much every install you are ashamed of.

Now the interesting part, the conditions. For the malicious include to be reachable, the active theme needs a top-level directory whose name starts with page-, something like page-templates. The advisory names Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney as themes where that layout exists, which is not an accusation, just geography. And to turn a file inclusion into code execution, the attacker needs a useful PHP file already sitting on disk. The advisory's example is pearcmd.php, which becomes a gadget once register_argc_argv is switched on, a combination it explicitly flags for the official PHP Docker image and for default cPanel setups running PHP versions below 8.5.

Read that list back. There is a PEAR command-line helper that ships in the base image whether or not you have typed pear this decade. There is register_argc_argv, an ini switch left over from the CGI era. Even the theme condition is just a directory naming habit older than the block editor. None of these are bugs on their own. Together they form the runway that lets a template-resolution slip take off into remote code execution. WordPress wrote the vulnerable line, but the surrounding stack supplied the accomplices.

The fair counter-argument is that this layering is exactly what protected most sites. Three conditions have to align, so an outdated install is not automatically one crafted request away from takeover, and the advisory says as much. True, and I am glad the coverage mostly stayed calm about it. Here is why I still will not relax: every one of those conditions is cheap to probe remotely at scale. Theme structure leaks through asset URLs, hosting fingerprints give away cPanel, and attackers script those checks in an afternoon while defenders tell themselves the stars probably will not align on their boxes. Narrow preconditions read nicely in an advisory and terribly in an incident report.

So the order of operations is boring on purpose. Update first, from the dashboard or with the matching release for whatever branch you run. Then, while you are on the box anyway, check register_argc_argv and switch it off unless you have a real reason to keep it, because that alone snaps the pearcmd.php link in the chain. And if a site sat exposed on an affected version with a matching theme and hosting setup, spend ten minutes grepping the access log for weird template requests and diff wp-content against a known-good copy before you close the ticket.

The longer fix is treating your baseline image like a dependency. The advisory drawing a line at PHP 8.5 is a hint that newer platform defaults already close part of this path. If you build on the official Docker image, it costs you two lines in the production stage to strip PEAR tooling you never invoke. Go folks like to point out that their deploy artifact is a single binary with nothing else in it, and fine, they earned that one, but nothing stops a PHP container from being nearly as bare. We just have to accept that software we never installed on purpose still counts as attack surface.

Which brings me to the question I genuinely want answered under this column. When you audit a production box or image, do you go hunting for executable leftovers like pearcmd.php, or does your review stop at your own code and composer.lock? And if the honest answer is the second one, what would it take, tooling, time or a scare like this, to move that line?