CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, citing evidence of active exploitation. The flaw lets an unauthenticated attacker execute code during a vulnerable WordPress core upgrade. WordPress released 7.1.4 with the repair on October 28. The new development is confirmed exploitation, rather than a newly released patch.
Evidence status: active exploitation confirmed by CISA. Its alert and catalog entry provide no victim count or first-exploitation date. The catalog marks ransomware use Unknown.
The upgrade window is the exposure condition
The Wordfence-authored CVE record describes predictable, web-accessible staging paths during full-package core upgrades. Those paths temporarily expose installation code while an update is in progress. The race condition is a timing failure: an attacker can reach vulnerable code during that interval.
This prerequisite matters. The record does not say every ordinary request to every WordPress page permits code execution. Equally, a short upgrade window does not establish that an exposed site escaped exploitation.
The record lists affected versions separately for release branches from 4.7 through 7.1. Avoid treating “4.7–7.1.3” as one continuous affected range after branch-specific security backports have shipped.
Match the installed branch to its fixed release
WordPress’s 7.1.4 release documentation confirms the October 28 release and lists security backports. These examples combine its fixed releases with the CVE record’s affected bounds:
| Release branch | Affected versions in that branch | Security release |
|---|---|---|
| 7.1 | 7.1.0–7.1.3 | 7.1.4 |
| 7.0 | 7.0.0–7.0.7 | 7.0.8 |
| 6.9 | 6.9.0–6.9.10 | 6.9.11 |
| 4.7 | 4.7.0–4.7.38 | 4.7.39 |
The linked documentation covers the intervening branches. These are security-release baselines, not instructions to downgrade a newer installation. WordPress says only its most recent version is actively supported; courtesy backports do not make old branches an equivalent long-term choice.
Check the version actually installed on each site, including hosted and less-used installations. The release announcement recommends immediate updates through WordPress’s supported update process. An enabled automatic-update setting is not evidence that an individual site completed its update. If hosting controls that process, ask the provider to confirm the resulting version and supported upgrade route.
Preserve evidence as well as closing the flaw
The catalog entry sets forensicTriage: Yes and lists a November 6 federal remediation due date. CISA’s binding requirements apply to Federal Civilian Executive Branch agencies under its risk-based rules. That date is not a universal deadline imposed on every private WordPress owner.
CISA’s triage guidance calls for scoping affected systems, preserving relevant evidence and then applying critical patches. Its suggested step-by-step timelines are best practices, not separate mandatory deadlines.
For an exposed site, preserve available web, hosting and update logs for the relevant upgrade periods. Review unexpected code, account or configuration changes through the normal incident-response process. These are investigative precautions drawn from the general triage guidance, not published WordPress-specific indicators proving compromise.
Installing a repaired release closes the documented flaw. It cannot establish whether an attacker already used an earlier upgrade window or remove every change made after a successful intrusion.
Caveat: CISA confirms exploitation but publishes no campaign details here; the Wordfence-authored CVE record and WordPress release notes establish the mechanism and branch-specific fixes.