Cloud Misconfiguration Top 10 — 2026 Edition

Published May 19, 2026 · By AxVeil Cloud · 15 min read

Misconfiguration remains the single largest contributor to public cloud breaches in 2026. Verizon's 2025 DBIR pegged it at 38% of cloud-related incidents; our own engagement data is even higher because we count IAM trust-chain errors that DBIR rolls into "credential abuse". The list below ranks the ten misconfigurations we find most often in production at customers across AWS, Azure, and GCP, with the detection query you can run today and the Terraform-ready fix that closes the gap. Pair it with our cloud pentesting methodology when you scope your next engagement.

The ten, ranked by 2026 breach frequency

1. Over-permissive IAM — the wildcard problem

The single most common AWS finding: an IAM policy with Action: "*" or Resource: "*" attached to a workload that does not need it. The chain looks like: developer ships a Lambda, attaches AdministratorAccess to ship fast, never re-scopes. An SSRF or compromised dependency now hands an attacker the keys to the account.

# Detect over-permissive policies (AWS CLI)
aws iam list-policies --scope Local --query \
  'Policies[].PolicyArn' --output text | \
  xargs -n1 -I{} aws iam get-policy-version --policy-arn {} \
    --version-id v1 --query 'PolicyVersion.Document' | \
  jq -r 'select(.Statement[]?.Action == "*" or
              .Statement[]?.Resource == "*")'

# Prowler check
prowler aws --checks iam_policy_no_administrative_privileges

Fix: use IAM Access Analyzer to generate least-privilege policies from CloudTrail history. Re-scope quarterly. Block AdministratorAccess attachment to service principals via SCP.

2. IMDSv1 still enabled on EC2

IMDSv2 has been generally available since 2019 and required-by-default for new instances since 2024, but old launch templates and AMIs still spin up with IMDSv1. The Capital One breach (2019) and most SSRF-to-cloud-credentials chains depend on IMDSv1's lack of session token requirement.

# Find instances with IMDSv1 enabled
aws ec2 describe-instances --query \
  'Reservations[].Instances[?MetadataOptions.HttpTokens==`optional`].
   [InstanceId,Tags[?Key==`Name`].Value | [0]]' --output table

# Terraform fix
resource "aws_instance" "app" {
  # ...
  metadata_options {
    http_tokens                 = "required"  # IMDSv2 only
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

3. Public storage buckets (S3, Azure Blob, GCS)

AWS S3 Block Public Access is on by default since 2023, but the ten-year-old buckets in your account were created when it was not. Azure Storage and GCS still allow anonymous read containers behind a single misclick.

# AWS - find buckets without Block Public Access
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  xargs -n1 -I{} sh -c 'aws s3api get-public-access-block \
    --bucket {} 2>/dev/null || echo "{} MISSING"'

# Azure - find anonymous-read containers
az storage account list --query "[].name" -o tsv | \
  xargs -n1 -I{} az storage container list --account-name {} \
    --query "[?properties.publicAccess!=`null`]"

4. Unscoped OIDC trust for CI/CD

GitHub Actions, GitLab CI, CircleCI and Buildkite all federate to AWS / Azure / GCP via OIDC. The common mistake: the trust policy accepts any repo, any branch, or any subject in the OIDC token. One compromised public-fork PR run lands a workload identity in your production account.

# Bad - accepts any GitHub repo
"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:*"
  }
}

# Good - locked to one repo, main branch
"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:sub":
      "repo:acme/api:ref:refs/heads/main",
    "token.actions.githubusercontent.com:aud":
      "sts.amazonaws.com"
  }
}

5. KMS key policies that grant kms:Decrypt with wildcard

A KMS key policy with Action: kms:Decrypt and Principal: "*"(even with no Condition) is reachable from any IAM principal that has matching permissions on its own side. Cross-account key policy review is the fastest way to find broken envelope encryption.

aws kms list-keys --query 'Keys[].KeyId' --output text | \
  xargs -n1 -I{} aws kms get-key-policy --key-id {} \
    --policy-name default --query Policy --output text | \
  jq -r 'select(.Statement[]?.Principal == "*" or
              .Statement[]?.Principal.AWS == "*")'

6. Internet-exposed databases

RDS, Cloud SQL, Azure SQL with public IPs and 0.0.0.0/0 in the security group / firewall. Shodan finds ~150,000 of these on any given day in 2026. Encryption-in-transit and a long password are not a substitute for not having a public IP.

# AWS - publicly accessible RDS
aws rds describe-db-instances --query \
  'DBInstances[?PubliclyAccessible==`true`].
   [DBInstanceIdentifier,Engine,Endpoint.Address]' \
  --output table

# GCP - Cloud SQL with public IP and 0.0.0.0/0
gcloud sql instances list --filter="settings.ipConfiguration.\
  ipv4Enabled=True AND settings.ipConfiguration.\
  authorizedNetworks.value=0.0.0.0/0"

7. Disabled or unmonitored audit logs

CloudTrail organisation trail off, GuardDuty disabled in non-primary regions, Config Recorder not recording, Azure Activity Log retention < 90 days, GCP Audit Logs without Data Access events. Each one renders forensics impossible after an incident; together they make CERT-In or SEC reporting a guessing game. See our CERT-In six-hour rule guidefor the retention obligations that bite Indian operators.

8. Default service-account permissions on Kubernetes

EKS / AKS / GKE pods that mount the default service account token (no IRSA / Workload Identity binding) inherit the cluster's default ServiceAccount role. Combined with cluster-admin role bindings from quickstart guides, a compromised container often has cluster-wide read.

# Find pods using default SA
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.serviceAccountName == null or
         .spec.serviceAccountName == "default") |
         "\(.metadata.namespace)/\(.metadata.name)"'

# Block via PodSecurityPolicy / PSA / Kyverno
# Force every workload to declare a non-default SA

9. Cross-account roles trusting whole accounts, not specific principals

A common AWS finding: an IAM role with AssumeRolePolicyDocument trusting arn:aws:iam::111122223333:rootwith no external ID. Any principal in account 111122223333 can assume the role. If 111122223333 is a partner's account, you have just delegated trust to every user, every CI job, and every compromised credential in that account.

# Good - specific principal + external ID
{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/PartnerIntegration"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "x9aV7kLpQ-tenant-acme-v2"
    }
  }
}

10. Container image / function package secrets

Docker image layers, Lambda environment variables, and Cloud Run service configs are still the number-one source of leaked credentials we find during cloud pentests. The fix is not just "use a secret manager" — it is "scan every image and every config in CI and block on a hit". TruffleHog, Gitleaks, and your CSPM's container scanner all cover this.

Mapping to compliance and frameworks

Tie each of the ten into your NIST CSF 2.0 Profileso progress on cloud posture rolls up to the same dashboard your board reviews.

Operating model — close the loop

A list of misconfigurations is only as useful as the operating model that fixes them. The pattern we recommend at AxVeil:

• Preventive. Terraform modules with secure defaults. PR-time policy gates (OPA, Checkov, tfsec, Sentinel).
• Detective. CSPM running 24x7 with Slack/Teams alerts on Critical findings within 15 minutes.
• Corrective. Auto-remediation for well-defined cases (public S3 -> Block Public Access flip; over-broad SG -> restrict to last-seen source IP range).
• Validation. Quarterly VAPT includes an authenticated cloud configuration review. Annual red team probes the IAM trust graph end-to-end.

Tools that help with the everyday tuning: CVSS calculatorto score newly-found exposures, and a CSPM platform of your choice. For SaaS-specific cloud postures, see our SaaS industry guide.

FAQ

Further reading

• AWS Pentesting Methodology
• Cloud Pentesting Methodology
• Supply Chain Attacks — 2026
• Glossary: CSPM