Infra Audit6 min readUpdated November 4, 2026

The Most Common AWS Misconfiguration Is One Line

We mapped every publicly disclosed AWS incident with a known root cause. The same handful of one-line mistakes explains almost all of them.

The recurring pattern is a resource policy with Principal *: buckets, KMS keys, ECR repos, SNS topics, Lambda URLs. One line grants the world access, and scanners rarely flag the non-S3 ones.

We went through the public record: ramimac's catalog of disclosed AWS incidents from 2014 to 2024, plus the 2026 cases Sysdig, Truffle Security and others documented. The same shapes repeat. A bucket policy with Principal * (LA Times 2018, Twilio 2020, PREMINT 2022). A shared snapshot (Imperva 2019, DNC 2016).

See How We Work

In This Guide

The pattern behind the incidents

We went through the public record: ramimac's catalog of disclosed AWS incidents from 2014 to 2024, plus the 2026 cases Sysdig, Truffle Security and others documented. The same shapes repeat. A bucket policy with Principal * (LA Times 2018, Twilio 2020, PREMINT 2022). A shared snapshot (Imperva 2019, DNC 2016).
We went through the public record: ramimac's catalog of disclosed AWS incidents from 2014 to 2024, plus the 2026 cases Sysdig, Truffle Security and others documented. The same shapes repeat. A bucket policy with Principal * (LA Times 2018, Twilio 2020, PREMINT 2022). A shared snapshot (Imperva 2019, DNC 2016). A leaked key with no rotation (FTX 2022). A world-readable ECR repo. None of these required a zero-day. Each was one line of config.

The one-line killers, by blast radius

iam:PassRole with Resource *: whoever holds it becomes any role in the account. NotAction in a policy: written as everything except X, read as everything. A cross-account KMS key policy: the other account decrypts everything behind the key. An S3 event notification to an external account: every new file leaves quietly.
iam:PassRole with Resource *: whoever holds it becomes any role in the account. NotAction in a policy: written as everything except X, read as everything. A cross-account KMS key policy: the other account decrypts everything behind the key. An S3 event notification to an external account: every new file leaves quietly. SSM Session Manager without logging: shell access with no trace. CloudTrail in one region: half the world's events unlogged. An open ECR policy: your images, including baked secrets, world-readable.

Why scanners miss them

Most tools check CIS benchmarks, which cover the famous ones and skip the quiet ones. NotAction, PassRole wildcards, cross-account KMS and SNS publish policies are not in the standard checklists. They live in resource policies that scanners rarely enumerate.
Most tools check CIS benchmarks, which cover the famous ones and skip the quiet ones. NotAction, PassRole wildcards, cross-account KMS and SNS publish policies are not in the standard checklists. They live in resource policies that scanners rarely enumerate. The audit skill checks each one with a dedicated command, because each has a documented incident behind it.

The fix is also one line

Every one of these is fixed by editing one line: scope the Principal, remove the wildcard, enable multi-region, add the log group. The hard part is knowing which line, and proving it is actually fixed.
Every one of these is fixed by editing one line: scope the Principal, remove the wildcard, enable multi-region, add the log group. The hard part is knowing which line, and proving it is actually fixed. That is what the read-only audit does: finds the line, cites the incident, and re-verifies after the fix with the same command.

4 Tips to Get Started

1

Search every resource policy for Principal *, not just S3. KMS, ECR, SNS and SQS have the same trap.

2

iam:PassRole with Resource * is the privilege escalation line. Anyone with it can become any role in the account.

3

NotAction in a policy means everything except X. Read it twice; it usually grants more than intended.

4

One CloudTrail region means half your events are unlogged. Multi-region is one checkbox.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Related Guides

Is My S3 Bucket Public? How to Check in One Command

One command tells you if your S3 bucket is public, and one curl proves it. The policy check shows intent, the anonymous request shows reality.

Terraform State File Leak: Every Secret in Plaintext

terraform.tfstate stores database passwords, IAM keys and TLS private keys in plaintext. sensitive=true hides nothing. Here is how leaks happen and the check.

Docker Socket Mounted in a Container: Root on the Host, No Exploit Needed

A container with /var/run/docker.sock mounted controls the host daemon and can mount your entire filesystem. No kernel exploit required. Here is the mechanism and the check.

pull_request_target: The GitHub Actions Trigger That Leaks Secrets

pull_request_target runs your workflow with its secrets on attacker-controlled PR code. One checkout line turns a fork PR into a credential leak.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

What is the most common AWS misconfiguration?

Public S3 buckets and over-broad IAM policies. The pattern behind most disclosed incidents: a resource policy with Principal *, an IAM key committed to a repo, or a snapshot shared to another account. Each is one line of config with account-wide blast radius.

Why is iam:PassRole with Resource * dangerous?

It lets any principal holding it assume any role in the account, including admin roles. An attacker with a modest set of permissions plus this line escalates to full control. It is the classic user-to-admin escalation and almost no scanner highlights it.

How do I find these lines in my account?

A read-only audit: list every resource policy and every identity policy, and grep for Principal *, Resource *, NotAction, and cross-account principals. The roqy audit skill ships these checks with the exact commands and a verdict model.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.

See How It Works