The Top Cloud Misconfigurations That Got Companies Breached in 2025

The Misconfiguration Problem

The cloud makes it incredibly easy to spin up infrastructure. It also makes it incredibly easy to misconfigure it. The 2025 Verizon DBIR found that misconfiguration was the leading cause of cloud breaches — not sophisticated exploits, not zero-days. Simple mistakes.

Here are the misconfigurations I see most often in security reviews — and the ones that led to real breaches.

1. Publicly Exposed S3 Buckets (Still Happening)

Yes, in 2026, S3 public access is still a top finding. The specific issue has evolved — AWS's account-level S3 Block Public Access controls have helped — but organizations still get burned by:

• Object ACL overrides on buckets where Block Public Access is enabled at the bucket level but not account level
• Signed URL over-sharing — generating pre-signed URLs with 7-day expiry for URLs that get forwarded in Slack
• S3 static website hosting on buckets containing sensitive files

Fix: Enforce S3 Block Public Access at the *organization* (AWS Organizations SCP) level. Use AWS Config rule s3-bucket-public-access-prohibited with auto-remediation.

2. Overprivileged IAM Roles (The Root Cause of Everything)

The most common IAM finding: service roles with *:* policies, or worse, a Lambda function that has AdministratorAccess.

Why does this happen? Developers get frustrated when their Lambda can't access the database, so they attach the admin policy and move on. Security never finds out.

# Find all roles with admin access in your account
aws iam list-roles | jq -r '.Roles[].RoleName' | while read role; do
  aws iam list-attached-role-policies --role-name $role |     jq -r --arg r "$role" '.AttachedPolicies[] | select(.PolicyName=="AdministratorAccess") | $r + ": ADMIN ACCESS"'
done

Fix: IAM Access Analyzer + AWS Config rule iam-no-inline-policy-check. Implement permission guardrails via SCPs. Use IAM Roles Anywhere for workloads, not long-lived access keys.

3. Secrets in Environment Variables

Lambda environment variables, ECS task definitions, and Kubernetes ConfigMaps are not secret stores. Yet I regularly find database passwords, API keys, and Stripe secrets sitting in plaintext environment variables — visible to anyone with iam:GetFunction or similar permissions.

Fix: AWS Secrets Manager or Parameter Store (SecureString). For Kubernetes, use External Secrets Operator syncing from Vault or AWS Secrets Manager. Add secret scanning (TruffleHog, GitGuardian) to your CI/CD pipeline.

4. Unrestricted Security Groups

Security groups with 0.0.0.0/0 ingress on port 22 (SSH), 3306 (MySQL), or 5432 (PostgreSQL) are still a top finding. This gives the entire internet a surface to attack.

Fix: AWS Config rule restricted-ssh and restricted-common-ports with auto-remediation. Use Systems Manager Session Manager instead of SSH — no open port needed. Enforce with SCPs.

5. CloudTrail Disabled or Logs Deleted

Security teams need CloudTrail to investigate incidents. Attackers know this — disabling CloudTrail or deleting logs is a common attacker technique to cover tracks.

Fix: Enable CloudTrail in all regions (including global services). Configure S3 log bucket with Object Lock (WORM). Set up CloudWatch alarm + SNS for DeleteTrail and StopLogging events. Forward to an immutable SIEM.

6. IMDSv1 Still Enabled

The AWS Instance Metadata Service (IMDS) is how EC2 instances get their credentials. IMDSv1 requires only an HTTP request to 169.254.169.254 — no authentication. Server-side request forgery (SSRF) vulnerabilities can steal credentials via IMDSv1.

IMDSv2 requires a pre-flight PUT request with a session token, neutralizing SSRF attacks.

Fix: Require IMDSv2 via account-level default in EC2 settings, and enforce via SCP:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringNotEquals": {
      "ec2:MetadataHttpTokens": "required"
    }
  }
}

Building a Systematic Defense

Individual fixes aren't enough. You need a continuous control plane:

1. CSPM (Cloud Security Posture Management) — Wiz, Orca, Prisma Cloud, or AWS Security Hub

2. SCPs — Preventive controls that make misconfigurations impossible

3. AWS Config with auto-remediation — Detective + corrective controls

4. Developer education — Security champions, internal wikis, Slack alerts when they misconfigure something

The goal is to make the secure path the default path, not an afterthought.