Cybersecurity News
Cybersecurity News Alert: WordPress Patched Itself Open
By Nattapong Sukkasem · Published · Updated .
TL;DR — Today is the deadline United States federal civilian agencies were given to remediate CVE-2026-119977, a race condition in the WordPress core upgrade routine that lets an unauthenticated attacker reach remote code execution. CISA listed it on 3 November, six days after WordPress shipped the fix in 7.1.4, and Wordfence counted more than 18,500 requests at the vulnerable path in the first 21 hours. What makes this cybersecurity news rather than one more CVE is where the exposure sits: the flaw is reachable only while a site installs a core update, so the window opens at the moment an administrator does the right thing.
Most vulnerability timelines assume a clean step change. A site is exposed, the patch lands, the site is safe. CVE-2026-119977 does not fit that shape, which is why it is the cybersecurity news worth half an hour of your week. The flaw lives inside the WordPress core upgrade routine, and cannot be reached on a site sitting untouched on an old release. It is reachable only during the handful of seconds in which WordPress unpacks a new version over the old one.
What CISA put on the clock
CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalogue on 3 November 2026, with a remediation date of 6 November for Federal Civilian Executive Branch agencies. That date is today. Reporting disagrees on which binding directive the entry cites, though the deadline is consistent everywhere. Wordfence, as numbering authority, scored the flaw CVSS 3.1 8.1, vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, classified CWE-367, a time-of-check to time-of-use race.
Every release from 4.7 through 7.1.3 is affected. The fix shipped on 28 October in 7.1.4 and was backported to every branch still eligible for security fixes, down to 4.7.39 — a fan-out that shows how the project read the risk. Installations on 4.6 or earlier receive nothing. Patchstack traces the code to WordPress 2.8, so the pattern survived seventeen years of review.
How a core update becomes remote code execution
A full-package core update does not patch files in place. WordPress unpacks the release into a working folder beneath wp-content/upgrade, copies it over the live installation, then deletes the staging copy. On many servers that folder sits inside the document root and PHP runs there.
A complete distribution carries its own installer at wp-admin/setup-config.php, built to run on a site with no configuration, so it answers without loading the installation around it. Before 7.1.4 the working folder was named predictably after the release package, and cleanup deleted the index.php that would otherwise have blocked a directory listing.
| Step | What happens |
|---|---|
| Trigger | An administrator, or an automatic background update, begins a full-package core update. |
| Unpack | The release is extracted into a predictable folder under wp-content/upgrade, web-served on many hosts. |
| Discovery | With index.php removed during cleanup, the folder can be listed and its exact name read. |
| Request | The attacker reaches the staged wp-admin/setup-config.php, which runs without the live configuration. |
| Write | A POST to step=2 makes the staged installer write a wp-config.php naming a database the attacker controls. |
| Promotion | The update copies that file over the live one; the site loads the attacker database and any administrator account in it. |
A proof of concept published on 4 November automates that chain and ships a fake MySQL server, so no real database is needed to answer. Once a site trusts an attacker-supplied database, a planted administrator account is simply a valid login, and the theme editor finishes the job.
The 7.1.4 fix closes each link in turn. Sixteen random characters are appended to the working folder name, index.php is recreated rather than deleted, and update-core.php adds wp-config.php to the files a core update will never copy out of the staging tree.
Why the race was winnable
An attack complexity of high is the honest rating: the staging folder exists for seconds, and a single well-aimed request rarely lands. What changes the arithmetic is that the starting gun is fired in public. WordPress announces a security release telling everyone to update immediately, and sites with background updates begin unpacking within hours. An attacker need not guess when a site will be vulnerable, only keep asking.
The telemetry shows exactly that. Wordfence deployed a firewall rule at 20:30 UTC on 28 October, roughly three hours after the announcement, and recorded its first match nine minutes later. Over the following 21 hours it counted more than 18,500 requests aimed at staged installer paths. Two of the largest sources polled small groups of sites for about fourteen and a half hours.
A DDoS attack is an argument about capacity, settled in minutes by whoever has more of it. This was the opposite discipline: a trickle of requests costing almost nothing, sustained across most of a day, waiting for a directory to exist.
There is no zero-day vulnerability anywhere in this story. The patch was public six days before CISA called the exploitation active. The attackers were never racing the vendor — they were racing the administrators installing the vendor's fix.
The fix has to be unpacked by the broken code
Here is the uncomfortable centre of this cybersecurity news story. The update that removes the flaw is itself a full-package core update, and on a site still running 7.1.3 it is unpacked by the old routine. One vendor analysis raises this directly, flagging it as its own reading rather than something WordPress or Wordfence has confirmed: the remediating upgrade may open the window one final time on its way through.
Whether that inference holds in every configuration matters less than its shape. Security practice assumes patching moves risk in one direction, and a defect in the patching mechanism inverts that locally. The sites most exposed after 28 October were not the neglected ones. They were the diligent ones, updating promptly, on a timetable the attacker could read off a public blog post.
An upgrade folder is server infrastructure
The severity ratings do not agree: WordPress marks the issue low with no score, Wordfence scores it 8.1, and Patchstack has said it would not call the flaw practical to exploit. The attempts arrived regardless, and what the disagreement obscures is structural. A WordPress installation is server infrastructure that keeps its own maintenance machinery inside its public document root. The upgrade folder is where the product puts temporary files by design, on millions of hosts, under a path anyone can guess.
That carries an awkward implication for cloud security practice. On managed WordPress hosting the provider often decides when the core update runs. IONOS and Pantheon both said they had mitigations in place before disclosure, which is welcome and also the point: the window on those fleets was scheduled outside the customer's change control.
What the last step asks your resolver to do
The final link in the published chain is the one most likely to be visible in your own logs. For the promoted configuration to be useful, the compromised site must connect outward to a database host the attacker names in that POST. That almost always means a hostname, so it means a lookup: your web server resolving a domain nobody ever placed in a configuration file, then opening a connection on the MySQL port to an address outside your estate. Web servers have narrow resolution habits, and a name outside that set, resolved minutes after an update, is a clean signal.
That visibility erodes by default. As host operating systems, container images and runtime libraries quietly adopt DNS over HTTPS, the lookup moves from your resolver to an encrypted session with a public one, and the clearest evidence of this compromise stops appearing in logs you control. A server is not a laptop in a coffee shop: decide where your own infrastructure resolves rather than inheriting it.
What to do before the next core release
- Confirm the version, do not assume it. Background updates usually work. Check that each site reports a fixed build for its branch rather than trusting the update fired.
- Deny the upgrade path at the web server. Block HTTP access to
/wp-content/upgrade/in the virtual host configuration, not inside the folder WordPress keeps recreating. - Hunt the window, not the month. Find each upgrade time, then pull every request to a PHP file beneath
wp-content/upgradeeither side of it. A 404 is noise; a POST to a staged installer is an incident. - Check the one file a core update never writes. A modified
wp-config.phparound an upgrade timestamp is the clearest indicator here. Follow it with a checksum verification and a review of administrator accounts. - Alert on the lookup and the egress. Flag unfamiliar names resolved by web processes and any outbound connection to a database port off your network. Use a network diagnostic tool to record what your configured names legitimately resolve to.
- Find the installations nobody owns. Whether a forgotten campaign microsite updates itself on a schedule nobody is accountable for is an IT security question, usually answered by marketing rather than by whoever handles the intrusion.
Why it matters beyond WordPress
No confirmed compromise has been published, and the counts in circulation do not reconcile: outlets report roughly 12,000, 18,500 and 63,000 across different windows, and one analyst could not match the largest figure to the vendor post it was credited to. Treat them as attempts, not victims.
The durable lesson outlasts the numbers and this cybersecurity news cycle. Unpacking an update is a privileged operation that briefly places writable, executable, attacker-interesting files inside a public directory, and nearly every deployment system does something comparable. WordPress is simply the one with enough installations to industrialise the attempt. The question worth carrying away is which of your own systems opens a door in order to close one.
Sources
- The Hacker News — CISA confirms hackers exploiting WordPress core flaw during software upgrades
- Security Affairs — CISA adds the WordPress flaw to its Known Exploited Vulnerabilities catalog
- ThreatDefence — Hunting the WordPress 7.1.4 upgrade-window RCE
- Rescana — WordPress core 7.1.4 fixes an unauthenticated upgrade-window race RCE
- WordPress.org — WordPress 7.1.4 security release
- Qualys ThreatPROTECT — CISA warns of WordPress vulnerability exploited in the wild
Related articles
Browse every DNS news article by month →
DNS angle
Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.
Source: The Hacker News — CISA confirms hackers exploiting WordPress core flaw during software upgrades ().