Key Takeaways
- Cloud misconfigurations are the single biggest source of breaches, often caused by human error
- IAM failures let attackers move laterally once they’re inside your environment
- Insecure APIs were behind the 2022 Optus breach that exposed 10 million customer records
- 54% of cloud environments carry vulnerabilities tied to exposed virtual machines and serverless functions
- Zero Trust and continuous monitoring are the most reliable defenses against most of these risks
- CSPM tools like Secure.com’s Misconfigurations module can catch and fix many of these issues automatically before they become incidents
Introduction
A single misconfigured S3 bucket exposed Toyota’s customer data for nearly 10 years. Nobody noticed.
That’s not a rare story. According to Wiz Research’s 2025 findings, over half of cloud environments carry active vulnerabilities tied to exposed virtual machines and serverless functions. And per Verizon’s 2025 Data Breach Investigations Report, vulnerability exploitation as an initial attack vector grew again this year, hitting 20%.
The cloud is not inherently insecure. But the way most teams configure, access, and monitor it is.
Here are the 10 vulnerabilities that attackers rely on most.
1. Cloud Misconfiguration
This is the number one cause of cloud data breaches. When storage buckets, databases, or VMs are set up with loose permissions or default settings left unchanged, attackers don’t need to be clever. They just walk in.
Common mistakes include public S3 buckets, open ports, default passwords, and disabled encryption. The Darktrace glossary notes that cloud services like Amazon S3 or Azure Blob Storage are sometimes set to public by default, meaning anyone on the internet can access sensitive files if settings aren’t corrected.
How to fix it:
- Use a Cloud Security Posture Management (CSPM) tool like Secure.com to scan and auto-remediate misconfigurations. Secure.com’s Misconfigurations module continuously assesses cloud, SaaS, and workload configurations against CIS Benchmarks, NCP, and DISA STIG standards, detecting drift in real-time and triggering automated remediation for low-risk changes while requiring human approval for high-impact actions.
- Set all cloud storage to private by default
- Review Infrastructure as Code (IaC) templates before deployment
2. Weak Identity and Access Management (IAM)
Most cloud environments have far more digital identities than human ones. Service accounts, automation tools, and third-party integrations all carry permissions. When those permissions are too broad, or when MFA is missing, attackers can compromise one account and pivot everywhere.
The 2024 Dropbox Sign breach is a clear example. Attackers accessed email addresses, hashed passwords, and credentials through a flaw in an automated system configuration tool. Dropbox contained the damage because it had isolated its Sign infrastructure. Most organizations have not done that.
How to fix it:
- Apply least privilege access across all users and services
- Enforce MFA, especially for cloud admin accounts
- Audit and rotate credentials on a regular schedule
3. Insecure APIs
APIs are how your cloud services talk to each other. They’re also one of the most frequently attacked surfaces in modern infrastructure. Weak authentication, missing rate limits, and no input validation all make APIs easy targets.
In 2022, the Optus data breach compromised around 10 million customers through a publicly available API that required no authentication at all. No exploit required.
How to fix it:
- Require authentication for every API endpoint, internal or external
- Use a Web Application Firewall (WAF) to filter malicious requests
- Apply rate limiting to prevent abuse and brute-force attacks
4. Cryptographic Failures (Lack of Encryption)
Data at rest or in transit without encryption is a liability. If an attacker gains access to unencrypted data, there’s nothing left to stop them from reading everything.
The 2017 Equifax breach is the most cited example. While the initial entry point was an unpatched Apache Struts vulnerability, subsequent investigations found that Equifax stored sensitive personal data without encryption. That decision turned a manageable incident into one that affected 148 million people.
How to fix it:
- Encrypt all data at rest using AES-256
- Enforce HTTPS and SFTP. Disable older, insecure protocols
- Use transparent data encryption for databases
5. Broken Access Control
This goes beyond IAM. Broken access control means users or services can reach resources they were never supposed to touch. It covers privilege escalation, insecure direct object references, and missing function-level access controls.
When a former AWS employee used her cloud knowledge to breach Capital One in 2019, she exploited a misconfigured web application firewall that gave her access to AWS metadata credentials. The result cost between $100 million and $150 million to remediate and exposed the data of over 100 million Americans and Canadians.
How to fix it:
- Use role-based access control (RBAC) consistently across all cloud resources
- Review access privileges regularly, especially when employees change roles or leave
- Adopt Zero Trust principles. Trust nothing by default, verify everything
6. Vulnerable and Outdated Components (Supply Chain Risk)
Your cloud application is only as secure as the libraries, SDKs, and third-party tools it depends on. If a vendor pushes a compromised update, your environment inherits that risk without any direct action on your part.
The MOVEit breach is the clearest recent example. Attackers injected malware into a file transfer tool used by thousands of organizations worldwide, harvesting sensitive data across industries with a single exploit in a third-party dependency.
How to fix it:
- Maintain a current inventory of all third-party dependencies
- Monitor security advisories and patch quickly when alerts come in
- Use runtime security tools to detect abnormal behavior from third-party code—Secure.com’s AppSec Teammate continuously assesses dependencies through SCA (Software Composition Analysis) and correlates build-time findings with runtime exploitability
7. Secrets Management Failures
API keys, database passwords, and access tokens left in code repositories or environment variables are a gift to attackers. Once exposed, these credentials are immediately exploited.
CrowdStrike recommends storing secrets in one place using a dedicated solution such as AWS Secrets Manager, and never hardcoding credentials anywhere in your codebase.
How to fix it:
- Use a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault)
- Scan repositories regularly for accidentally committed credentials
- Rotate secrets on a schedule and immediately after any suspected exposure
8. Server-Side Request Forgery (SSRF)
SSRF attacks trick a cloud server into making internal requests on the attacker’s behalf. In cloud environments, this often means reaching cloud metadata endpoints that expose IAM credentials and instance configuration.
It was an SSRF vulnerability combined with a misconfigured WAF that allowed the Capital One attacker to query AWS’s internal metadata service and retrieve temporary credentials. One misconfig, one SSRF endpoint, 100 million exposed records.
How to fix it:
- Block outbound requests to internal metadata endpoints (169.254.169.254 on AWS)
- Validate and sanitize all user-supplied URLs in your application
- Use IMDSv2 on AWS, which requires session tokens for metadata access
9. Insufficient Logging and Monitoring
If you’re not logging, you’re not seeing. Attackers count on detection gaps. The Jelly Bean Communications breach went undetected for seven years, from 2013 to 2020, exposing 3.5 million health insurance applicants. The company eventually paid $293,771 to settle the case because it failed to maintain adequate monitoring under HIPAA.
You don’t have to be in healthcare for this to matter. Long dwell times happen across every industry when logging is an afterthought.
How to fix it:
- Centralize logs from all cloud services, applications, and network layers
- Set up automated alerts for failed authentication, unusual API calls, and privilege changes
- Run threat detection tools that flag anomalies in real time
10. Shadow IT and Lack of Visibility
Shadow IT means cloud resources spun up outside IT’s control. Employees bypass approval to move faster, but those resources often carry default passwords, no monitoring, and zero oversight.
In 2024, fintech company Finastra discovered a breach that originated from a third-party secure file transfer platform that sat entirely outside its central security team’s control. Because no one was watching it, no one noticed the breach immediately.
How to fix it:
- Conduct regular audits to discover unauthorized cloud assets
- Use a CNAPP (Cloud Native Application Protection Platform) for full-environment visibility—Secure.com provides unified visibility through its Asset Discovery & Knowledge Graph, which continuously maps all assets across cloud, on-premises, endpoints, and SaaS applications, creating a living map that reveals blind spots before attackers exploit them
- Create and enforce clear policies for provisioning cloud resources
When Cloud Vulnerabilities Hit the Headlines
Optus
A publicly available API exposed customer records without authentication.
Capital One
Misconfigured WAF allowed access to AWS metadata and credentials.
Equifax
Unpatched vulnerability exposed millions of sensitive records.
Jelly Bean
Breach went undetected for years due to lack of monitoring.
MOVEit
Zero-day vulnerability impacted thousands of organizations.
Toyota
Cloud misconfiguration exposed customer location data.
How to Prioritize These Vulnerabilities
Not every vulnerability deserves equal urgency. A useful framework:
| Priority | Vulnerability | Why It’s Urgent |
|---|---|---|
| Critical | Misconfiguration | Most common initial breach vector |
| Critical | Weak IAM | Enables lateral movement |
| High | Insecure APIs | Exposed to external attackers |
| High | Missing Encryption | Data readable if breached |
| High | Broken Access Control | Privilege escalation path |
| Medium | Supply Chain Risk | Hard to detect, high blast radius |
| Medium | Secrets Exposure | Instant credential theft if discovered |
| Medium | SSRF | Often linked to IAM compromise |
| Medium | Poor Monitoring | Extends attacker dwell time |
| Ongoing | Shadow IT | Grows quietly without governance |
FAQs
What causes most cloud data breaches?
How is cloud security different from traditional network security?
What is Zero Trust and does it actually help?
Does CSPM replace manual security audits?
Conclusion
Most cloud breaches are not sophisticated. They’re the result of a public bucket, an overprivileged account, or a forgotten API endpoint that nobody was watching.
The good news is that the fixes are not complicated. CSPM tools, least privilege access, encrypted storage, and continuous monitoring address the majority of these risks. The hard part is making them standard practice, not one-time checkboxes.
Start with misconfigurations, IAM, and API security. Those three alone cover the most common paths attackers take. Once those are solid, work through the rest of the list systematically.
Cloud security doesn’t require perfection. It requires consistency—and that’s exactly what Digital Security Teammates deliver.