Over two working days at the end of August 2026, CISA added seven vulnerabilities to the Known Exploited Vulnerabilities (KEV) catalog. On 25 August it added one: CVE-2026-60004, a code injection flaw in Gitea, the self-hosted Git service, carrying a CVSS score of 9.8 and a remediation deadline of 28 August. On 26 August it added six more, including CVE-2026-8452 in Citrix NetScaler ADC and NetScaler Gateway — a memory-buffer flaw the vendor patched on 30 June that is now being exploited in the wild.
That is a normal week’s KEV traffic. What makes it worth stopping on is the composition of the list and the shape of the deadlines.
Four of the six additions on 26 August are old. Not last-quarter old. CVE-2015-3246 and CVE-2015-5287 are eleven years old. CVE-2019-1068 is seven. CVE-2021-23758 is five. CVE-2022-0995 is four. These are not zero-days; they are fully patched, long-documented defects that someone, somewhere, successfully attacked in 2026 — which is the only criterion for KEV inclusion.
And CISA did not treat the seven the same. It set 29 August for two of them and 9 September for the other four. A federal directive that has every incentive to keep its instructions simple deliberately produced a split deadline. That is a design decision, and private-sector programs should read it as one.
This article is about vulnerability debt: why decade-old CVEs land in an exploitation catalog in 2026, what the split deadline says about prioritisation methodology, why KEV binds the private sector in practice despite binding only federal agencies in law, and what a defensible KEV operating procedure looks like when an auditor or an insurer asks to see it.
The Seven Vulnerabilities
| CVE | Vendor / Product | Weakness | Year disclosed | FCEB due date |
|---|---|---|---|---|
| CVE-2026-60004 | Gitea | Code injection (CWE-94), CVSS 9.8 | 2026 | 28 Aug 2026 |
| CVE-2026-8452 | Citrix NetScaler ADC / Gateway | Improper restriction of operations within the bounds of a memory buffer (CWE-119), CVSS 8.8 | 2026 | 29 Aug 2026 |
| CVE-2019-1068 | Microsoft SQL Server | Remote code execution | 2019 | 29 Aug 2026 |
| CVE-2022-0995 | Linux kernel | Out-of-bounds write | 2022 | 9 Sep 2026 |
| CVE-2021-23758 | Ajax.NET Professional | Deserialization of untrusted data | 2021 | 9 Sep 2026 |
| CVE-2015-5287 | Red Hat Automatic Bug Reporting Tool (ABRT) | Privilege escalation | 2015 | 9 Sep 2026 |
| CVE-2015-3246 | Red Hat libuser | Race condition | 2015 | 9 Sep 2026 |
Read the table as two populations. The top two rows are current-generation software with live exploitation and near-immediate deadlines. The bottom five are the archaeology — unremediated defects sitting in production estates for years, unnoticed, until an attacker found them useful again.
Why Eleven-Year-Old CVEs Land in KEV in 2026
A CVE from 2015 appearing in an exploitation catalog in 2026 is not a story about attacker sophistication. It is a story about asset inventory.
Consider what the legacy entries actually are. libuser and ABRT are Red Hat Enterprise Linux components — packages that ship by default, are never named in a business requirement, and live on every RHEL and CentOS host whether anybody remembers deploying them or not. Both are local privilege escalation primitives: they do not get an attacker in, they turn a foothold into root, and CVE-2022-0995 in the Linux kernel has the same profile. CVE-2021-23758 is a deserialization flaw in Ajax.NET Professional, a third-party .NET library buried in an application somebody built years ago and now merely operates. CVE-2019-1068 means an unpatched SQL Server instance, and unpatched SQL instances are almost always instances nobody knew were there.
Every one of these is a survivorship case. They persisted because the system carrying them sat outside the remediation programme, and it sat outside the programme because it sat outside the inventory. The failure modes recur with dreary consistency:
- Unmanaged Linux estates. Windows fleets are usually swept by a management agent; Linux servers stood up by application teams, inherited through acquisition, or running a workload too fragile to reboot frequently are not. A 2015 privilege-escalation flaw survives precisely on hosts where nobody runs
dnf update. - Appliances and virtual appliances. Network appliances, storage controllers, and security devices run full operating systems the owner neither patches nor scans, on the theory that the vendor handles it. The vendor handles the firmware; the underlying OS packages ride along with whatever shipped.
- Embedded, OT, and vendor-managed systems. Devices with a twenty-year service life carry the software of their manufacture date for all of it, and a managed service provider patches only what the contract says it patches. The gap between “managed” and “patched” is where these CVEs live — a point examined further in our analysis of the N-able N-central patch bypass and MSP blast radius.
- Applications with dependency debt. Ajax.NET Professional is the archetype: nobody scans the application, they scan the server. The library is invisible to infrastructure tooling and out of scope for application tooling never pointed at legacy builds.
Underneath all four is the same control gap, and it is the first control in every major framework because everything else depends on it:
- CIS Controls v8, Control 1 (Inventory and Control of Enterprise Assets) and Control 2 (Inventory and Control of Software Assets) are numbered one and two deliberately. Control 7, Continuous Vulnerability Management, is arithmetically incapable of covering assets Controls 1 and 2 never enumerated.
- NIST CSF 2.0, ID.AM — ID.AM-01 (hardware inventoried), ID.AM-02 (software, services and systems inventoried), ID.AM-08 (systems managed across the lifecycle) — states the same dependency as an outcome.
- ISO/IEC 27001:2022 Annex A 5.9, Inventory of information and other associated assets, requires an accurate, maintained inventory with named owners. Annex A 8.8, Management of technical vulnerabilities, requires timely vulnerability information for systems in use, evaluation of exposure, and appropriate measures. An auditor reading A 8.8 alone sees a scanning schedule; an auditor reading it against A 5.9 sees whether the scanner’s target list matches the asset register.
That comparison is the audit test worth running on yourself. Diff your scanner’s authenticated-coverage list against your CMDB; the delta is your 2015 CVE population. If your scanner reports 100 percent coverage of a 4,000-asset inventory while the network carries 5,200 live addresses, the metric is measuring the inventory, not the estate.
The Split Deadline Is the Methodology Lesson
CISA gave four of the six additions a two-week clock and two of them a three-day clock. Same catalog, same day, same criterion for inclusion, different urgency. Why?
Because KEV inclusion establishes that exploitation is real; it does not establish that exploitation is urgent for you. The differentiators are exposure and impact. CVE-2026-8452 sits on internet-facing NetScaler Gateway and AAA virtual servers, is reachable pre-authentication, and yields code execution: publicly exposed, automatable, total system control. CVE-2019-1068 is a SQL Server RCE, and internet-reachable SQL instances are catastrophic where they exist. Both got three days. CVE-2015-3246 is a local race condition in libuser: real, exploitable, and useless to an attacker who has not already landed on the host. It got two weeks.
This is the logic of BOD 26-04, “Prioritizing Security Updates Based on Risk,” issued 10 June 2026, which supersedes both BOD 19-02 and the long-standing BOD 22-01 KEV regime. Where BOD 22-01 applied a flat clock to every KEV entry, BOD 26-04 combines four factors — public exposure, known exploitation (KEV status), automation potential, and technical impact (total versus partial control) — into tiered timelines: three days where a KEV vulnerability on a publicly exposed asset grants total control (with forensic triage in the most severe combination), fourteen days for standard KEV cases, sixty days for lower-risk combinations, and next upgrade or rebuild where no risk criterion is met. Agencies must be in full compliance with the timeline table by 7 December 2026. We covered the operational shape of that transition in the BOD 26-04 August 7 deadline and the Fortinet and Arista KEV additions.
The private-sector translation is the important part, and it is not “adopt CISA’s deadlines.” It is adopt CISA’s variables.
Most enterprise programmes still route on CVSS base score — “Critical in 30 days, High in 60.” That rule is indefensible on this week’s evidence. CVE-2026-8452 carries a CVSS of 8.8 — a High, not a Critical — and is being actively exploited against internet-facing appliances, with web shells dropped on compromised hosts. A 9.8 in an internal-only system with no public exploit and no observed exploitation is, on any honest accounting, the lower priority. A programme that patches the 9.8 first because the number is bigger has optimised for the wrong variable.
Two supplements make this operational and are worth naming explicitly in policy:
EPSS (Exploit Prediction Scoring System), maintained by FIRST, gives a daily-updated probability that a CVE will be exploited within 30 days. It is the right instrument for the enormous middle band of vulnerabilities not in KEV, where you have no evidence either way. Because the overwhelming majority of published CVEs score very low, it lets a team defensibly deprioritise thousands of findings while escalating the small population with meaningful probability. EPSS is a forecast, not a fact; KEV is a fact, not a forecast.
SSVC (Stakeholder-Specific Vulnerability Categorization), from CERT/CC and CISA, replaces a score with a documented decision tree — exploitation status, technical impact, automatability, and mission impact resolving to Track, Track*, Attend, or Act. Its underrated virtue is evidentiary: a written, repeatable rationale per decision. When an auditor asks why a KEV entry took 45 days rather than 14, “our SSVC assessment placed it in Track because the asset is not network-reachable and exploitation is not automatable” is an answer. “It was only an 8.1” is not.
Note that BOD 26-04’s four factors are, essentially, SSVC’s. That is not coincidence, and it is the clearest signal available about where regulator and auditor expectations are heading.
KEV Binds Federal Agencies. Everyone Else Is Bound Anyway.
BOD 26-04 is legally binding on FCEB agencies and nobody else. Treating that as the end of the analysis is a mistake that gets more expensive every year, because KEV has quietly become an infrastructure standard that reaches private organisations through at least five other channels:
Contract clauses. Federal flow-downs increasingly reference KEV directly, and commercial master services agreements have followed: “Supplier shall remediate any vulnerability listed in the CISA KEV catalog affecting systems used to provide the Services within [X] days of catalog addition” is now a routine ask in enterprise security addenda.
Cyber insurance. Underwriting questionnaires ask about KEV remediation timelines by name, and KEV status is what a claims adjuster reaches for after an incident: a breach traced to a CVE that sat in KEV, unpatched, past its published due date is the cleanest possible narrative for a coverage dispute over failure to maintain represented controls.
FedRAMP continuous monitoring. Cloud service providers report monthly under ConMon with defined remediation windows, and FedRAMP has aligned its expectations to the BOD 26-04 model. Any organisation selling SaaS to federal customers inherits this whether or not it thinks of itself as regulated.
PCI DSS 4.0. Requirement 6.3.1 obliges entities to identify and manage vulnerabilities using industry-recognised sources and assign risk rankings; 6.3.3 requires critical and high-security patches within one month of release; 11.3 governs scanning and rescanning until resolution. A KEV entry is by definition an industry-recognised source establishing active exploitation, and an assessor who finds a KEV-listed CVE unremediated on an in-scope system will not accept a low internal risk ranking as the reason. Enterprise buyers, meanwhile, now ask vendors for KEV remediation SLAs as routinely as they ask for SOC 2 reports.
Writing the KEV Clause Into Policy
Vague policy is unauditable policy. A defensible vulnerability management standard should state something close to the following, with your own numbers:
Vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalog are classified as Priority 1 regardless of CVSS base score. Priority 1 vulnerabilities affecting internet-facing assets, or any asset where exploitation grants administrative or total system control, shall be remediated or mitigated within 72 hours of catalog addition. All other Priority 1 vulnerabilities shall be remediated within 14 days. Where remediation is not achievable within the applicable window, a documented exception is required under Section [X], approved by the named system owner and the CISO or delegate, specifying compensating controls, a remediation date, and an expiry not exceeding 90 days.
Three properties make that clause work: it is tiered rather than flat, so it survives contact with reality; it is exposure-driven rather than score-driven; and it puts a named approver and a hard expiry on exceptions, which is the difference between a risk acceptance and a permanent hole with paperwork attached.
The NetScaler Case: Sixty Days Between Patch and Exploitation
CVE-2026-8452’s timeline deserves close reading because it is the entire edge-appliance problem in one sequence.
30 June 2026: Citrix discloses the flaw and ships fixed builds — 14.1-72.61, 13.1-63.18, and 13.1-37.272 — the same day. The advisory characterises the impact as memory overflow causing instability, which most readers would file as denial of service.
14 August 2026: watchTowr Labs publishes a technical analysis and proof-of-concept showing the flaw permits unauthenticated remote code execution, not merely a DoS. The real severity becomes public six weeks after the patch.
Shortly after 14 August: exploitation begins. Researchers document dozens of attempts from a dozen distinct attacker IPs across multiple countries, with web shells named x.php and z.php dropped on compromised appliances and discovery commands run to map the host.
26 August 2026: CISA adds it to KEV with a 29 August federal deadline.
Every organisation that patched NetScaler in early July was fine. Every organisation that read “denial of service,” decided it did not warrant an out-of-band change, and slotted it into the next quarterly maintenance window spent the second half of August running an internet-facing appliance with a public RCE proof-of-concept against it. Two conclusions follow.
First, initial severity characterisations are provisional. The gap between “instability” and “unauthenticated RCE” was closed by third-party research, not the vendor advisory. A programme that treats a vendor’s first-day impact statement as final is deciding on data with a known revision rate. For internet-facing infrastructure, the safe default is to patch on availability, not on severity assessment.
Second, “we patch quarterly” is not a policy for an internet-facing appliance; it is a statement about acceptable dwell time. A quarterly cycle means an expected exposure window of roughly 45 days and a worst case of 90. Set that against the pattern of recent years: edge devices — VPN concentrators, application delivery controllers, secure gateways, file transfer appliances, firewalls — have been the dominant initial-access vector for both ransomware affiliates and state-aligned intrusion sets. They are internet-facing by design, terminate authenticated sessions, sit at the boundary with reach into internal segments, are frequently excluded from EDR coverage, and are rarely rebooted willingly. The Verizon DBIR 2026 data on exploitation as an initial access vector makes the same point at population scale.
If your change management process cannot accommodate an emergency patch to an edge appliance inside 72 hours, that constraint — not your patching SLA — is your actual security posture, and it should be recorded as a risk with an owner rather than assumed away.
Gitea and the Developer Infrastructure Nobody Owns
CVE-2026-60004 is the week’s other instructive case. Gitea is a lightweight self-hosted Git service, patched in version 1.27.1 in late July. The flaw lets an attacker with repository write access submit a crafted patch to the diffpatch API endpoint, planting an executable Git hook that runs shell commands as the Gitea service account. It reached KEV on 25 August, with at least one documented incident in which an exposed instance was compromised and used to run crypto-mining software.
Gitea instances are not usually procured. They appear. A team wants a lightweight repository host, someone runs a container, it works, and three years later it holds source code, CI credentials, deployment keys, and signing material — while appearing in no CMDB, no scan scope, and no patch schedule. The compromise path is short: a low-privilege developer account or a stolen token becomes command execution on a host holding the credentials to your build pipeline.
The generalised failure is that developer infrastructure is production infrastructure. Treating it as a team-level convenience means the assets holding your source code and deployment credentials are governed less rigorously than your file servers. Self-hosted CI runners, artifact registries, secrets managers, internal package proxies, and Git hosts all belong in the same inventory, under the same patch SLA, as anything else. We made the parallel argument about self-managed AI and compute infrastructure in the analyses of the Ray KEV addition and shadow compute infrastructure and Langflow CVE-2026-9198 and AI orchestration blast radius; the pattern is identical and the remedy is the same.
A KEV Operating Procedure
The following is the minimum viable process that turns KEV from a news feed into a control an assessor can test.
1. Ingest the catalog daily, automatically. CISA publishes KEV as JSON and CSV at a stable URL. Pull it on a schedule rather than relying on someone reading an alert email, and record the retrieval time — that timestamp proves your clock started when it should have.
2. Match automatically against the asset inventory. New entries should be diffed against your CPE/software inventory and scan data within hours, producing a candidate affected-asset list without human intervention. This step is only as good as your inventory, which is why Controls 1 and 2 come first.
3. Triage on exposure and impact, not score. For each match, record the four BOD 26-04 factors and assign the SLA tier your policy defines. Keep the reasoning; it is the audit artifact.
4. Escalate on a defined trigger, not on judgement. A KEV entry on a publicly exposed asset with total-control impact should automatically open an emergency change record and page the system owner. If escalation waits on someone deciding it is bad enough, it will be slow on the day it matters.
5. Run an exception process with teeth. Every exception needs the affected assets, the reason remediation is not possible, the compensating controls actually implemented (not proposed), a named approver with authority, and a hard expiry. Expired exceptions must reopen automatically; a register with no expiries is a list of accepted breaches.
6. Verify remediation independently. Close findings on rescan evidence, not ticket status. PCI DSS 11.3 requires rescanning until resolution for a reason, and the requirement generalises.
7. Keep the evidence an auditor or insurer will ask for. The KEV ingestion log with timestamps; the matched-asset list per entry; per-CVE timelines showing catalog-addition, detection, and closure dates; SLA compliance metrics by tier over a rolling period; the current exception register with approvers and expiries; and evidence of inventory reconciliation — scanner coverage against asset register, with the delta explained. That last artifact is the one almost nobody has, and the one that answers the question every other artifact begs.
Conclusion
The Gitea and NetScaler entries are this week’s news. The four legacy CVEs are the diagnosis. A 2015 privilege escalation flaw in a default Red Hat package does not reach an exploitation catalog in 2026 because attackers got cleverer; it reaches it because somewhere there are production hosts no inventory lists, no scanner reaches, and no patch cycle touches — and an attacker already on one of them found a decade-old tool that still worked.
CISA’s split deadline says the rest. Faced with seven exploited vulnerabilities, the agency best placed to apply one uniform rule instead sorted them by exposure and impact. That is the methodology demonstrated rather than described: exploitation status decides whether something is in scope, exposure and impact decide how fast. A programme still routing on CVSS severity bands is using a variable CISA has visibly stopped using — and will one day have to explain that to an auditor, an underwriter, or a regulator, most likely after the fact.
The organisations that will handle the next KEV addition well are not the ones with the fastest patching. They are the ones that already know what they own.
Sources: CISA — CISA Adds Six Known Exploited Vulnerabilities to Catalog, CISA — CISA Adds One Known Exploited Vulnerability to Catalog, CISA — BOD 26-04: Prioritizing Security Updates Based on Risk, The Hacker News — CISA Adds Six Exploited Flaws to KEV, Infosecurity Magazine — CISA Warns of Six Exploited Flaws in Microsoft, Linux and Citrix, Help Net Security — Previously patched Citrix NetScaler flaw exploited in the wild (CVE-2026-8452), Help Net Security — Critical Gitea vulnerability now exploited in the wild (CVE-2026-60004), Citrix — NetScaler ADC and NetScaler Gateway Security Bulletin CTX696604, Tenable — What is CISA BOD 26-04
This article is provided for informational purposes only and does not constitute legal advice.
