CISA KEV August 2026: Why Decade-Old CVEs Are Suddenly Exploited Again

The August 26 Batch: Six New Entries, One From 2015

On August 26, 2026, CISA added six vulnerabilities to the Known Exploited Vulnerabilities catalog, spanning Red Hat, the Linux Kernel, Ajax.NET Professional, Microsoft SQL Server, and Citrix NetScaler (CISA). Half of the six affect Linux components (Cybernews), and the batch includes a Microsoft SQL Server remote code execution flaw first disclosed back in 2019 (Acunetix) alongside a Red Hat privilege escalation bug that traces back to 2015 (CVE.org, Red Hat).

That second detail is the one worth sitting with. A vulnerability disclosed more than a decade ago is being actively exploited in the wild today, and CISA cared enough to add it to a catalog that exists specifically to flag confirmed, real-world exploitation. Not theoretical risk. Not a researcher's proof of concept. Attackers are using it right now, in 2026, against systems that were supposed to have been retired or patched years ago.

A Month of Additions, Not a One-Off

August 26 wasn't an isolated alert. CISA published KEV updates on August 3 (one vulnerability), August 11 (three vulnerabilities), August 18 (four vulnerabilities), August 20 (two vulnerabilities), and then the six-vulnerability batch on August 26. That's five separate KEV updates in a single month, touching Linux, Windows, network appliances, and web frameworks. If you manage patching for more than a handful of clients, you spent August chasing a moving target across nearly every platform you support.

CISA's binding directive process gives federal civilian agencies a hard deadline to remediate catalog entries. Everyone else, meaning most MSP clients, treats KEV inclusion as a strong signal rather than a legal mandate. That gap between "must fix" and "should fix" is exactly where legacy systems survive.

Why a 2015 Bug Is Suddenly a 2026 Problem

Here's the mechanism analysts keep circling back to: attackers don't need a fresh zero-day when a decade-old, well-documented vulnerability still works. The exploit code is mature, the technical writeups are public, and the barrier to entry is low. What changed isn't the vulnerability. What changed is that scanning at scale finally found the systems that never got patched.

Defenders, meanwhile, tend to deprioritize old CVEs precisely because they assume the fix shipped years ago. That assumption holds for the systems everyone remembers. It does not hold for the RHEL server someone spun up for a project that ended in 2019, or the SQL Server instance a departed employee stood up for a reporting job nobody documented. These are the systems vulnerability scanners never see, because vulnerability scanners can only assess what's on the asset list. One recent analysis of this exact KEV batch called it a story about "vulnerability debt" rather than a single bad patch cycle, and that framing is accurate (ComplianceHub). Debt compounds. Interest is exploitation.

What This Means If You're an MSP

The practical guidance circulating this month lands on a phrase worth repeating to clients: patch, then assume compromise (Pro IT NW). Patching alone answers "is this system still vulnerable." It does not answer "was this system already touched before we patched it." For any KEV entry with a public exploit and a multi-year disclosure history, assume some percentage of unpatched instances were already probed, and check accordingly.

For the assets you do know about, the fundamentals still apply: cross-reference the KEV catalog against your managed inventory, prioritize by confirmed exploitation status rather than raw CVSS score, and push emergency patches for NetScaler, SQL Server, and any exposed Linux kernel component before month-end maintenance windows. NetScaler in particular has a history of being both internet-facing and slow to patch across client environments, which makes it a repeat guest on KEV updates.

The harder problem is the asset you don't know about. You cannot patch a system that never made it into your CMDB. You cannot schedule remediation for a SQL Server instance nobody told you exists. This is where most MSPs hit a wall that better ticketing software doesn't solve, because the problem isn't process, it's visibility.

The Compensating Control: Detection That Doesn't Need the Patch List

Asset inventory gaps are permanent. Shadow IT gets created faster than it gets documented, decommissioned servers get forgotten instead of deleted, and every acquisition or reorg adds infrastructure nobody fully mapped. No scanning cadence closes that gap completely.

What does close it is watching behavior instead of watching a list. A forgotten RHEL box exploited through a decade-old privilege escalation flaw doesn't just sit there quietly. It generates anomalous process activity, unusual authentication patterns, and lateral movement attempts toward the rest of the network. A shadow SQL Server instance being exploited via that 2019 remote code execution flaw produces the same kind of telemetry signature that any actively attacked database produces, regardless of whether it was ever on anyone's patch schedule.

Where Vijilan's Global SOC Fits

This is the layer Vijilan operates at. Our Global SOC works from log and telemetry, ingesting from platforms like CrowdStrike Falcon, Microsoft Sentinel, and Defender across the environments we monitor. That means detection isn't gated on whether an asset was inventoried, scanned, or patched on schedule. If a system generates privilege escalation behavior, unusual lateral movement, or command execution consistent with active exploitation, it shows up in the telemetry whether or not it was ever on a spreadsheet.

Through ThreatRespond™, our Managed XDR service, that anomalous activity gets triaged and, where the client's containment posture allows it, acted on through ThreatContain™, not just logged for someone to review next week. For partners running proactive threat hunting engagements, ThreatHunt™ analysts specifically look for the kind of dormant, long-lived footholds that decade-old CVEs create, the exact profile of this month's KEV additions. And for MSPs building out log management and alerting without a full XDR deployment, Vijilan Guard provides the monitoring layer that catches this activity even on infrastructure the client's own team has lost track of.

The honest version of this pitch is simple: patch management tells you what you should fix. It cannot tell you what's already been touched on a system it doesn't know exists. Detection at the telemetry layer can. That's the gap between an asset inventory and a security operation, and it's the gap that turns a decade-old CVE from a headline into a contained incident instead of a quiet foothold.

If you're an MSP evaluating how to close that visibility gap for clients without adding headcount, our MSP partner program is built exactly for this, and we never compete with our partners for their clients. Pricing questions have a straight answer at our pricing page.

Frequently asked questions

What vulnerabilities were added to the CISA KEV catalog on August 26, 2026?

CISA added six vulnerabilities affecting Red Hat, the Linux Kernel, Ajax.NET Professional, Microsoft SQL Server, and Citrix NetScaler. Half of the additions were Linux-related, and the batch included flaws with disclosure histories going back to 2019 and 2015.

Why are decade-old CVEs being exploited now instead of when they were first disclosed?

Attackers scan broadly for any unpatched instance of a known vulnerability, and mature, well-documented exploits for old CVEs are easy to weaponize at scale. Defenders often assume old vulnerabilities were remediated long ago, which leaves forgotten or undocumented systems as the last exposed targets.

How should an MSP prioritize patching after a KEV update like this?

Cross-reference the catalog against your managed asset inventory, prioritize internet-facing and high-value systems like NetScaler and SQL Server first, and treat confirmed exploitation status as a stronger signal than CVSS score alone.

What can be done about legacy or shadow assets that were never inventoried?

Since these assets can't be patched on a schedule nobody knows to create, detection has to work at the log and telemetry layer instead of relying on asset lists. Anomalous behavior like privilege escalation or lateral movement will still surface even from systems that were never formally tracked.