Why 'We Patched That in 2015' Is Not an Answer to a KEV Deadline

On 8 October 2026 CISA added five vulnerabilities to its Known Exploited Vulnerabilities catalog and gave federal agencies until 11 October to act. The striking detail was their age: two were disclosed in 2015, one in 2016, one in 2021 and one in 2023. Every one had a vendor patch available for years. For any security leader, the reflex response, "we patched that long ago," is natural and almost always insufficient. This article explains why a KEV deadline on an old CVE is a different kind of obligation than patching a fresh one, and how to meet it.

What a KEV listing actually asserts

The Known Exploited Vulnerabilities catalog is not a severity ranking. A CVE earns a place on it only when CISA has evidence that it is being exploited in the wild. That is a factual claim about the present, not a theoretical one about risk. When an old CVE appears, CISA is telling you that right now, somewhere, attackers are successfully using it against real systems.

Under Binding Operational Directive 26-04, federal civilian agencies must remediate catalogued vulnerabilities by the assigned due date, and the batch from October 2026 carried the compressed three-day window CISA reserves for urgent entries. Private organisations are not bound by the directive, but the catalogue has become the de facto minimum standard for "vulnerabilities you cannot leave unaddressed," because it is a curated list of what is provably being used against people.

The reason an old CVE lands there is almost always a disclosed campaign. These five arrived alongside a joint advisory, AA26-281A, attributing their exploitation to a China-linked contractor running an industrial scanning operation. The mechanics of that operation are covered in How a Contractor's Scanning Platform Turns a BotnetBotnet🛡️A network of internet-connected devices compromised and controlled by an operator, used for denial-of-service attacks, proxying malicious traffic, credential stuffing or spam. Edge routers are prized botnet hosts because they are numerous, always on, directly reachable and rarely inspected by their owners. Into a Target List; the relevant point here is that the listing is a direct consequence of observed, attributed exploitation.

Why 'we patched that' does not close the ticket

The gap between believing a vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. is gone and proving it is gone is where these campaigns live. Several forces keep a decade-old CVE alive in an environment that "patched it":

• **Embedded and bundled components.** A vulnerable library or server rarely exists only where you installed it deliberately. The ONLYOFFICE Document Server in the October batch ships inside collaboration suites and appliances. A component like Apache Struts gets bundled into vendor products whose owners have no idea it is there. You can patch every instance you know about and still run three you have forgotten.
• **Appliances and vendor images.** When a product is delivered as a sealed appliance, the operator often cannot see or change the version of the FTP or DNS daemon inside it. The fix depends on a vendor firmwareFirmware🏠Permanent software programmed into a device's hardware that controls its basic functions. update that may never come for an end-of-life device.
• **Drift and rebuilds.** A host patched in 2016 may have been rebuilt from an old image, restored from a backup, or spun up from a template that predates the fix. Patch state is not permanent; it decays.
• **Shadow and inherited systems.** Mergers, departed staff and quick projects leave systems that no one currently owns. These are precisely the forgotten internet-facing hosts a scanning pipeline is built to find.

This is why a KEV deadline on an old CVE is really a hunting assignment, not a patching one. The patch almost certainly exists and is almost certainly already deployed to the systems you manage well. The obligation is to prove that no unmanaged instance exists, which is a fundamentally different and harder task.

Turning a KEV deadline into a verification exercise

Meeting the deadline on an old CVE means answering one question with evidence: does any instance of this vulnerable service exist anywhere we are responsible for, and can I show it is patched or gone? A workable process:

1. **Identify the true footprint of the component, not the product.** Do not search only for "ONLYOFFICE" or "Struts" as installed applications. Search for the service's network fingerprint and for the component embedded inside other products. Vendor advisories and the CVE's affected-version data tell you what to look for.
2. **Scan yourself the way the adversary does.** The campaign found victims by sweeping a small set of ports from the internet. Run the same external scan against your own ranges. Anything that answers on the relevant port is a candidate you must then version-check. How to Find Which of Your Admin Consoles Are Reachable From the Internet details this.
3. **Resolve the disagreements in the data.** Affected-version ranges often differ between the CVE record, the vendor advisory and CISA's note. The Strapi entry in this batch is a live example: NVD's configuration data and the advisory's "up to 4.5.5" do not match exactly. Verify against the build you actually run, and treat the broader range as the one to clear.
4. **Prove absence, then record it.** The deliverable is not "we applied the patch." It is "we searched for every instance using these methods, found these, and confirmed each is patched or decommissioned." That record is what lets you close the deadline honestly and answer the same question faster next time.
5. **Watch for the follow-on activity regardless.** Because the window between a KEV listing and your verification is itself a risk period, instrument detection for what a successful exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. leads to. How to Spot DCSyncDCSync🛡️A credential-theft technique in which an attacker impersonates a domain controller and asks a real one to replicate account data, including password hashes, over the normal Active Directory replication protocol. and Mailbox Harvesting After a Web Server Is Breached covers the post-exploitation signals this actor generated.

The strategic shift the catalogue represents

The deeper lesson of an all-old-CVE KEV batch is that the catalogue has outgrown its origins as a zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. feed. CISA will now attach a three-day deadline to a ten-year-old vulnerability the moment it has evidence of exploitation, and the implicit demand is that you can account for every instance of that component in your estate on short notice. An organisation that can only patch cannot meet that demand; an organisation that maintains an accurate, continuous inventory of its exposed services can. The campaign behind this batch succeeded not because its targets failed to patch, but because its targets did not know what they still had running. Closing that gap, the difference between managing known systems and knowing all your systems, is the real work a KEV deadline on an old CVE is asking you to do.