Ten new entries, one 2015 bug still active
CISA added ten vulnerabilities to its exploited-bugs list in five days; two date to 2015 and 2019.
By The Signal · · 5 min read
Between August 24 and August 28, 2026, the Cybersecurity and Infrastructure Security Agency added ten vulnerabilities to its Known Exploited Vulnerabilities Catalog across four separate advisories. Two of those bugs — a Red Hat race condition and a Microsoft SQL Server flaw — were first assigned CVE numbers in 2015 and 2019. They are only now confirmed as actively exploited, more than a decade after the software shipped.
The number is ten, and it came in four batches
CISA runs the KEV Catalog as a running ledger, not a periodic report. An entry gets added the moment the agency has evidence — not suspicion, evidence — that a vulnerability is being exploited in the wild. On August 24, one addition: an access-control flaw in Oracle HTTP Server and the WebLogic Server Proxy Plug-in. On August 25, one more: a code-injection bug in Gitea, the self-hosted Git service popular with small engineering teams that don't want to pay for GitHub. On August 26, six at once, including that 2015 Red Hat race condition (CVE-2015-3246) and a 2019 Microsoft SQL Server remote vulnerability. On August 27, three more: an authentication flaw in ownCloud, an unspecified Linux kernel bug, and a path-traversal issue in JFrog Artifactory, the artifact repository many companies use to store compiled software before it ships.
Under Binding Operational Directive 26-04, issued this year to replace the prior BOD 22-01, federal civilian agencies don't get to file these away. The directive tells them to prioritize remediation specifically for KEV-listed bugs that grant "total control of the asset post-exploitation" on anything internet-facing, and — this is the newer part — to check whether an attacker already got in before the patch was applied. That second requirement matters because a patched server isn't a clean server. If the vulnerability was exploited last month, the patch closes the door after the burglar already has a key copied.
A ten-year gap is the whole point of the Register's framing
The Register's coverage of CISA's related commentary — that many of the most exploited vulnerability classes "should have been eradicated decades ago" — lands harder against this specific list than against an abstract one. CVE-2015-3246 is a race condition in libuser, a library Red Hat systems use to manage user and group accounts. It was disclosed and patched eleven years before this month's KEV addition. A patch existing for eleven years and an exploit surfacing anyway isn't a story about a hard problem. It's a story about unpatched systems still running in production somewhere, likely because upgrading touches something nobody wants to touch: an authentication chain, a legacy application, a system nobody currently owns.
Systemic gaps in Secure by Design adoption — the framework CISA has pushed vendors toward since 2023, asking them to ship products where the safe configuration is the default one — explain part of this, but not the patching gap specifically. Secure by Design is about what a vendor builds. This list is about what a customer runs. Those are different failures, and conflating them lets both sides point at the other.
The counter-argument: old CVEs reappearing isn't automatically alarming
There's a reasonable objection here. A vulnerability from 2015 showing up as "actively exploited" in 2026 doesn't necessarily mean it sat unpatched and undiscovered for eleven years. It can mean an attacker found a new way to chain it with something else — a race condition that was low-value alone becomes valuable paired with a privilege-escalation bug discovered last year, for instance, which is exactly the pattern with CVE-2015-5287, the companion Red Hat ABRT privilege-escalation flaw added the same day. Security researchers describe this as a supply of old, low-priority bugs that attackers keep in reserve, waiting for the second half of a working exploit chain to appear. The KEV addition date tells you when CISA got evidence of exploitation, not when the vulnerability became dangerous. That's a real distinction, and it means the "decades old" framing, while true, can also make patch discipline look worse than the underlying incident.
Still, that counter-argument doesn't fully clear the boards. A vulnerability sitting unpatched for a decade is a bigger attack surface regardless of when someone gets around to using it. The Artifactory and Gitea entries — both under two years old — show attackers moving fast on new software too. The old bugs and the new ones aren't competing stories; they're the same story told at two speeds.
The plumbing analogy holds because the fix is the same shape
Think of a building with old iron pipes behind new drywall. The pipes were replaced with code decades ago — the patch exists, free, published. But replacing them means opening the wall, and someone decided that risk and cost weren't worth it while the water still ran. The leak that finally floods the apartment below isn't news because the pipe was old. It's news because somebody chose not to open the wall. CISA's KEV list is the plumber's inspection report: it doesn't fix anything by itself, it just states, plainly, which pipes are currently leaking, so that whoever owns the building has to make the same choice again, this time with a deadline attached.
What ten entries change for agencies that don't run federal systems
BOD 26-04 legally binds only Federal Civilian Executive Branch agencies — the roughly 100 departments and sub-agencies under the executive branch's civilian umbrella. Everyone else, including the companies running the ownCloud instances, Gitea servers, and Artifactory repositories named this week, faces no legal remediation deadline. CISA's own advisory language asks them to "adopt risk-based vulnerability management" voluntarily. That's a request, not a rule, and it's the same request CISA has made with every KEV addition since the catalog started in 2021.
What happens next to these ten vulnerabilities is procedural and unglamorous: federal IT teams pull the list, cross-reference it against their asset inventories, and file remediation timelines against whatever internal deadline BOD 26-04 assigns based on the vulnerability's severity tier. For the Oracle and JFrog entries especially — both sitting on infrastructure that commercial software supply chains depend on — the more consequential number isn't in this week's advisory at all. It's how many non-federal organizations running the same software never see the list, because nobody requires them to look.