31 AUG 2026 — CISA's analysis of what actually gets exploited finds the top classes are improper input validation, path traversal and OS command injection. All three were well understood before most of the code running today was written.

What the data says

Improper input validation, catalogued as CWE-20, is the single most common weakness type across both the Known Exploited Vulnerabilities catalogue and registered CVEs. It accounts for 113 entries in KEV, about 7.6 per cent of the list.

Three of the top five KEV weaknesses are unfixed holes of that family: improper input validation, path traversal and OS command injection. Seven of the ten most frequent weaknesses on the KEV catalogue account for 41.5 per cent of its entries, and the analysis calls them stubborn.

CWE-20Improper input validation — 113 KEV entries, 7.6 per cent
41.5%Share of KEV held by just seven weakness types
7,701 → 21,019Injection CVEs, 2024 to 2025
Two datasetsKEV counts what is exploited; CVEs count what is reported

The growth figure needs handling with care

Injection weaknesses accounted for 7,701 CVEs in 2024 and 21,019 in 2025. That near-tripling is the number most likely to be quoted as evidence that software is getting worse.

It is not evidence of that. CVE issuance overall has grown steeply as the number of organisations authorised to assign identifiers has expanded and as automated discovery has scaled, so a raw year-on-year count measures reporting capacity as much as it measures defects. A category can triple in the record while the underlying rate of introduction stays flat, or even falls, if the denominator is growing faster than anyone is tracking.

Injection remains the largest category by a wide margin. The trend line within it is not something these counts can settle.

Why the two catalogues are not interchangeable

KEV and the CVE corpus get quoted in the same sentence and they answer different questions.

A CVE is a report that a flaw exists. KEV is a much smaller list of flaws with evidence of active exploitation, and inclusion triggers a patching obligation for United States federal agencies. The CVE list measures what has been found. The KEV catalogue measures what attackers have chosen to use.

The more useful finding is in that distinction. If a weakness class is common in the CVE record, it means researchers keep finding it. If it is common in KEV, it means attackers keep succeeding with it, which is a statement about deployed systems rather than about code quality in the abstract. Input validation tops both lists, and topping the second one is the part that should worry a defender.

Solved in principle is not solved in practice

In theory these classes should have been eradicated decades ago. That is true, and it says nothing about why they survive.

SQL injection has a complete solution that has been available since prepared statements existed: parameterise the query and the class disappears. OS command injection has one too, in the form of argument arrays that never construct a shell string. Path traversal is harder but tractable with canonicalisation and a resolved-path check. None of this is research. It is all in the manuals.

What survives is the code written before those practices were universal, which is a different problem from ignorance. A working application built in 2009 with string-concatenated queries does not rewrite itself because the industry reached consensus in 2012. It gets extended, wrapped in an API, moved to a container and put behind a load balancer, and the original query is still there.

So the persistence of these classes is largely a fact about the age and volume of deployed software rather than about what any current developer knows. The remedy that follows is unglamorous. Somebody has to find the specific constructs and replace them, which produces no features and therefore rarely gets funded.

The generated-code question this raises

There is a second mechanism worth naming, and it is new.

Models are trained on public code, and public code contains decades of the constructs described above. We reported that AI-generated code security has not improved in a year, holding at a pass rate near 56 per cent, and injection classes are prominent in what fails. A model reproducing the median pattern from its training corpus will reproduce the median vulnerability rate of that corpus.

That does not make generated code uniquely dangerous, because the median human-written line has the same provenance. It does mean the assumption that new code is safer code no longer holds automatically, and the classes CISA is describing are precisely the ones most likely to be regenerated.

What a defender should take from it

This analysis is most useful as an argument about prioritisation, and it cuts against the reflex to chase novelty.

Security attention follows the interesting, and the interesting is currently agentic attacks, model exploitation and supply-chain compromise. Those are all real threats, and none of them accounts for much of the volume. If seven weakness types account for 41.5 per cent of everything attackers are actually using, then a scanner configured for those seven, run against the oldest applications in the estate, will find more exposure than a programme built around this quarter's novel technique.

The timing argument reinforces it. We reported that most exploitation now lands within 48 hours of a proof of concept. Combine the two findings and the operational picture is uncomfortable. The flaws being exploited are old classes in old software, and the window to patch one of them once it becomes public is now measured in days.