CISA added two vulnerabilities to the Known Exploited Vulnerabilities catalogue in late August 2026 that were not new. One was disclosed in 2023. The other was disclosed in 2019 — seven years before CISA confirmed it was being actively exploited.
The 2019 case
CVE-2019-1068, CVSS 8.8, is a remote code execution vulnerability in Microsoft SQL Server, published by NVD on 15 July 2019 and added to KEV on 26 August 2026. Per NVD, it exists because SQL Server "incorrectly handles processing of internal functions" — a description broad enough to have covered a genuine patch-and-forget vulnerability for the better part of a decade, until CISA's catalogue confirmed otherwise.
The 2023 case
CVE-2023-49105, CVSS 9.8, is an authentication bypass in ownCloud, published 21 November 2023 and added to KEV on 27 August 2026 — one day after the SQL Server entry. Per NVD, an attacker who knows a victim's username can access, modify, or delete any file without authentication, provided the victim has not configured a signing key. That precondition is the entire story: an unconfigured optional security feature is the only thing standing between "vulnerable" and "exploited," and three years after disclosure, CISA's catalogue confirms attackers found accounts where it was never configured.
Why "old CVE, low priority" is the wrong read of either one
Every vulnerability management programme built around severity scoring alone eventually produces the same blind spot: a bug that scored high on disclosure and generated no confirmed-exploitation signal for years drifts quietly down every prioritised list, not because the risk changed but because attention is finite and newer findings keep arriving. Both of these CVEs are the proof that "no confirmed exploitation yet" is a snapshot, not a permanent verdict.
Neither of these is exotic or obscure software. Microsoft SQL Server and ownCloud are both widely deployed, which means the population of organisations that could plausibly still be running an unpatched, years-old vulnerable version is not small — it's exactly the population that stopped tracking a CVE this old the moment it fell off whatever dashboard surfaced it originally.
What "confirmed exploited" likely means after this many years
CISA's KEV catalogue lists confirmed exploitation, not a theory about it — but the catalogue entry doesn't specify when exploitation began relative to the listing date, only that it has occurred. For a CVE this old, that ambiguity cuts in an uncomfortable direction: it is entirely possible that CVE-2019-1068 or CVE-2023-49105 have been quietly exploited for years, against organisations that never had the specific detection in place to notice, and only recently came to CISA's attention through a documented incident, a researcher's report, or a threat-intelligence finding surfacing well after the fact. Treating either listing as "just discovered" understates the plausible exposure window; treating it as "probably fine, it's old" is the opposite and equally unfounded error. The honest position is that the listing date tells you when confirmation arrived, not when the risk began.
What this means for how you should be tracking CVEs, not just which ones
A vulnerability's disclosure date is not an expiration date on its relevance. Both of these CVEs are proof that "this is old, surely someone patched it by now" is an assumption, not a fact — verify it rather than defer to it.
Optional security configuration is where old vulnerabilities hide longest. CVE-2023-49105's entire exploitability rests on a signing key nobody was required to configure. Any vulnerability whose mitigation is opt-in rather than default is a candidate for exactly this kind of multi-year gap between disclosure and confirmed exploitation.
Re-run vulnerability scans against your full inventory periodically, not only against new disclosures. A scan cadence built around "check new CVEs against what we run" will never surface a seven-year-old CVE landing in KEV for the first time — that requires checking old CVEs against current inventory too.
The dashboard problem, stated plainly
Most vulnerability-management tooling is built around a simple mental model: new CVE arrives, check it against inventory, remediate, close. That model has no natural mechanism for periodically re-checking CVEs that are already years old against an inventory that has changed since — new instances stood up, old ones migrated, configurations altered in ways that reintroduce an old precondition. A CVE that scored high on day one and generated no alerts afterward simply stops appearing on anyone's list, not because it was resolved, but because the tooling has no trigger to bring it back into view. CVE-2019-1068 and CVE-2023-49105 are what that gap looks like from the outside, years later, once CISA's own confirmation forces the question back open.
How Safeguard helps
Safeguard's continuous inventory does not age out a component's known vulnerabilities based on disclosure date — a CVE from 2019 is checked against current deployments with the same rigor as one from this week, which is exactly the gap that let both of these sit unaddressed for years in some environments. Reachability analysis on top of that inventory is what turns "we might still run an old vulnerable version somewhere" into a specific, checkable answer, before CISA's catalogue turns the question into an incident.
