The most common cloud misconfigurations: public buckets, excessive IAM and keys in repositories

By Kike Gandia · Co-Founder & CEO, OSCP

Most serious cloud incidents do not start with an unknown vulnerability but with a configuration: a bucket someone made public, a role with “temporary” administrator permissions, an access key pushed to a repository or an instance that hands its credentials to anyone who knows how to ask. They are well-known mistakes, they repeat across AWS, Azure and Google Cloud, and almost all have a simple fix. This guide covers the most frequent ones, why they are dangerous, what providers have changed in their defaults, a real case that chains them together and how to find them before an attacker does.

Why configuration is the main cloud risk

In your own data centre, exposing a database to the internet means touching the firewall, the routing and the server. In the cloud it takes a checkbox or one line of an infrastructure template. That ease is the cloud's advantage and also its main risk: anyone with permissions can change a resource's exposure in seconds, and the change stays live until someone notices.

That is why guidance from reference bodies focuses on configuration rather than software vulnerabilities. In March 2024 the NSA, with CISA taking part in six of them, published its “Top Ten Cloud Security Mitigation Strategies”: ten recommendation sheets that start with upholding the shared responsibility model and continue with identity and access management, key management, network segmentation and encryption, data protection, securing CI/CD environments, infrastructure as code, hybrid and multi-cloud environments, managed service providers and logging for detection.

Three characteristics make these mistakes so dangerous:

They are visible from outside. There are tools continuously scanning the internet for open buckets, published keys and exposed services.
They require no exploitation. A public bucket gets downloaded; a valid key gets used. There is no exploit to detect.
They chain together. A minor mistake gives access to a credential, and the credential gives access to everything else.

Summary: the most common mistakes and their impact

Mistake	Example	What an attacker gets	What stops it
Public storage	S3 bucket, Azure Blob container or Cloud Storage bucket open to anyone	Downloading backups, documents or customer data	Blocking public access at account or organisation level
Excessive IAM	Users and roles with administrator permissions or wildcards	A stolen credential controlling the whole account	Least privilege, permission boundaries, reviewing unused permissions
Keys in repositories	Access keys in Git, container images, mobile apps or pipeline logs	Direct access to the account with the key's identity	Removing long-lived keys, secret scanning, rotation
Unprotected metadata	Instances accepting IMDSv1 behind an application with SSRF	Stealing the machine role's temporary credentials	Mandatory IMDSv2, hop limit, least-privilege roles
Open network	SSH, RDP or databases reachable from 0.0.0.0/0	Brute force, service exploitation, direct data access	Restrictive security groups, bastion or session-based access
Shared snapshots and images	Disk or database snapshots, or machine images, shared publicly	Mounting a full copy of the disk with all its data and secrets	Blocking public sharing, regular review
Logging switched off	No persistent activity logging or no data access events	Acting without leaving useful traces and without anyone noticing	Centralised, protected logging with alerts that someone reviews
Badly scoped trust	Roles assumable from other accounts or from CI/CD without conditions	A third party, or any repository, obtaining credentials for your account	Strict conditions in trust policies

The following sections explain each block in more detail.

Public storage: buckets, blobs and snapshots

It is the best-known mistake and the one that has produced the most headlines: a storage container accessible to anyone who knows, or guesses, its name.

Providers have hardened their defaults. Since April 2023, new S3 buckets are created with Block Public Access enabled and ACLs disabled, however they are created. In Azure, the default configuration of storage accounts prohibits anonymous access to blobs. But those changes have important limits:

They only apply to new resources. Buckets and accounts created earlier keep their configuration.
They can be switched off. It only takes someone removing the block to publish a static website and, over time, the same bucket ends up holding other things.
They do not cover every way of sharing. S3 presigned URLs or Azure SAS tokens with years-long expiry and broad permissions amount to public access for whoever has the link.

Two classic confusions: in Google Cloud, granting access to allAuthenticatedUsers does not limit access to your organisation but to anyone with a Google account; and in S3 the old ACLs for “authenticated users” meant any AWS account, not your company's.

Snapshots deserve a separate mention. A publicly shared disk or database snapshot contains a full copy of the data, including configuration files with passwords. Shared machine images have the same problem.

The fix is to apply the block at account or organisation level, not bucket by bucket —S3 account-level Block Public Access, the public access prevention organisation policy in Google Cloud, Azure Policy to prevent anonymous access— and to review regularly what is shared externally.

Excessive IAM: the mistake that turns any flaw into a total one

If you had to pick a single mistake, it would be this one. Permissions determine how much damage whoever compromises an identity can do, and in most accounts they are far broader than necessary:

Administrator permissions for convenience. Policies with "Action": "*" and "Resource": "*" attached to users, application roles or the deployment pipeline, because that way it “works”.
The root account or subscription owner in daily use, sometimes without MFA.
Human users with long-lived access keys instead of federated access with temporary credentials.
Accumulated permissions. Whoever changed teams keeps the old ones; the role for a finished project still exists; test service accounts are never deleted.
Combinations that allow escalation. Permissions that look harmless on their own —such as being able to pass a role to a service and create functions— let a limited identity act as a more privileged one.
Broad trust relationships. Roles an external provider can assume without an external ID, or roles for GitHub Actions or other CI systems whose condition does not restrict which repository or branch can obtain credentials.

The way to reduce it is well known: least privilege, starting with internet-facing identities; temporary credentials for people and workloads; permission boundaries for roles that create other roles; organisation policies (SCPs in AWS, Azure Policy, organisation policies in Google Cloud) that block the most dangerous actions; and regular review of unused permissions, with native tools such as IAM Access Analyzer. What cannot be seen without testing is whether any escalation path remains: that is what offensive IAM analysis is for, as explained in the AWS penetration testing guide.

Keys and secrets in repositories

Long-lived credentials —AWS access keys, Azure service principal secrets, Google Cloud service account keys— end up where they should not. GitGuardian's State of Secrets Sprawl 2026 report gives a sense of scale: 28,649,024 new secrets detected in public GitHub commits during 2025, 34% more than the previous year. And that is only public repositories.

Where they turn up:

In Git history, even if they were deleted in the latest commit.
In configuration files, infrastructure templates and .env files committed by mistake.
In published container images, mobile app code and the JavaScript sent to the browser.
In CI/CD pipeline logs and in function environment variables.

Providers react ever faster. In February 2024 GitHub enabled by default the protection that blocks pushes containing secrets to public repositories, and AWS keys are among the patterns GitHub reports directly to AWS when it finds them. AWS, for its part, can attach a quarantine policy (AWSCompromisedKeyQuarantineV3) to the exposed key that denies actions such as launching instances or creating users, and informs you through a support case. But that quarantine is a safety net, not a solution: it does not revoke the key or cover other providers, and attackers watch repositories too.

If a key has been published, deleting the commit does not help. It must be deactivated and rotated immediately, the activity log checked for what was done with it, and resources created by the attacker hunted down: instances for cryptocurrency mining, new users or extra keys. Prevention means removing long-lived keys wherever possible —roles, identity federation for CI/CD, temporary access for people— keeping secrets in a manager and scanning code before every push.

The metadata service and SSRF: the Capital One case

Every cloud virtual machine can query an internal metadata service that, among other things, hands out temporary credentials for the role assigned to the machine. If an application on that machine is vulnerable to SSRF —meaning it can be made to send requests to arbitrary addresses— an attacker can ask it to query that service and return the credentials.

The best-known case is Capital One in 2019. According to the US Department of Justice complaint, a misconfigured web application firewall allowed commands to be sent to one of the bank's servers; with one of them the attacker obtained the credentials of an account named “…-WAF-Role”, with another she listed more than 700 storage folders or buckets and with a third she copied the data. The complaint does not use terms such as SSRF or metadata service, but the pattern it describes —a server executing an attacker's request and ending up handing over a role's credentials— is exactly what AWS set out to cut off when, in November 2019, it introduced IMDSv2 as added defence against open firewalls, reverse proxies and SSRF vulnerabilities. Capital One put those affected at around 100 million people in the United States and around 6 million in Canada, and in August 2020 the OCC, the US banking supervisor, fined it $80 million for failing to establish effective risk assessment processes before migrating to the public cloud.

The chain has three links, and breaking any of them cuts it:

Link	What failed	What cuts it
The application	It allows requests to internal destinations	Validating destinations, blocking internal and metadata ranges
The metadata service	It hands out credentials to a simple request	IMDSv2, which requires a session token obtained with a PUT request; a hop limit so containers cannot reach it
The role	It can list and read many buckets	Least privilege: a web server's role does not need to read all the data

Since March 2024, AWS lets you set it as the default for new instances in each region of the account. Old instances, legacy images and infrastructure templates copied from years ago still accept IMDSv1 if nobody changes them. In Azure and Google Cloud, the metadata service requires a specific header on every request, which stops the simplest SSRFs but does not replace destination validation in the application.

Open network: admin ports and exposed services

Cloud security groups and firewall rules are easy to open and easy to forget. The most frequent patterns:

SSH (22) or RDP (3389) open to 0.0.0.0/0, often “just during the migration”.
Databases, caches and search engines reachable from the internet: publicly accessible relational databases, Redis, Elasticsearch or MongoDB instances without authentication.
Admin panels and internal APIs published behind a load balancer with no additional authentication.
Unrestricted outbound internet access from every subnet, which makes exfiltration and downloading tools after a compromise easier.
Connectivity between environments broader than needed: the development environment can reach production through a peering nobody reviewed.

The modern alternative to opening admin ports is not opening them: the provider's own session-based access services, bastions with temporary access or private networks with identity-based access. And for services that genuinely must be exposed, an inventory of what is published and why, checked regularly against what is visible from outside.

Logging and detection switched off

This mistake opens the door to nobody, but it makes all the others worse: without logs the attack goes undetected and, afterwards, nobody can reconstruct what happened or which data was affected, which also complicates notification duties.

Provider	What exists by default	What is usually missing
AWS	CloudTrail provides a 90-day event history of management events per region	A trail or event data store that keeps logs long term, in every region and protected against deletion; S3 data access events; GuardDuty enabled
Google Cloud	Admin Activity audit logs are always written	Data Access audit logs, disabled by default except for BigQuery
Azure	The subscription activity log	Sending it to a destination with enough retention and enabling diagnostic logs on each resource

Having the logs is not enough either. They need to be centralised in an account or project development teams cannot write to, alerts generated on the events that matter —key creation, policy changes, logging being disabled, access from unusual locations— and someone has to review them. One of the most revealing checks in a cloud penetration test is whether anyone reacts while permissions are enumerated or data downloaded.

How to find them and stop them coming back

These mistakes are found with three complementary tools:

A posture tool (CSPM), native to the provider or open source such as Prowler, which continuously checks every account's configuration against rules such as the CIS Benchmarks and alerts when something changes.
Preventive guardrails: organisation policies that directly block dangerous configurations —public access, unused regions, disabling logging— and scanning infrastructure-as-code templates before deployment. It is better for a mistake to be unable to reach production than to detect it afterwards.
A cloud penetration test, which answers the question the others do not: which of these mistakes, combined with each other and with the application running on top, let an attacker reach the data or take control of the account.

Order matters. Fixing first what a posture tool finds lets the penetration test focus on chains and identity, where it adds most value. The differences between the two approaches are covered in the comparison of CSPM and cloud penetration testing.

FAQ

What is the most dangerous cloud misconfiguration?

Excessive permissions, because they determine the reach of all the others. A public bucket exposes what it contains; an identity with administrator permissions compromised through a leaked key or a vulnerable application exposes the whole account. In practice, serious incidents usually combine several mistakes.

If AWS already blocks public access by default, why are there still public buckets?

Because the change, applied since April 2023, only affects new buckets, can be switched off and does not cover other ways of sharing, such as long-lived presigned URLs or public snapshots. The recommendation is to apply the block at account or organisation level and review exceptions regularly.

I pushed an AWS key to GitHub: what should I do?

Deactivate and rotate it immediately: deleting the commit does not help, because it stays in the history and may have been copied within seconds. Then check CloudTrail for what was done with it, look for resources or users created by third parties and check whether AWS has attached its quarantine policy and opened a support case. And replace that long-lived key with temporary credentials.

Does IMDSv2 prevent SSRF attacks?

It does not prevent SSRF, which is an application flaw, but it stops the most damaging use of it in AWS: stealing the role's credentials through the metadata service with a simple request. It should be combined with destination validation in the application and least-privilege roles, so that stolen credentials grant as little access as possible.

Are these mistakes specific to AWS?

No. They all have equivalents in Azure and Google Cloud: storage containers with anonymous access, owner roles over-assigned, service principal secrets or service account keys in repositories, metadata services reachable from vulnerable applications and data access logs never enabled.

How do I find out which of these mistakes my account has?

A first sweep with the provider's native posture tool or with Prowler shows most of them within a few hours. To know which are genuinely exploitable and how they chain with your applications and identities, you need a cloud penetration test with realistic starting assumptions.

Sources

Review the configuration of my cloud environment