In the race to build and ship, the phrase "it just works" often describes everything a developer aspires to achieve. But for security teams, it can be a sign that they need to take a deeper look at the code. What happens when "just working" also means "wide open"?

Cloud application misconfigurations - from unrestricted public exposure to default credentials and excessive permissions - are among the most common and effective ways attackers gain a foothold in an environment. Unlike a CVE with a clear patch and a vendor SLA, misconfigurations often fall through the cracks. They are silent, surprisingly widespread, and being actively exploited by malicious actors.

This was the topic of a talk we gave at DistrictCon 2025, and this blogpost will walk you through the details.

Misconfigurations vs. Vulnerabilities: Not Just Semantics

For security teams, vulnerabilities are a known quantity: a CVE is disclosed, vulnerability scanners are triggered, and a patching process kicks in. In contrast, misconfigurations can be more complex to deal with:

• No universal patch: A vendor can't fix your internal security settings. What’s safe in a development environment can be dangerous on the public internet.

• Human error at cloud speed: New technologies are adopted with incredible velocity, especially open source solutions. It’s common to copy-paste a Docker command or a Terraform module from documentation or an example project in order to get started, often skipping the "harden for production" step. The problems begin when organizations forget to compensate for those early decisions once they’re ready to ship.

• Identical end result: Attackers don't care if they can gain initial access by exploiting a zero-day or by using an admin/admin user-password combination. The outcome is the same: remote code execution (RCE), data exfiltration, or a cryptominer consuming your compute.

We see four classes of these misconfigurations abused most often:

1. Unrestricted access: Services and endpoints that were never meant to be exposed to the public internet are left open, often without authentication or network controls.

2. Default/Weak credentials: Systems are left with simple or predictable passwords, and the ghost of `admin/admin` lives on - now amplified by AI-generated tutorials and quick-start guides that promote insecure examples

3. Excessive permissions: Anonymous or low-privilege users are granted the ability to perform high-impact, administrative actions.

4. Exposed databases: Databases are deployed without proper access controls or encryption, often accessible directly over the internet, allowing attackers to extract, modify, or delete sensitive data with minimal effort.

The chart below breaks down the prevalence of these misconfigurations based on our data:

Why Misconfigurations Happen

We believe that misconfigurations often emerge from the pace and culture of modern cloud development. Teams are under pressure to adopt new technologies quickly, and the cloud makes this especially easy with one-click deployments and endless new services to try. But the people spinning up these resources aren’t always security experts, or they might simply not have security in mind during testing, with security checks sometimes being an afterthought or something to be handled at a future date. When you add in the complexity of dynamic, large-scale environments - where configurations change rapidly and overlap across services - the chances of human error grow dramatically.

To demonstrate the real-world impact of these risks, here are three cases we’ve observed in the wild that show how simple setup flaws can escalate into full machine compromise or sensitive data leaks.

Case Study 1: Selenium Grid – Browser Automation as a Backdoor

• Background: Selenium Grid is a popular tool for routing automated browser tests across different environments. It’s incredibly simple to spin up, often with a single Docker command. According to our data around 1 in 4 cloud environments contain at least one instance of Selenium Grid.

• The misconfiguration: The official documentation clearly states that Grid "must be protected from external access." However, this warning is easy to miss, and countless instances are evidently left exposed to the public Internet.

• The abuse path: An exposed Selenium Grid can be instructed to run anything, not just a browser. Attackers use the --binary-location flag to point to the Python interpreter and pass -c to execute arbitrary commands. The result is instant RCE on the node. We've tracked a threat actor that abused this technique for over a year to run crypto-miners, completely unnoticed. That same foothold could just as easily be used for credential theft or intellectual property exfiltration. For more technical details see our blog describing the campaign.

Case Study 2: Spring Boot Actuator -  SSRF & Heap Dumps as a Service

• Background: Spring Boot is a popular Java framework with an "Actuator" module that exposes operational endpoints like health checks and metrics. According to our data over half of cloud environments have at least one Spring Boot Actuator instance.

• The misconfiguration: Key Actuator endpoints that can leak sensitive data or enable server-side request forgery (SSRF) are often left open without authentication. Of the publicly exposed instances we see, roughly a quarter are misconfigured.

• The abuse path (part 1): The /heapdump endpoint dumps the entire memory of the Java application. We've responsibly discovered AWS keys, database credentials, API tokens, and full user HTTP requests with session cookies inside these dumps.

• The abuse path (part 2): When Spring Cloud Gateway is enabled, the /actuator/gateway endpoint allows creating new routes. Without proper security controls, attackers can register arbitrary routes that forward traffic to internal services. This effectively turns the application into a proxy for server-side request forgery (SSRF), enabling access to sensitive internal resources such as databases or the cloud metadata service (IMDS), which can then be abused to steal cloud credentials.

Case Study 3: PostgreSQL – COPY Your Way to Code Execution

• Background: PostgreSQL is a relational database system known for its flexibility, allowing users to define custom data types, functions, operators, and extensions, while supporting advanced SQL features and complex queries. According to our data three out of four cloud environments contain at least one self hosted postgres instance.

• The misconfiguration: A combination of two factors: weak, easily guessable credentials and a powerful, built-in feature.

• The abuse Path: PostgreSQL has a feature, COPY FROM PROGRAM, that allows a database query to execute an arbitrary command on the underlying host. It's intended for data import/export, but when combined with a weak password, it’s a gift to attackers. This method is very popular and well known, it is even implemented and documented in Metasploit (the popular pentesting software):

Threat actors like the DreamBus botnet actively scan the internet for PostgreSQL servers with common credentials (postgres/password, etc.). Once in, they use COPY FROM PROGRAM to run malware, typically a crypto-miner, and then use the compromised host to scan for more victims.

Solving The Silent Risk: A Practical Plan

These exposures often don't leave obvious logs. If you aren't proactively looking for what’s exposed on your perimeter, you may never know how an attacker got in. Here’s how to start:

1. Gain full visibility - You can't protect what you don't know you have. Maintain an always-fresh inventory of your deployed services, technologies, and assets. This is where a comprehensive platform that continuously maps your external attack surface and internal assets is essential. You need to know what’s running, what version it is, and most importantly, what’s exposed to the internet.

2. Scan your perimeter proactively - Regularly scan your public-facing IPs and domains for the exact kind of misconfigurations attackers look for. 

3. Shift security left - Implement misconfiguration checks directly into your CI/CD pipeline. Use Policy-as-Code tools to programmatically block risky patterns before they ever reach production.

4. Educate and enable your teams - Developers and DevOps engineers must understand why a footnote in the documentation saying "don't expose this" is critical. Provide them with secure-by-default templates, Helm charts, and internal standards to make the secure path the easy path.

How Can Wiz Help?

Prevention:

The Wiz Dynamic Scanner identifies publicly exposed instances and detects exposed technologies. It continuously checks for common misconfigurations that may lead to critical security issues such as remote code execution (RCE), unauthorized access, and sensitive information disclosure.

Detection:

Wiz provides comprehensive detection capabilities across both build-time and runtime environments to help mitigate the risks outlined in this blog.

Our agentless workload scanner automatically identifies all the technologies mentioned, flagging potentially vulnerable instances before they can be exploited. Leveraging pattern-based malware detection, Wiz can also uncover compromised workloads even those targeted by adaptive and stealthy threat actors like DreamBus.

At runtime, the Wiz Runtime Sensor monitors for suspicious events and behaviors linked to these threats and beyond, alerting you as adversaries move through the attack kill chain. For example, the Runtime Sensor can detect a reverse shell initiated as part of a Selenium Grid exploit as described above.