Changed since version 2

• what_happened and verdict now state the flaw is a TOCTOU race abusing predictable web-accessible staging paths, and use 'could allow' code execution as the source does [S1].
• Added eradicate and reenter_when sections. The eradicate steps are generic, because the sources describe no persistence.

What happened

• CISA added CVE-2026-119977 to the KEV catalog on 2026-11-03, with a federal due date of 2026-11-06 [S1][S2].
• The flaw is a TOCTOU race in WordPress Core. It could let unauthenticated attackers execute code during full-package core upgrades [S1].
• The race abuses predictable, web-accessible staging paths created during the upgrade [S1].
• BOD 26-04 requires federal agencies to perform forensic triage for this entry [S1].
• The sources reviewed give no attacker behaviour, payloads or IoCs [S1][S3].

Timeline

Detect

Web requests into WordPress upgrade staging paths · Web server / reverse proxy / WAF access logs

index=* "/wp-content/upgrade" | rex field=_raw "(?<req_path>/wp-content/upgrade[^\s\"?]*)" | search req_path="*.php*" | stats count earliest(_time) as first_seen latest(_time) as last_seen values(status) as status by host, req_path | convert ctime(first_seen) ctime(last_seen)

FROM logs-* | WHERE url.path LIKE "*/wp-content/upgrade*" AND url.path LIKE "*.php*" | STATS count = COUNT(*), first_seen = MIN(@timestamp), last_seen = MAX(@timestamp), status = VALUES(http.response.status_code) BY host.name, url.path

A hit means: A client requested a PHP file in the upgrade staging area. This matches the predictable staging-path condition [S1]. The search assumes the default WordPress directory, because the sources do not name the path. A 200 response to an external client during an upgrade window warrants forensic triage.

Shell or download tools spawned by the web server or PHP process · EDR / Sysmon / auditd process creation on WordPress hosts

index=* (parent_process_name="php*" OR parent_process_name="httpd" OR parent_process_name="apache2" OR parent_process_name="nginx" OR parent_process_name="w3wp.exe") (process_name="sh" OR process_name="bash" OR process_name="dash" OR process_name="curl" OR process_name="wget" OR process_name="python*" OR process_name="perl" OR process_name="nc" OR process_name="cmd.exe" OR process_name="powershell.exe") | stats count earliest(_time) as first_seen values(process) as cmdline by host, parent_process_name, process_name

FROM logs-* | WHERE (process.parent.name LIKE "php*" OR process.parent.name IN ("httpd", "apache2", "nginx", "w3wp.exe")) AND (process.name IN ("sh", "bash", "dash", "curl", "wget", "perl", "nc", "cmd.exe", "powershell.exe") OR process.name LIKE "python*") | STATS count = COUNT(*), first_seen = MIN(@timestamp), cmdline = VALUES(process.command_line) BY host.name, process.parent.name, process.name

A hit means: The web server executed a command. This is consistent with the code execution the KEV entry describes [S1]. Correlate the time with core upgrade windows and with Hunt 1 hits.

Verify

• True positive: an external client fetches or executes a .php file under the staging path while a core upgrade is running. Look for follow-on activity such as new PHP files, web-server child processes or new admin users.
• Compare hit times with actual core upgrade times in WordPress or host logs. The race exists only during full-package upgrades [S1].
• Benign look-alike: WordPress itself writing and extracting files in the upgrade directory during legitimate updates.
• Benign look-alike: scanners and uptime checks probing wp-content paths. These typically return 403 or 404 and show no execution.
• Benign look-alike: cron, WP-CLI or backup plugins spawning shell or PHP subprocesses.

Scope

Affected

• WordPress Core sites vulnerable to CVE-2026-119977 [S1]. Pipeline exposure data gives 4.7.0 through 7.1.3, citing a Wordfence advisory that is not among S1–S3.

Only if

• A full-package core upgrade is performed, which creates web-accessible staging paths during the upgrade window [S1].

Not affected if

• Core is at a fixed version: 7.1.4 or later per pipeline exposure data, which cites a vendor release note not among S1–S3.

Fixed in: 7.1.4 (per pipeline exposure data; confirm against the WordPress release note)

Enumerate

• All WordPress instances and their core versions, including marketing, campaign, and third-party or agency-hosted sites.
• Which sites ran full-package core upgrades, and when. Check auto-update logs and hosting-panel history.
• Whether the staging directory is reachable over the web on each site.
• Admin accounts, application passwords and API keys on each site.
• Secrets stored on WordPress hosts, such as wp-config.php database credentials and cloud keys.

Contain

• Preserve evidence first: export web access logs and snapshot wp-content/upgrade and the web root. Deleting staging contents cannot be undone.
• Patch to the fixed release. Run the upgrade with the site restricted (maintenance mode, IP allowlist or WAF deny on staging paths) if feasible. This precaution is derived from the mechanism in [S1]; it is not vendor guidance.
• Until patched, avoid unattended full-package core upgrades on exposed sites, or block web access to the staging directory.
• Isolate any site with a confirmed hit from internal networks and databases pending forensic triage, as BOD 26-04 requires for federal agencies [S1].

Eradicate

• Remove any unknown PHP files and webshells found in staging or web directories. The sources give no specific persistence artefacts.
• Remove unknown admin users and rotate wp-config.php database credentials, application passwords and keys on any affected host.
• Reinstall core from a verified package if checksums do not match.

Recover

• Before restoring traffic, confirm the core version is fixed, checksums match, and no unknown PHP files or admin accounts remain.
• Monitor web logs for staging-path requests and web-server child processes for at least the next upgrade cycle.
• Watch outbound connections from WordPress hosts for unexpected destinations.

Re-enter the loop when

• A vendor or researcher publishes IoCs, payloads or the exact staging path.
• The WordPress advisory changes the affected range or fixed version.
• Exploitation is reported outside upgrade windows, or in plugin and theme updates.
• A hit appears on a site not in the original inventory.

Debrief

• Record each WordPress site with its version, upgrade times and hunt results.
• Record the time from KEV listing (2026-11-03) to patch for each site.
• Gap: no source reviewed gives the exact staging path, exploit timing or IoCs.
• Gap: the version range and fixed version come from advisories not among S1–S3.
• Gap: whether the inventory covered third-party or agency-hosted sites.

Detection coverage — checked automatically

Checked automatically 2026-11-10 18:12Z from public sources: 10 published, 17 nothing found, 0 not machine-checkable, 0 failed. "Nothing found" means the public source answered and had nothing, as of that moment; a feed covers only its newest posts. Re-checked daily.

Exposure queries — generated automatically

Where each CVE comes from: CVE-2026-119977 — WordPress Core CVE-2026-119977 TOCTOU race enables unauthenticated code execution during upgrade; added to CISA KEV. A product row answers "is the software from that story reachable from the internet", not "is this card about that software".

vuln:CVE-2026-119977

cpe:"cpe:/a:wordpress:wordpress"

product:"Wordpress"

host.services: (software.product = "Wordpress")

http.html:"wp-includes/js/wp-emoji-release.min.js"

Internet-wide count, trend

Shodan's count of matching services on the whole internet, one point a day; the scope (your ranges) is never part of it. A count moves with Shodan's crawl as much as with patching, so read the direction, not the digit.

Banner spellings: a model read 1 from the NVD names and this card's text (former and marketing names, console titles); 1 matched something on Shodan and is shown above, the rest were dropped.

Scope every query in your own tool, never in a shared document: Shodan `net:<your_ranges>`, `org:"<your_org>"` or `hostname:<your_domain>` (or a Shodan Monitor network alert, which applies the scope for you); Censys `host.ip: <your_ranges>` or `host.dns.names: <your_domain>`. Then compare the banner version with the affected range. Generated automatically 2026-11-10 18:12Z from the CVE ids and NVD's CPE configurations, each Shodan query counted against Shodan itself; re-built daily with the coverage check.

Open questions

• The input flags one material development on watch, but today's story repeats the prior facts. What changed is not identified in S1–S3.
• Exact staging path and race timing are not given by S1–S3.
• Affected range 4.7.0–7.1.3 and fix 7.1.4 need confirmation from the WordPress or Wordfence advisory.
• Who is exploiting this, and how widely?

Sources

• [S1] https://www.cisa.gov/known-exploited-vulnerabilities-catalog · Cybersecurity and Infrastructure Security Agency (CISA)
• [S2] https://www.cisa.gov/news-events/alerts/2026/11/03/cisa-adds-one-known-exploited-vulnerability-catalog · CISA
• [S3] https://thehackernews.com/2026/11/cisa-confirms-hackers-exploiting.html · The Hacker News

Public OSINT only. AI-generated by the pipeline; structure follows the DAIR model from Dynamic Incident Response (Joshua Wright). Published automatically; a dismissed draft unpublishes it.