On November 4, the engineers who run ProudCity — the managed WordPress platform behind Madeira Beach and other small-city government sites — opened a public GitHub issue, shipped an out-of-band update, and closed it two hours and fourteen minutes later. The issue describes the work as "a precautionary out-of-band update, not a response to an active problem." The update applied WordPress 7.1.4, released October 28, which fixes CVE-2026-119977 — a remote code execution flaw CISA added to its Known Exploited Vulnerabilities catalog on November 3 with a November 6 federal deadline.
What makes ProudCity worth writing about is a sentence in that same issue: "ProudCity sites install core from the image and have DISALLOW_FILE_MODS set, so that upgrade window never opens on our sites." They were not patching an exposure. They were documenting that they never had one.
The patch and the exploit are the same operation
NVD describes the defect plainly: WordPress is "vulnerable to Remote Code Execution in versions 4.7 through 7.1.3" because of "predictable, web-accessible staging paths used during full-package core upgrades." During a core upgrade, WP_Upgrader unpacks the new release into directories under wp-content — upgrade/ and upgrade-temp-backup/ — whose paths are guessable and reachable over HTTP. An unauthenticated attacker who reaches the right path while the upgrade is in flight gets code execution.
The CVSS vector is AV:N/AC:H/PR:N/UI:N, scored 8.1. The AC:H — high attack complexity — is the whole story, and it reads worse than it sounds. The attack is "hard" because it is a race against the upgrade window. But a race you can poll for as long as you like is not hard; it is patient.
Here is the part no coverage states: the vulnerable operation is the remediation. Clicking "Update Now" on an internet-facing site is performing the exploitable act. And if minor-version auto-updates are enabled — the default — your site already performed it, unattended, on WordPress's schedule, on October 28. The CVE was not even published until October 31. This inverts the usual relationship between a patch and a compromise: where a NetScaler upgrade was the only way to check whether you had already been breached, here the upgrade is itself the exposure. CISA flags this one forensicTriage: Yes, and the honest question for a site with auto-updates on is not "are we patched" but "did our October 28 upgrade get raced."
The durable control is unwritable core
The reason ProudCity was never in scope is not luck and not a faster patch cycle. DISALLOW_FILE_MODS is a WordPress constant that forbids the application from modifying its own files — no plugin installs, no theme edits, no core updates from the dashboard. Combine it with core delivered inside a container image, and the PHP process simply cannot write to wp-admin, wp-includes, or wp-content/upgrade. The staging directories are never created because the upgrade machinery never runs. The upgrade window is a property of writable core, not of WordPress.
This costs you the one-click update. Core and plugin changes now move through an image rebuild and a deploy, which means you need a pipeline, and a team that updates by clicking cannot adopt it on a Tuesday. The sequencing that makes it affordable is to treat core as a build artifact: pin the version in your image, update it the way you update any other dependency, and let deployment — not the web server — be the only thing that writes to the code. A web server that cannot modify the application it serves is immune to an entire class of defects, of which this CVE is one instance.
If you cannot get there this quarter, the interim answer is narrower but real. Deny web access to both staging directories, not just upgrade/ — the circulating mitigation names only the first, and upgrade-temp-backup/ is created in the same run. And find your branch's actual fixed version instead of assuming you need 7.1.4: the fix shipped simultaneously across every branch WordPress still supports. A site on 6.8 is fixed at 6.8.12, a 6.0 site at 6.0.18, a 5.0 site at 5.0.31, a 4.7 site at 4.7.39 — no major-version jump required. The KEV entry links only the 7.1.4 announcement, which is how readers end up planning a migration they do not need.
What to check this week
ls -ld wp-content/upgrade wp-content/upgrade-temp-backup— find out which user owns them and whether either is reachable from the public internet.- Find your branch's fixed version in the WordPress release archive rather than assuming 7.1.4.
- If a host or agency runs your updates, ask them the ProudCity question: when did the last core upgrade run, and can the PHP user write to core?
- Review
wp-content/upgradeaccess logs from October 28 forward for requests to staged paths.
The November 6 deadline is a BOD 26-04 three-day clock, and the mechanics of that are covered separately. The deadline is the easy part. The question that outlives it is whether your web server should be able to write the code it runs.
North InfoSec runs AI-assisted penetration testing and security assessments, including the deploy-pipeline and filesystem-permission review described above. northinfosec.com