By Olivia Harper. Fact-checked against 2025–2026 cloud security research, OWASP and CISA guidance, provider documentation and public breach reports.
One kind of cloud misconfiguration, storage left open to the public, exposed 535,480 buckets to anyone, according to research published in May 2026 by Mysterium VPN. Together they held nearly 20 billion files, including 685,047 credential and key files, all reachable without a login or an exploit.
Nobody hacked those storage services. They worked as designed, and customers set them up wrong. That’s what separates a cloud security misconfiguration from a software flaw, and it’s why these mistakes keep causing breaches years after providers switched to safer defaults.
This guide explains what counts as a misconfiguration, the most common ones on AWS, Azure and Google Cloud in 2026, and how to check and lock down your own cloud security setup.
What Is a Cloud Misconfiguration?
A cloud misconfiguration is any setting, permission or policy that leaves a cloud resource more exposed than its owner intended. It sits on the customer’s side of the shared responsibility model, needs no software bug for an attacker to use, and usually takes one change to fix.
The misconfiguration meaning is plainer than the jargon suggests: the cloud did exactly what you told it to, and the instruction was wrong. Three everyday examples:
- A storage bucket made public “for a quick test” and never switched back
- An admin account with full access and no MFA
- Audit logging turned off to cut costs, so an intruder leaves no trail
How is that different from a software flaw? A vulnerability tracked as a CVE lives in the vendor’s code, and you wait for a patch. A misconfigured setting lives in your own account, and no patch will ever arrive. Security teams often reduce the misconfiguration definition to one test: if you can fix it from the console or in code, it’s your misconfiguration to fix.
Why Do Misconfigurations Still Happen When Cloud Defaults Are Safer?
Safer defaults fix only what gets created after they arrive. Most companies also run years of older resources, make manual changes under pressure and have accounts nobody fully tracks.
Each of those lets risky settings back in, which is why providers’ improvements haven’t ended cloud misconfiguration breaches.
What Did AWS, Azure and Google Cloud Change?
All three major providers have made their defaults safer in the past few years:
- April 2023 (AWS): new S3 buckets arrive with Block Public Access turned on and access control lists (ACLs) disabled.
- 2023 (Azure): new storage accounts ship with anonymous blob access turned off.
- May 3, 2024 (Google Cloud): every new organization gets seven organization policies enforced. These include a block on creating service account keys and a requirement for uniform bucket-level access on Cloud Storage.
Notice the word “new” in every line. None of these changes reached back to buckets, storage accounts or organizations created earlier, and none stops an admin from switching a setting off later. That’s where many gaps in cloud security now sit: in the older half of your environment.
How Does Configuration Drift Creep Back In?
At 2 a.m., a production app loses its database connection. The on-call engineer opens the console, widens a security group to 0.0.0.0/0 and the alerts stop. Everyone goes back to bed. The Terraform file still says that the port is closed, and nobody updates it.
That mismatch between code and the live cloud is configuration drift, and it builds up in three other ways:
- Copy-pasted modules: a Terraform snippet from an old project or a forum post brings its open settings along.
- Unmanaged legacy services: a test environment or a retired app’s storage that no team owns. With no owner, there are no reviews, and that’s a leading cause of security gaps in unmanaged cloud services.
- Shadow accounts: a team opens a cloud account on a company card, outside your organization and its guardrails.
One habit stops most configuration drift: any change made in the console gets written back to code within a day, or rolled back.
What Are the Most Common Cloud Misconfigurations in 2026?
Weak identity controls and missing logging top the list on every major cloud. The clearest current data comes from Intruder’s 2026 Cloud Security Index, which tracked cloud misconfigurations across 3,000 organizations on AWS, Azure and Google Cloud over the 12 months to July 2026.
The Cloud Security Alliance published it in September 2026. The figures below show the share of accounts affected.
AWS
AWS accounts had the highest rates in five of the six categories. Two of its five most common AWS misconfigurations involve an S3 bucket misconfiguration:
| Misconfiguration | % of accounts | Why it matters |
|---|---|---|
| S3 doesn’t enforce HTTPS | 87% | Data can travel unencrypted if a client connects over plain HTTP |
| Permissive network ACL ingress to sensitive ports | 84% | SSH, RDP or database ports accept traffic from wider ranges than needed |
| IAM policies allow privilege escalation | 83% | A low-level user can grant themselves admin rights |
| Block Public Access off at account level | 81% | One bucket-level change can expose data with no account-wide safety net |
| IAM access keys not rotated | 71% | A stolen key keeps working until someone notices |
Azure
Three of Azure’s top five involve storage accounts, and the other two come down to identity and secrets:
| Misconfiguration | % of accounts | Why it matters |
|---|---|---|
| Storage account key rotation off | 67% | A leaked key never expires |
| Storage account access keys enabled | 66% | Shared keys grant full access and bypass Microsoft Entra ID roles |
| Public network access on storage accounts | 61% | Data is reachable from the internet instead of only through private endpoints |
| Entra users without MFA | 55% | One phished password is enough to sign in |
| Key Vault secrets that never expire | 41% | Old secrets stay valid indefinitely |
Google Cloud
Google Cloud had the lowest rates in four of the six categories, but identity is its weak spot:
| Misconfiguration | % of accounts | Why it matters |
|---|---|---|
| OS Login MFA off | 77% | Engineers can SSH into VMs without a second factor |
| Unused service accounts | 75% | Idle identities still hold live permissions |
| Over-permissive service accounts | 53% | A broad role such as Editor turns one compromised workload into project-wide access |
| Permissive ingress to sensitive ports | 34% | Admin and database ports face the internet |
| Default network still in use | 29% | Its auto-created firewall rules allow SSH and RDP from any address |
How Do the Three Clouds Compare?
| Category | AWS | Azure | Google Cloud |
|---|---|---|---|
| Weak IAM controls | 97% | 90% | 87% |
| Missing logging and alerting | 98% | 80% | 82% |
| Misconfigured services | 68% | 80% | 37% |
| Permissive firewalls | 83% | 45% | 34% |
| Exposed services | 76% | 64% | 8% |
| Weak encryption | 49% | 35% | 8% |
Missing logging peaks at 98% of AWS accounts, which means many teams couldn’t trace a break-in even after spotting one. Weak IAM also grows with company size, from 87% of companies with up to 250 employees to 98% of large enterprises.
How Do Misconfiguration Attacks Work?
How fast does a public bucket get found? Faster than most teams expect. Open-source scanners such as ZMap can sweep the entire IPv4 internet in under an hour, and search engines like Shodan index exposed services around the clock. Most misconfiguration attacks follow four stages:
- Discovery. Bots scan for open ports and guess bucket names from wordlists built on company names, such as acme-backups or acme-prod-logs.
- Public snapshots and machine images. A disk snapshot or server image shared publicly hands over a full copy of a machine, including database files and SSH keys.
- Dangling DNS. A DNS record still points to a cloud resource that was deleted. The attacker recreates a resource with the same name and takes over your subdomain to host phishing pages.
- Harvesting secrets. Exposed .env files and keys, like the credential files in the bucket study above, let the attacker sign in as a legitimate user.
That last step matters most. Once a valid key is in use, the misconfiguration attack becomes an identity breach that looks like normal activity in your logs. Our guide to cloud security risks in 2026 shows how stolen keys feed wider attacks.
Which Recent Breaches Started With a Cloud Misconfiguration?
Several of the latest cloud misconfiguration breaches started in a supplier’s cloud or a SaaS platform, not on the victim’s own servers. That’s why so many recent supply-chain incidents trace back to settings someone else controlled.
Volkswagen’s Cariad (December 2024)
Cariad builds the software that runs in cars across Volkswagen’s brands. In December 2024, Der Spiegel and researchers from the Chaos Computer Club revealed that a misconfigured AWS environment run by Cariad had exposed location data for about 800,000 electric vehicles, with precise positions for roughly 460,000.
Several terabytes sat reachable online for months. The impact went beyond customer privacy: reporters found the data could track two German politicians.
Tea App (July 2025)
What happened: The women’s dating-safety app stored verification photos in a legacy Firebase storage bucket with no authentication. Anyone with the right URL could download about 72,000 images, including roughly 13,000 selfies and government ID photos from users who signed up before February 2024.
The lesson: Tea had moved to newer storage but never locked down or deleted the old system. Retire old storage; don’t just abandon it.
The impact: A second exposure followed, involving private messages, and Tea shut down its messaging feature.
McGraw Hill (April 2026)
The education publisher disclosed that attackers took data from a Salesforce-hosted webpage after exploiting a “Salesforce environment misconfiguration.” Have I Been Pwned later listed 13.5 million accounts tied to the leak.
It’s a clear example of SaaS misconfigurations: Salesforce itself wasn’t breached, but sharing settings on a public-facing site exposed records that should have stayed private.
How Can You Check Your Own Cloud for Misconfigurations Today?
Run these read-only checks before you buy any tool. They take a few minutes in each provider’s command-line tool. They change nothing, and they work with a read-only role: SecurityAudit on AWS, Reader on Azure or Security Reviewer on Google Cloud.
AWS: two checks for the most damaging misconfigurations
Is Block Public Access on for the whole account? Replace the number with your account ID:
aws s3control get-public-access-block --account-id 111122223333All four settings should return true. An error saying no configuration exists means no account-wide block is in place.
Which access keys are old or unused?
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csvOpen the file and sort by access_key_1_last_rotated. Anything older than 90 days needs rotating or deleting.
Azure: storage accounts that still allow anonymous access
az storage account list --query '[?allowBlobPublicAccess!=`false`].{name:name, group:resourceGroup}' -o tableEvery account listed allows anonymous access at the account level. Older accounts with no explicit setting show up here too. Data is only exposed if a container inside is also public, but switching the account setting off closes the door for every container at once.
Google Cloud: leftover defaults and long-lived keys
Is the default network, with its open SSH and RDP rules, still in your project?
gcloud compute networks list --filter="name=default"Which service accounts have keys someone created by hand?
for sa in $(gcloud iam service-accounts list --format="value(email)"); do
gcloud iam service-accounts keys list --iam-account="$sa" --managed-by=user --format="table(name.basename(), validAfterTime)"
doneEach key listed is a long-lived credential. Replace it with workload identity federation where you can.
How Do You Stop Misconfigurations From Coming Back?
Speed of repair depends on company size, and not in the way you’d guess. In Intruder’s 2026 data, companies with fewer than 1,000 employees fixed cloud misconfigurations in 7 to 16 days, and enterprises with 10,000 or more took about 10.
Companies with 1,000 to 5,000 employees were the slowest, at 35 days. They’re big enough to sprawl but often too small for a dedicated cloud security team. Four controls close that gap at any size:
- Block risky settings at the top. Apply organization-level guardrails that no single account can override:
- AWS: Service Control Policies that stop anyone from disabling Block Public Access, and Resource Control Policies that keep your data away from identities outside your organization
- Azure: Azure Policy rules set to “deny”
- Google Cloud: explicitly enforce constraints such as
storage.publicAccessPreventionandcompute.skipDefaultNetworkCreationon organizations created before the 2024 defaults
- Check code before it merges. Run an IaC scanner such as Trivy or KICS on every pull request, so open settings are caught in review rather than in production.
- Alert on drift. Schedule
terraform plan -detailed-exitcodenightly; an exit code of 2 means the live cloud no longer matches the code. For continuous cloud misconfiguration monitoring across every account, add a cloud security posture management tool. - Give every exception an expiry date. When a bucket truly must be public, record the owner, the reason and an end date, for example a resource tag like
exception-expires=2026-12-31. Review the list monthly.
Our cloud security tips and best practices guide covers the day-to-day habits that keep these controls working.
FAQ’s
What is the most common cloud misconfiguration?
Weak identity and access settings, such as over-broad roles, missing MFA and old keys, affect the large majority of accounts on all three major clouds.
On AWS, the single most frequent finding is an S3 bucket that doesn’t require HTTPS, which shows up in nearly nine out of ten accounts.
Are cloud misconfigurations the same as OWASP’s “security misconfigurations”?
They overlap but aren’t identical. OWASP’s list of security misconfigurations focuses on applications: default accounts, verbose error messages and unneeded features left on. It also includes badly set permissions on cloud services.
The category climbed from #5 in 2021 to #2 in the OWASP Top 10:2025. Cloud misconfigurations cover the wider infrastructure layer too, including networks, storage, identity and logging.
What is configuration drift in the cloud?
Configuration drift is the gap that opens when live cloud settings move away from the approved baseline, usually the version in your infrastructure code.
Manual console edits, emergency fixes and other automation tools all cause it. Comparing the live environment against code on a schedule catches drift early.
What are SaaS misconfigurations?
They’re risky settings inside business apps such as Salesforce, Microsoft 365 and Google Workspace. Common examples are public sharing links, overly open guest access on public sites and missing MFA policies. CISA’s free SCuBA baselines set out secure configurations for Microsoft 365 and Google Workspace.
The Microsoft 365 baseline is mandatory for federal agencies under Binding Operational Directive 25-01. Tools that monitor SaaS settings form their own category, and our CNAPP vs CSPM comparison explains where each type fits.
How long does it take to fix a cloud misconfiguration?
Changing the setting often takes minutes. Approving the change is what takes weeks. Teams stall on unclear ownership, fear of breaking production, change-approval queues and fixes buried in shared Terraform modules. Tagging every resource with an owner and testing fixes in staging first removes most of that delay.
