Cloud environments face a quiet epidemic of security misconfigurations. Our data reveals that 25% of cloud deployments have at least one Selenium Grid instance. Security teams focus on flashy zero-day exploits and known vulnerabilities, yet a more persistent threat exists in everyday misconfigurations.
These problems become especially concerning when you consider their stealthy nature. Unlike CVEs that point to devices needing patches, misconfigurations remain undetected. The statistics paint a concerning picture - 75% of cloud environments run at least one self-hosted PostgreSQL instance. More than half operate with at least one Spring Boot Actuator instance. Both become prime targets for attacks due to improper configuration.
Security misconfigurations take many forms. Unrestricted access to public-facing services creates vulnerabilities. Weak credentials, excessive permissions, and exposed databases without proper controls add to the risk. Our analysis of 1.3 million security issues across 68,500 unique customer assets shows that misconfigured cloud services often match high-scoring vulnerabilities in risk level.
This piece will get into how these misconfigurations stand apart from traditional CVEs. We'll explore the most common types we see and share practical strategies to protect your environment.
How Misconfigurations Differ from CVEs
Misconfigurations are quite different from traditional vulnerabilities in several ways. CVEs represent specific software flaws that vendors can spot and fix. Security misconfigurations exist in a different space where organizations, not external providers, must take full responsibility.
No vendor patching mechanism for misconfigurations
The biggest difference between vulnerabilities and misconfigurations lies in how they get fixed. CVEs have a clear path: someone finds them, they get an ID, and vendors patch them. Misconfigurations, however, have no universal patch. Something secure in development can become risky once it faces the public internet.
On top of that, patch management only covers vulnerabilities that vendors can fix. This scope is nowhere near enough to address the wider security issues that misconfigurations create. Many security problems like poorly configured cloud storage buckets, excessive user permissions, or flawed architecture design don't fall under patch management at all.
Human error and copy-paste culture in DevOps
Most security incidents happen because of human mistakes, not complex attacks. About 95% of security breaches come from human error. Data breaches involve people 74% of the time, including misused privileges and stolen credentials.
Today's "copy-paste culture" in DevOps makes this worse. Developers often copy commands or Terraform modules straight from docs or example projects to save time. Many skip vital security steps before going live. Research from VirginiaTech shows that security features in coding frameworks are too complex and poorly documented. This leads developers to copy potentially unsafe code from Stack Overflow and similar forums.
Same end result: RCE, data theft, or lateral movement
Misconfigurations and vulnerabilities might start differently, but they lead to similar outcomes. Attackers don't care if they get in through a zero-day exploit or default admin/admin credentials. Both paths let them execute remote code, steal data, or move through your environment.
To name just one example, see how an attacker could exploit AWS Lambda misconfigurations. They might access sensitive database connection strings in environment variables and use overly permissive IAM roles to jump between functions. This could compromise an entire serverless application ecosystem.
4 Common Security Misconfigurations in Cloud Environments
Cloud environments constantly face threats. Google Cloud's latest research shows misconfigurations account for 75% of network intrusions. This alarming number shows how small setup errors can guide major security incidents.
Unrestricted access to public-facing services
Public access misconfigurations create some of the most dangerous cloud security gaps. Organizations expose their storage buckets, critical network services like SSH, or web services that weren't meant to be public. This can quickly result in data theft or system compromise. Many companies don't realize they allow unrestricted outbound internet access. This creates paths for attackers to steal sensitive information from cloud platforms. The solution lies in limiting access to specific IP addresses and services.
Default or weak credentials in production systems
Weak or default credentials remain the main entry point for cloud attacks. They make up 47% of all cloud environment intrusions during 2024. Users reuse 94% of passwords on multiple systems. Default credentials like "admin/admin" or "1234" ship with many devices and software. These persist in production environments because they make setup easier and help with bulk provisioning. In spite of that, using them cancels out all other security controls by giving attackers legitimate access that bypasses advanced detection systems.
Excessive permissions for low-privilege users
Overprivilege happens when users or applications get more permissions than they need. About 23% of identities in major cloud platforms have "critical" or "high-severity" excessive permissions. AWS environments show 87% of human identities have too many permissions. These extra privileges make the attack surface much larger. IT teams often put users in high-privilege groups instead of setting up detailed access controls. This makes things convenient but risky. Breaches with stolen credentials take about 292 days to spot and fix.
Exposed databases without encryption or access control
Databases often become targets because of permission mistakes and open network ports. Poor database encryption security controls put organizations at risk of fraud and data breaches. Things get worse when database administrators control both data and encryption keys. This setup ignores insider threats and gives attackers plenty of time to find weaknesses.
Real-World Exploits from Misconfigurations
Let's get into some attack campaigns that exploit security misconfigurations instead of patched vulnerabilities.
Selenium Grid: Remote code execution via --binary-location
A campaign called "SeleniumGreed" targets Selenium Grid instances, as security researchers discovered. This popular testing framework has 30,000 instances exposed to the public. Attackers abuse the --binary-location parameter to execute any commands they want. The parameter should point to Chrome's location, but attackers make it point to Python instead and run malicious code. The compromised systems end up being used for cryptomining operations.
Spring Boot Actuator: Heap dumps and SSRF via /actuator/gateway
Spring Boot's Actuator endpoints are great monitoring tools that become risky with wrong configurations. The /actuator/heapdump endpoint can expose complete memory snapshots if left open to the public. These snapshots contain sensitive data like credentials, API keys, tokens, encryption secrets, and personal information. Cloud environments often leave these endpoints open, which lets anyone access critical system details without authentication.
PostgreSQL: COPY FROM PROGRAM abuse with weak credentials
PostgreSQL databases are under constant attack through the COPY FROM PROGRAM feature. Security researchers found a cryptojacking campaign that took over over 1,500 PostgreSQL servers around the world in March 2025. The attackers first break in using weak credentials like "postgres/postgres". They then use the COPY FROM PROGRAM feature to run shell commands straight from SQL queries. This method helps them deploy malware without triggering usual detection systems.
How to Prevent Security Misconfigurations in CI/CD Pipelines
Security misconfigurations need a multi-layered approach that begins before code hits production. We implemented these strategies in our CI/CD pipeline to create multiple checkpoints that catch problems early.
Asset inventory and visibility across cloud services
Complete visibility is the foundation to make security work. A detailed asset inventory helps teams find all cloud resources in their environments. Teams should update this inventory continuously and make it available to security personnel who monitor risks from a central location. Major cloud providers have native tools—Microsoft Defender for Cloud inventory, Google Cloud Asset Inventory, and AWS Systems Manager Inventory—that give you this vital visibility.
Perimeter scanning for exposed endpoints
Regular perimeter scanning spots vulnerabilities in internet-facing systems. External vulnerability scanners copy remote attacker activities to find misconfigurations, missing patches, and exposed services. The window between vulnerability discovery and exploitation has shrunk to just 12 days. This makes continuous scanning vital for proactive security.
Policy-as-Code integration in CI/CD workflows
Policy-as-Code (PaC) changes governance from reactive to proactive by adding automated checks directly into pipelines. Here's what makes it work:
- Start with advisory (warn) mode before enforcing blocking policies
- Run policy checks during pull requests to get fastest feedback
- Treat policies as code with versioning and automated testing
Developer education with secure-by-default templates
Developer education combined with secure-by-default templates helps teams understand security's impact. Using pre-hardened libraries that automatically enable security best practices will substantially reduce misconfigurations.
Conclusion
Security misconfigurations pose one of the most important yet overlooked threats to modern cloud environments. This piece shows how these silent dangers often go undetected while creating risks similar to high-scoring vulnerabilities.
These configuration errors need direct action from organizations, unlike CVEs where teams wait for vendor patches. Security teams worldwide must prioritize detection and fix these issues quickly. Human factors create the biggest concern, as nearly 95% of security breaches come from human mistakes rather than complex attacks.
Cloud environments face four main types of misconfigurations. Public services with unlimited access, production systems with default credentials, excessive permissions, and exposed databases create problems. These give attackers legitimate ways into systems and often bypass even the best security controls.
Ground examples like Selenium Grid, Spring Boot Actuator, and PostgreSQL attacks show how attackers target these weak configurations. Organizations need detailed strategies that work against these risks.
Teams need full visibility of their cloud assets to protect against misconfigurations. Regular scanning of the perimeter helps find exposed endpoints before attackers do. Policy-as-Code brings automatic security checks during development. Secure-by-default templates help reduce human error.
Security teams can't just rely on vulnerability management programs. An all-encompassing approach that handles both CVEs and misconfigurations will give a better protection. Attackers don't care if they get access through a zero-day exploit or default credentials - they just want to get in. Our security strategies must block all possible entry points, especially these dangerous but often ignored misconfigurations.
