> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # CISA adds WordPress TOCTOU race condition CVE-2026-119977 to KEV - URL: https://f4n6.co.uk/security-feed/cisa-adds-wordpress-toctou-race-condition-cve-2026-119977-to-kev/ - Published: 2026-11-04T09:45:25.000Z - Updated: 2026-11-04T09:45:25.000Z - Author: Jeff Davies - Tags: #security-feed, CVE-2026-119977 ## 1\. Executive summary CISA added CVE-2026-119977, a time-of-check time-of-use race condition in WordPress Core, to the Known Exploited Vulnerabilities catalog on 2026-11-03, citing evidence of active exploitation. NVD scores the flaw 8.1 HIGH (CWE-367); EPSS puts exploitation probability at 1%. The vulnerability lets an unauthenticated attacker execute code on the server during the window in which a full-package core upgrade is unpacking files into a predictable, web-accessible staging path. Any EMEA financial services firm running WordPress Core, including marketing sites, intranet portals and supplier-facing microsites, is exposed while an upgrade is in progress; the exploitation window is seconds long but the attacker needs no credentials, and Defiant recorded more than 18,500 requests targeting staged installer paths in the first 21 hours after its firewall rule shipped. CISA's remediation due date is 2026-11-06. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | DORA Art. 17: ICT-related incident management process | CISA records active exploitation of a component (WordPress Core) that many firms run as internet-facing infrastructure; the flaw is only exploitable during an upgrade window, so detection depends on upgrade-time logging. | The incident management process must cover upgrade windows as an attack surface: log staging-path requests, define who reviews them, and treat a hit as a security event requiring triage. | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | If a WordPress Core host is compromised through this flaw, the firm has an ICT-related security incident whose major-incident classification and reporting timeline run from detection. | Detection and triage of staging-path access must be fast enough to meet the reporting clock; the upgrade-window logging in Art. 17 is the input. | | NIS2 Art. 21(2)(d): supply chain security measures | WordPress Core is third-party software, and the fix ships as a core release (7.1.4, backported to 4.7) that the firm must track and apply across its estate and any agency-managed sites. | Supplier and agency contracts must oblige timely core updates and evidence of the version in use; the firm needs an inventory of who runs WordPress on its behalf. | ## 3\. Technical analysis & attack chain CVE-2026-119977 is a TOCTOU race condition in the WordPress Core update process. NVD describes it as allowing unauthenticated attackers to execute code on the server during the upgrade window, caused by predictable, web-accessible staging paths used during full-package core upgrades. The verified severity is 8.1 HIGH, CWE-367, and the CVE is in CISA KEV (added 2026-11-03). EPSS is 1%. The mechanism, as Defiant describes it to SecurityWeek: when WordPress unpacks a complete Core update, the new files land in a staging directory whose path is predictable and reachable over the web on many servers. An attacker who can reach that tree and has PHP execution there can act on the staged files before WordPress promotes and cleans them up. Defiant lists the preconditions as a full-package update containing the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time to complete the attack before WordPress removes the temporary files. No account on the site is needed. The window is seconds long and attack complexity is high, which is why the actor behaviour Defiant observed is repeated polling of the vulnerable paths rather than a single request. Confirmed steps, from the sources: 1. A site administrator runs a full-package WordPress Core upgrade, which unpacks installer files into a staging directory. 2. The attacker, unauthenticated, requests the predictable staging path over the web while unpacking is in progress. 3. The attacker acts on the staged installer files (Defiant's telemetry shows requests aimed at staged setup-config.php installer paths) before WordPress promotes and deletes the temporary files. 4. On success the outcome is code execution on the server. NVD states this; Defiant describes the flaw as exploitable for remote code execution. What the sources do not give: no post-exploitation detail (persistence, privilege escalation, command-and-control, lateral movement, data access) is stated in public reporting. No victim is named. No malware family, webshell name or implant is identified. No initial-access vector other than the upgrade window itself is described. No actor is named by any source, and MITRE ATT&CK has no profile tying a named group to this CVE, so attribution is unconfirmed. Exploitation evidence rests on two sources. CISA's KEV listing is the authoritative statement of active exploitation. Defiant's telemetry, reported by SecurityWeek, is single-sourced: Wordfence recorded more than 18,500 requests targeting staged setup-config.php installer paths in the first 21 hours after its firewall rule deployed, with the first match nine minutes after deployment. Defiant has not reported successful compromises. Treat the request volume as one vendor's observation and verify before relying on it for scoping. The fix: WordPress 7.1.4, released with patches on October 28, randomizes the staging directory, adds an index guard, and prevents unsafe promotion of staged configuration data. Fixes were backported to branches through WordPress 4.7\. WordPress 7.1.4 also carries patches for 22 security defects, including several XSS flaws, interactivity API issues, an unauthenticated information disclosure bug, an authorization weakness, and updated bundled root certificates reflecting the eMudhra revocation. Those other defects are separate from CVE-2026-119977 and are not covered by its KEV entry. Separate events, not part of this item: CVE-2026-60137 (WordPress Core SQL injection) and CVE-2026-63030 (WordPress Core interpretation conflict) are distinct KEV entries with their own due dates; CVE-2026-87902 is a separate WordPress RCE flaw; and a separate, then-unidentified WordPress Core RCE affecting versions 4.7 through 7.1.3 drew nearly 63,000 attack attempts in 24 hours. None of these contribute indicators or facts to this advisory. ## 4\. Mitigation & containment P1 (within 24 hours) - Upgrade every WordPress Core installation to 7.1.4, or to the current release on the relevant branch if the site runs an older line, since fixes were backported through 4.7\. Confirm the running version after the upgrade; do not assume an auto-update succeeded. - Inventory internet-facing WordPress instances, including agency-managed and marketing microsites, and record which version each runs. The exposure is only during a full-package upgrade, so an estate that never upgrades is not safe, it is unpatched. - Where 7.1.4 cannot be applied immediately, restrict web access to staging directories at the reverse proxy or WAF. Defiant's observed traffic targets staged setup-config.php installer paths; block or alert on requests to those paths outside a known upgrade window. - Enable and retain web server access logs for the upgrade period so staging-path requests can be reviewed after the fact. P2 (within 72 hours) - Review logs for requests to setup-config.php under staging paths in the days before and after any recent core upgrade. Defiant's firewall rule matched such requests within nine minutes of deployment, so the pattern is detectable in access logs. - Confirm that no upgrade ran between 2026-11-03 (KEV addition) and the point 7.1.4 was applied, and treat any such window as a candidate for compromise review. - For hosts that ran an upgrade in an exposed window, check for unexpected files in the web root and for modified core files against a clean 7.1.4 package. P3 (within 7 days) - Add staging-path access to standing detection (see §6) rather than one-off review. - Where a third party or agency operates WordPress on the firm's behalf, obtain written confirmation of the version in use and the date 7.1.4 was applied, and put core-update timelines into the contract. No fixed release other than WordPress 7.1.4 (and its backports through 4.7) is named in public reporting. No vendor workaround short of the 7.1.4 changes is described. ## 5\. Indicators of compromise No atomic indicators of compromise (hashes, domains, IPs, filenames) are present in the sources. The sources describe observable behaviour but no machine-pivotable values. Behavioural indicators | behaviour | where to observe | confidence | | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------ | | Unauthenticated HTTP requests to a predictable WordPress Core staging path during a full-package upgrade | Web server access logs, reverse proxy, WAF | High (Defiant, single-sourced) | | Repeated polling of staging paths to hit the seconds-long window | Web server access logs (request rate per source) | High (Defiant, single-sourced) | | Requests targeting staged setup-config.php installer paths | Web server access logs, WAF | High (Defiant, single-sourced; >18,500 requests in first 21 hours) | ## 6\. Detection The sources give no file artefacts, command lines, mutexes or registry keys for this flaw, so a YARA rule cannot be built from threat artefacts. Detection rests on web request behaviour. The Sigma rule below matches access-log requests to setup-config.php under a staging path; tune the path pattern to the site's actual staging convention, since the sources do not give the exact directory name. ```yaml title: WordPress Core staging setup-config.php access during upgrade window id: 8f3c2a10-1199-4777-9a10-000000000001 status: experimental description: Detects unauthenticated requests to a WordPress Core staging setup-config.php installer path, the behaviour Defiant observed against CVE-2026-119977. author: Adverse Trace date: 2026-11-04 references: - https://thehackernews.com/2026/11/cisa-confirms-hackers-exploiting.html - https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/ logsource: category: webserver detection: selection_path: cs-uri-stem|contains: - '/setup-config.php' selection_staging: cs-uri-stem|contains: - '/wp-content/upgrade/' - '/upgrade/' condition: selection_path and selection_staging falsepositives: - Legitimate WordPress core upgrade in progress from the site administrator level: high ``` Alert on any match outside a scheduled upgrade window. During an upgrade, correlate the source address against the administrator's. ## CVE assessment 1 referenced CVE — **1 actively exploited (CISA KEV)** | CVE | CVSS | Exploited | EPSS | Summary | | ---------------------------------------------------------------------------------- | -------- | ---------------- | ---- | --------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2026-119977](https://nvd.nist.gov/vuln/detail/CVE-2026-119977?ref=f4n6.co.uk) | 8.1 High | ⚠ KEV 2026-11-03 | 1% | WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3\. This is due to predictable, web-accessible… | ## 7\. Sources - The Hacker News, "CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades", https://thehackernews.com/2026/11/cisa-confirms-hackers-exploiting.html, 2026-11-04 - NVD / CISA KEV, CVE-2026-119977, https://nvd.nist.gov/vuln/detail/CVE-2026-119977 - SecurityWeek, "Fresh WordPress Vulnerability in Attackers' Crosshairs", https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/ ## 8\. Adverse Trace position Adverse Trace assesses CVE-2026-119977 as 8.1 HIGH per NVD, in CISA KEV since 2026-11-03, with a CISA remediation due date of 2026-11-06\. The exploitation evidence is CISA's KEV listing plus Defiant's telemetry; the request-volume figures are single-sourced to Defiant and should be verified before use in scoping. No actor is named and attribution is unconfirmed. Client impact for EMEA financial services is moderate: the flaw needs a full-package upgrade in progress and a web-reachable staging path, but it needs no credentials and the fix (WordPress 7.1.4, backported through 4.7) is available, so the risk is concentrated in estates that upgrade slowly or cannot confirm their version. Adverse Trace will track whether Defiant or WordPress reports a confirmed compromise, and will update this advisory if a victim, actor or post-exploitation detail is published. Clients should confirm 7.1.4 across all WordPress instances, including agency-managed sites, and report the version and upgrade date back to their Adverse Trace contact by 2026-11-06. --- [Read the original source →](https://thehackernews.com/2026/11/cisa-confirms-hackers-exploiting.html?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*