What Are Cloud Vulnerabilities? Categories and Fixes

The breach reports rarely name a CVE. They name a storage bucket that was public, a security group open to the internet, an access key checked into a Git repo, a role that could assume every other role in the account. The exploit was not a buffer overflow. It was a setting. Someone left a switch in the wrong position and an attacker found it before the owner did.

That is what makes cloud vulnerabilities their own discipline. A traditional vulnerability is a flaw in code: a parser that mishandles input, a library with a known CVE, a service you forgot to patch. Those still exist in the cloud. But most cloud incidents start somewhere else, in how the environment is configured, who can reach what, and how the pieces are wired together. This guide covers what cloud vulnerabilities are and why they differ from ordinary CVEs, the categories that recur, where the provider's responsibility ends and yours begins, the concrete examples a responder keeps seeing, and how defenders find, fix, and prioritize them. It is written for the people who get paged when a bucket goes public: SOC analysts, threat hunters, and DFIR responders.

What are cloud vulnerabilities?

A cloud vulnerability is any weakness in a cloud environment that an attacker can use to gain access, escalate privilege, or reach data they should not. The word "weakness" is doing more work here than in a traditional CVE. On-premises, a vulnerability is usually a defect in software you can patch. In the cloud, the weakness is just as often a configuration you chose, an identity you granted too much, or an architecture that connects two things that should have stayed apart.

Three sources of weakness dominate, and only the first overlaps with classic vulnerability management. Configuration: a setting left at an insecure default or changed to a permissive value. Identity: a user, role, or key that holds more access than it needs, or that should not exist at all. Architecture: how services, networks, and accounts are connected, so that reaching one thing becomes a path to another. A software CVE in a workload is a fourth source, and it matters, but it is not where most cloud incidents begin.

This is why a vulnerability scanner pointed at a cloud account misses most of the risk. It can tell you a workload runs an unpatched package. It cannot tell you the workload's instance role can read every bucket in the account, or that the bucket policy allows public reads, or that the security group exposes the admin port to the entire internet. Those are not flaws in code. They are decisions, and finding them means reading the configuration and the identity graph, not just the package list. The fix for a CVE is a patch. The fix for a cloud vulnerability is usually a policy change.

The shared responsibility model: provider versus customer

Before the categories, the line that decides which side owns each one. Every major provider runs a shared responsibility model, and misunderstanding it is itself a source of vulnerabilities. AWS frames it as security "of" the cloud versus security "in" the cloud. AWS is responsible for protecting the infrastructure that runs the services: the hardware, the hypervisor, the physical facilities, the managed service software. The customer is responsible for what they put on top: the guest operating system and its patches, application code, firewall and security group configuration, data, encryption choices, and identity and access management.

The practical effect is that the provider almost never causes the breaches you investigate. The hypervisor does not leak your data; a bucket policy you set to public does. The dividing line also shifts by service model. For infrastructure services like EC2, the customer owns a lot, including patching the operating system. For managed services like S3 or a managed database, the provider runs more of the stack, but the customer still owns the data, the access policy, and the encryption setting. The mistake that creates vulnerabilities is assuming the provider covers something it does not. "It is in the cloud, so it is secure" is the sentence that precedes a public bucket.

For a defender, the model is a triage tool. When something goes wrong, the responsibility line tells you which side to look at first, and for nearly every cloud incident, the answer is the customer's configuration and identity, not the provider's infrastructure.

The major categories of cloud vulnerabilities

Cloud vulnerabilities cluster into a handful of recurring categories. They are not exotic. Each is a class of mistake that shows up across every provider and most environments.

Misconfigurations. The largest category by far. A storage bucket set to public, logging turned off, encryption not enabled, a default that was never hardened. Misconfigurations are common because cloud platforms expose thousands of settings and default to availability over security in many of them. This is the category most AWS misconfigurations fall into, and it is the one a posture scan catches fastest.

Weak or over-permissioned IAM. Identity is the new perimeter in the cloud, and over-broad identity is the most dangerous vulnerability class. A role with a wildcard policy that allows every action on every resource. A user with permanent administrator access. A role that can assume any other role, collapsing every boundary in the account. When an attacker lands on an over-permissioned identity, they inherit everything it can reach.

Insecure APIs. Cloud services are operated through APIs, and so is everything built on them. An API without authentication, with broken object-level authorization, or that leaks data through verbose errors is a direct path in. The cloud control plane is itself an API, which means a leaked credential is API access.

Exposed storage and data. Public object storage, snapshots shared too widely, databases reachable from the internet, backups in an open bucket. This overlaps with misconfiguration but earns its own line because the impact is direct: the data is the target, and exposed storage hands it over without an exploit.

Unpatched workloads. The classic CVE, still present. Virtual machines, containers, and serverless functions run software that needs patching. Cloud makes this worse in one way: it is trivial to spin up workloads and forget them, so unpatched instances accumulate as orphans no one is tracking.

Insecure secrets management. Access keys, API tokens, and database passwords hardcoded in source, baked into container images, stored in environment variables, or committed to a repository. A leaked long-lived credential is one of the most reliable ways into a cloud account, because it often grants exactly the access the developer had.

Lack of visibility and shadow cloud. You cannot defend what you cannot see. Accounts created outside the central process, resources spun up by a team and never inventoried, regions no one monitors. Shadow cloud is the modern shadow IT, and it expands the attack surface faster than security can track.

Supply chain. The workload pulls a base image, a package, or a third-party module, and inherits its flaws. A compromised dependency or a poisoned image becomes your vulnerability the moment it runs in your account.

Concrete examples a responder keeps seeing

The categories become real in a handful of patterns that recur across investigations.

The public S3 bucket. A bucket's access policy or ACL allows public reads, and the data inside, customer records, backups, internal documents, is reachable by anyone who knows or guesses the URL. No exploit, no malware. The bucket was set to public, often to make sharing easy, and never set back. This is the archetype of a misconfiguration with direct data impact.

The open security group. A security group rule allows inbound traffic from 0.0.0.0/0, the entire internet, to a sensitive port: SSH on 22, RDP on 3389, a database port, an admin console. The instance is now reachable by every scanner on the internet, and exposed services get found in minutes. The fix is to scope the source to known ranges and close the port, but the rule was opened for a quick test and left in place.

SSRF to the metadata service. This is the cloud-native attack chain. An application on an EC2 instance has a server-side request forgery flaw: it can be tricked into making a request to a URL an attacker controls. The attacker points it at the instance metadata service at 169.254.169.254, the link-local address every EC2 instance uses to read its own metadata. On IMDSv1, a simple GET to that address returns the instance's IAM role credentials, and the attacker now holds the role's keys. This is exactly the path behind several large cloud breaches. AWS introduced IMDSv2 to break it: IMDSv2 is session-oriented, requiring a PUT request to obtain a token and that token in every subsequent GET, which an ordinary SSRF cannot perform. AWS documents IMDSv2 as defense in depth against open firewalls, reverse proxies, and SSRF. Enforcing IMDSv2 and disabling IMDSv1 closes the chain.

The leaked access key. A long-lived access key ends up in a public Git repository, a container image, a log, or a paste site. Automated scanners find exposed AWS keys within minutes of them being committed. Whoever finds it gets the access the key carries, which is often broad, because the key was created for convenience and scoped to nothing.

How defenders find and fix cloud vulnerabilities

Finding cloud vulnerabilities means reading configuration and identity, not just scanning for CVEs. Several tool classes do this, and they overlap.

Cloud Security Posture Management (CSPM) continuously evaluates the configuration of cloud resources against a baseline of secure settings and benchmarks like the CIS controls. It is the tool that catches the public bucket, the open security group, the disabled logging, the unencrypted volume. CSPM is the answer to the misconfiguration category, and it runs continuously because configuration drifts every time someone makes a change.

Vulnerability scanning still applies to the workloads. Scanning virtual machine images, container images, and running instances for known CVEs covers the unpatched-workload and supply-chain categories. In the cloud the useful version is agentless or registry scanning that does not require touching every host.

Cloud Infrastructure Entitlement Management (CIEM) analyzes the identity graph: who can do what, which roles are over-permissioned, which can assume which, where standing administrative access lives. CIEM answers the IAM category, the one a configuration scan alone misses, by computing effective permissions rather than reading policies one at a time.

Cloud Workload Protection secures the running workloads themselves: virtual machines, containers, and serverless functions, with vulnerability detection, runtime monitoring, and behavioral controls. A cloud workload protection platform (CWPP) is the runtime counterpart to posture management, watching what a workload does after it is deployed.

The specific fixes follow the categories. Enforce IMDSv2 and disable IMDSv1 to kill the metadata SSRF path. Set buckets to block public access by default. Scope security group rules to known source ranges, never 0.0.0.0/0 on sensitive ports. Replace long-lived access keys with short-lived role credentials and a secrets manager. Apply least privilege to every role and remove standing administrative access. Patch and rebuild workloads from hardened images on a schedule. Many of these are platform defaults now, which makes turning them on the single highest-leverage action available.

Prioritizing what to fix first

A real cloud account has hundreds of findings on day one. Fixing them in the order a scanner lists them wastes the response. Three factors decide what comes first.

Exploitability. How hard is it to actually use this? A public bucket with a guessable name is exploitable today by anyone. An over-permissioned role that requires an attacker to already be inside is exploitable only after a foothold. Real, demonstrated exploit paths outrank theoretical ones.

Exposure. Is it reachable from the internet, or only from inside the account? An open security group on a public IP and a public bucket are exposed to the entire internet. An internal misconfiguration matters less until something else lets an attacker in. Internet-facing findings come first.

Blast radius. If this is exploited, how far does it reach? A role that can assume every other role, a key with account-wide access, a bucket holding the customer database, each turns one finding into total compromise. The vulnerability whose exploitation hands over the most is the one to fix first, even if it is harder to reach.

The findings that score high on all three, internet-exposed, easy to exploit, and wide blast radius, are the emergencies: the public bucket full of customer data, the open admin port on a box with a powerful instance role, the leaked key with administrator rights. Everything else queues behind them. This is also where posture and entitlement tools earn their place, because they can rank findings by these factors instead of leaving an analyst to sort a flat list by hand.

Cloud vulnerability categories, examples, and controls

The bottom line

Cloud vulnerabilities are not mostly software bugs. They are configuration, identity, and architecture: a public bucket, an over-permissioned role, an open security group, a leaked key, an SSRF path to the metadata service. The shared responsibility model decides which side owns each one, and for nearly every incident the answer is the customer's settings and permissions, not the provider's infrastructure.

Finding them means reading configuration and the identity graph with posture management, entitlement analysis, and workload protection, not just running a CVE scanner. Fixing them means turning on defaults that already exist: block public access, scope security groups, enforce IMDSv2, replace long-lived keys, apply least privilege. And prioritizing them means leading with exploitability, exposure, and blast radius, so the public bucket full of customer data gets fixed before the theoretical internal finding. The switch in the wrong position is the whole problem, and putting it back is usually the whole fix.