WordPress is on CISA's exploited list. Patching is only half the job
CISA added a WordPress Core flaw to its known exploited vulnerabilities catalogue on 3 November. Patch it, then check whether you were compromised before the fix landed.
What happened
On 3 November 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added one vulnerability to its Known Exploited Vulnerabilities (KEV) catalogue. It is CVE-2026-119977, a time-of-check to time-of-use (TOCTOU) race condition in WordPress Core. CISA said it added the entry on evidence of active exploitation.
CISA's alert notes that TOCTOU vulnerabilities are a frequent attack vector and pose significant risks to the federal enterprise. The alert does not name a fixed version or describe the exploitation, and the page we read gives no remediation due date. Anyone running WordPress should read the WordPress project's own security notices for the affected and patched versions.
The alert also refers to Binding Operational Directive (BOD) 26-04. According to the alert, the directive requires Federal Civilian Executive Branch agencies to prioritise rapid remediation of KEV vulnerabilities on publicly exposed assets that could give an attacker total control after exploitation. It also sets expectations for checking whether a system was compromised before the patch was applied.
The directive applies only to federal agencies. CISA does, however, encourage all organisations to prioritise vulnerabilities in the catalogue.
That is the whole of what CISA published here, and we have added nothing to it. The rest of this note is our view.
Why it matters
The catalogue answers the question every patch queue faces. Most organisations have more vulnerabilities than they can fix at once. An entry in the KEV catalogue means exploitation has been seen. That moves it ahead of flaws that are only severe in theory. Our view is that a plain rule, such as fixing catalogue entries on exposed systems first, beats a long debate about scores.
Public websites are part of the attack surface. WordPress often sits on marketing sites, event pages and microsites, sometimes run by an agency or a team outside central IT. These systems are exposed to the internet by design. When one is compromised, it can damage your brand, host malicious content or give an attacker a foothold, depending on what else is connected to it.
A patch tells you about the future, not the past. The directive's expectation that agencies check for compromise before patching reflects a basic point. If exploitation was under way before you applied the update, the update does not remove what an attacker left behind. Organisations that patch and move on can be left with an intruder they have not found.
Ownership is usually the real gap. In incidents of this kind, the hard part is often not the fix but finding out who owns the site, who can change it and how quickly. An inventory with names against it turns a scramble into a routine job.
What we would do
- Find every WordPress site you own or pay for. Include agency-managed sites, old campaign pages and sites acquired with a business. Record the version, the host and the owner.
- Apply the update and read the vendor's advice. Use the WordPress project's security notices for affected versions. If you cannot patch immediately, ask your host or agency what interim protection they can put in place, and agree a date.
- Check for signs of compromise before and after. Review web server and access logs for the period before the update, look for unexpected files, administrator accounts, plugins and scheduled tasks, and compare against a known-good copy.
- Treat any finding as an incident. Preserve logs, change credentials and keys the site could reach, restore from a clean copy where needed, and tell your incident lead. Take advice if personal data may be involved.
- Adopt the catalogue as a standing input. Subscribe to the KEV feed, match entries to your inventory automatically, and set a target time for exposed systems. Report on how often you meet it.
- Reduce what a website can reach. Separate marketing sites from internal networks and from systems holding customer data, so a compromise stays small.
The aim is a short, repeatable response that works the same way for the next entry, whichever product it concerns.
Questions we are asked
Does this CISA directive apply to us?
Binding Operational Directive 26-04 applies only to US federal civilian agencies. CISA does, however, encourage all organisations to prioritise vulnerabilities in the catalogue, because each entry rests on evidence of active exploitation. Many organisations adopt the catalogue as an input to their own patching priorities. Whether any contractual or regulatory duty applies to you is a question for your own advisers.
Is patching enough once an exploited flaw is announced?
Not on its own. Exploitation can begin before a fix is applied, so a patched system may already have been compromised. CISA's directive sets an expectation that agencies check for compromise before the patch. Review logs, look for unexpected files, accounts and scheduled tasks, and keep evidence. If anything looks wrong, treat it as an incident and not as routine maintenance.
How do we know which of our systems are exposed?
Start from an inventory of internet-facing assets, including marketing sites, microsites and agency-run properties that sit outside the main IT estate. Match each to its software and version, and name an owner. Scanning from outside your network shows what an attacker sees. Gaps in the inventory are usually where exploited flaws are found first.