The CISA Known Exploited Vulnerabilities (KEV) catalog is one of the best prioritization tools in security. It answers a question severity scores cannot: is anyone actually exploiting this? Many teams now patch KEV entries first, and they are right to.

But if your environment is mostly AWS, a KEV-driven program will spend its energy on a minority of your real risk. Most AWS account breaches start with a stolen key, an over-privileged role or an exposed setting, and none of those will ever get a CVE.

This post makes that case with published data, shows where KEV still matters in AWS, and proposes an “AWS KEV list”: the conditions attackers have demonstrably exploited, ranked the same way KEV ranks CVEs.

What can CISA KEV see in AWS, and what can’t it?

CISA adds an entry only when three conditions hold: the vulnerability has an assigned CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action such as a vendor-provided update. Those criteria make KEV precise. They also define what it leaves out.

No CVE, no entry. A CVE describes a flaw in a product. A leaked access key, a role with AdministratorAccess, or a bucket set to public is not a flaw in AWS; it is how the customer configured AWS. Those conditions fall outside the CVE system entirely, so they can never appear in KEV, no matter how often attackers exploit them.

Flaws in AWS itself rarely need you. For years, cloud providers refrained from disclosing vulnerabilities found and fixed in their services unless customer action was required. The CVE program’s rules changed in 2024 so that CNAs must not treat cloud technology as the sole basis for deciding whether to assign a CVE, and Microsoft and Google now publish cloud CVEs tagged exclusively-hosted-service when customers need to take no action. Even when such CVEs exist, there is nothing for you to patch.

The result is a clean split. KEV covers the software you run on AWS. It does not cover how you run AWS.

What actually breaches AWS accounts?

The best cloud-specific data comes from Google’s Threat Horizons reports, which classify how attackers first got into the cloud environments Google and Mandiant investigated:

Initial access vector H1 2025 H2 2025 Has a CVE?
Weak or absent credentials 47.1% 27.2% No
Misconfiguration 29.4% 21% No
Software exploitation Lower share 44.5% Usually

In the first half of 2025, the two non-CVE vectors accounted for about three quarters of cloud intrusions Google saw. Even in the second half, when software exploitation took the top spot for the first time, credentials and misconfiguration together still made up nearly half.

Other sources point the same way. Mandiant attributed 83% of initial access in platform-agnostic cloud and SaaS incidents to identity. Datadog found long-lived credentials to be the most common cause of publicly documented cloud breaches, and Rami McCarthy’s catalog of AWS customer security incidents is dominated by leaked keys, exposed secrets and over-permissive access rather than CVEs.

Google’s data is for Google Cloud, and AWS publishes no equivalent breakdown, so treat these as directional. The AWS case studies in the public record show the same thing. Uber in 2016 and the Codefinger S3 ransomware started with leaked keys. Even when a CVE came first, as in the 2024 LLMjacking case that began with a vulnerable Laravel app, the damage inside AWS was done with a stolen credential.

Where does KEV still belong in AWS?

None of this makes KEV irrelevant. Your EC2 instances, containers and Lambda functions run software with CVEs, and attackers are exploiting it faster than ever.

The share is rising. Google’s H2 2025 data put software exploitation at 44.5% of cloud initial access, overtaking weak credentials for the first time. Across all breaches, Verizon’s 2026 DBIR found vulnerability exploitation at 31% versus 13% for credential abuse.

The window is hours. React2Shell (CVE-2025-55182) is the clearest recent example. Within hours of its disclosure on December 3, 2025, Amazon threat intelligence observed exploitation attempts by China state-nexus groups including Earth Lamia and Jackpot Panda, using its MadPot honeypots. CISA added it to KEV two days later, with a federal patch deadline of December 26.

Patching lags. Verizon’s 2026 DBIR, as summarized by Tenable, found organizations fully remediated only 26% of KEV vulnerabilities, and the median time to patch grew from 32 to 43 days. Datadog found that 87% of organizations run at least one known exploitable vulnerability in deployed services.

And CVEs become credentials. The 2024 LLMjacking case shows how the two lists connect: a KEV-class bug in an internet-facing app gave the attacker a foothold, and the cloud credentials on that host gave them AWS. Patching the app would have stopped it; so would a role scoped to what the app needed.

So KEV belongs in your AWS program, aimed at internet-facing workloads. It just isn’t the whole list.

The AWS KEV list

KEV’s rule is simple: if it has been exploited in the wild, fix it first. Applied to AWS conditions instead of CVEs, the public record gives this list. Every entry has been exploited in a documented incident, and every entry can be checked today.

# Known-exploited condition Exploited in How to check
1 Long-lived IAM access keys Uber 2016, EleKtra-Leak, Codefinger aws iam generate-credential-report, then look for active keys older than 90 days; Datadog found 59% of IAM users have keys over a year old
2 Admin rights on a key or workload FortiGuard LLMjacking case, Sysdig 8-minute intrusion aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess; IAM Access Analyzer for unused access
3 Secrets in code, config or public files .env extortion campaign, keys in a public bucket Secret scanning on all repos and pipelines; confirm web servers never serve .env files
4 IMDSv1 allowed on EC2 Capital One 2019 aws ec2 describe-instances --filters Name=metadata-options.http-tokens,Values=optional
5 Internet-facing workload with a KEV CVE React2Shell, Laravel in the first LLMjacking case Vulnerability scanner filtered to KEV, limited to internet-reachable assets
6 S3 public access not blocked Close to 20 public breaches in 2022 aws s3control get-public-access-block --account-id <id> in every account
7 SSE-C allowed on buckets Codefinger ransomware Bucket SSE-C setting introduced in April 2026, or the AWS-published RCP
8 Unrestricted Bedrock invocation LLMjacking Identities allowed bedrock:InvokeModel; models not blocked by SCP, since Bedrock now enables models by default
9 Logging that attackers can see or switch off Attackers checking Bedrock logging before using a key aws cloudtrail get-trail-status --name <trail>; an organization trail protected by SCP

How to read it. The order follows the evidence: items 1 to 3 are identity, which drives the largest share of incidents; item 5 is where KEV itself plugs in. Items 6 to 9 are cheaper to fix than to argue about, and most are a single organization-level policy.

Putting both lists to work

The two lists don’t compete; they feed one queue. Every finding, whether a CVE from a scanner or a condition from a posture tool, goes through the same three questions:

  1. Is it known exploited? That means a KEV CVE, or a condition on the AWS KEV list above. Everything else follows your normal risk-based backlog.
  2. Is it exposed? An internet-facing workload, or a credential that exists outside AWS, such as a key in a laptop, a CI system or a repository.
  3. Does it lead to broad AWS access? A vulnerable host whose role can read every bucket, or a leaked key with admin rights, is a different problem from the same flaw behind a narrowly scoped role.

For timing, CISA’s binding directive gives federal agencies two weeks for newly added KEV entries, a reasonable baseline. The data argues for going faster when the answer to all three is yes: leaked keys have been used within five minutes, and React2Shell was exploited within hours.

AWS KEV triage flow: known exploited, then exposed, then broad AWS access; outcomes range from normal backlog to fix now.

The outcome timings other than the two-week KEV pace are suggestions; set them to match your own team’s capacity.

How to test the AWS KEV list

A posture scanner tells you whether a condition exists. It can’t tell you what happens when an attacker uses it: whether anything alerts, and whether a guardrail stops the next step. That is a separate question, and you answer it the same way for every item: run the attack in a sandbox and look.

cloud-firedrill tags its built-in scenarios with the list items they exercise, so you can see which items you have actually tested:

# Condition Scenarios that exercise it
1 Long-lived IAM access keys Backdoor access key on an IAM user; Bedrock API key creation blocked
2 Admin rights on a key or workload Backdoored role trust policy; stolen key that escalates its own rights
3 Secrets or data shared outside the account EBS snapshot shared with another account, in two regions
4 IMDSv1 allowed on EC2 Instance credentials stolen and used elsewhere
5 Internet-facing workload with a KEV CVE None: this one belongs to your vulnerability scanner
6 S3 public or external access not blocked Bucket policy backdoored for an outside account
7 SSE-C allowed on buckets SSE-C write blocked by the April 2026 default or by the RCP
8 Unrestricted Bedrock invocation LLMjacking access probe; invocation by an unapproved role blocked
9 Logging that attackers can switch off CloudTrail trail stopped

After a run, the trends command turns those tags into a coverage table per list item. The tag map is in the contrib/ folder of the repository:

firedrill run guardduty-gaps --expected-account 111111111111 --confirm
firedrill trends results.json --tag-map contrib/aws-kev-tags.yaml

An item counts as covered only when its scenarios come back DETECTED or PREVENTED. LOGGED means CloudTrail saw the attack and nobody would have been told.

Conclusion

KEV works because it replaces theoretical severity with evidence of real attacks. The same idea applied to AWS gives a different list, because the evidence in AWS points mostly at identity and configuration, which no CVE will ever describe.

Keep patching KEV CVEs on your internet-facing workloads, faster than the 43-day median. But put long-lived keys, admin-level permissions, exposed secrets and IMDSv1 on the same “known exploited” footing, because the public record says they are. A vulnerability program that only counts CVEs will report green while the most common AWS breach path stays open.

Sources

KEV and the CVE program

Breach and threat data

Incidents cited in the list