More and more organizations store customer information, financial records, and internal documents in SaaS and cloud environments. The promise is clear: speed, scalability, and access “anywhere.” But that convenience comes with a serious risk—one small configuration mistake can turn sensitive data into something the public can reach.
This is where misconfiguration risks matter. Threat actors routinely scan the internet for exactly the kind of access and settings errors that make data discoverable or downloadable. Recent incidents show that the root cause is often not a broken product, but an incorrect setup on the customer side.
Why misconfiguration is different from a vulnerability
When people hear about “security flaws,” they often think of software bugs that can be patched. With misconfigurations, the story is different. There may be no technical vulnerability to fix, because the system works the way it was designed to work.
The problem is that access is configured incorrectly. Instead of limiting what users and systems can view or request, settings may allow more access than intended. Attackers exploit the exposed functionality rather than breaking through defenses.
Common examples include guest accounts with overly broad permissions, an API that can be reached without proper authentication, or a default setup that was never tightened after initial deployment.
The bigger the SaaS footprint, the larger the attack surface
Organizations increasingly rely on SaaS platforms and low-code environments to build and deliver applications quickly. Low-code approaches allow users to assemble functionality visually, which can speed up development without requiring deep programming expertise.
However, this also increases the chance of access-control mistakes. If permissions, roles, and authentication settings are not carefully managed, the environment may unintentionally allow anonymous or lightly authenticated access paths.
One reason the risk is so difficult to manage is scale. Organizations often use many SaaS applications at the same time, and each platform introduces its own configuration choices. This creates a larger surface where misconfiguration risks can hide.
Recent examples of misconfiguration-driven data exposure
Two developments from late 2025 into early 2026 illustrate how attackers can turn configuration errors into high-impact outcomes.
Wrongly configured Salesforce Experience environments
Attackers reportedly abused misconfigured Salesforce Experience Cloud environments. In these cases, guest users had permissions that were too permissive. As a result, data could be accessed without authentication through Salesforce’s Aura API.
Salesforce clarified that the issue was not a platform vulnerability, but configuration errors committed by customers. Mandiant later published AuraInspector, a tool intended to help Salesforce administrators identify these misconfigurations, though it was soon followed by reports of misuse of a modified version. The group involved claimed to have affected hundreds of organizations.
Mendix low-code authorization issues
A separate investigation by DIVD focused on authorization misconfigurations in applications built on the Mendix low-code platform. Based on a large-scale scan, DIVD reported that it found multiple incorrectly configured applications.
In those applications, too many permissions were granted to anonymous users or newly registered users. DIVD indicated that exposed data could include names, contact details, addresses, customer data, and documents such as identity-related information.
How attackers exploit misconfigurations (typical five-step pattern)
While each incident has its own details, the overall approach often follows a recognizable sequence. Attackers start by finding targets automatically, then validate what they can access, and finally gather and monetize the data.
A common five-phase flow looks like this:
- Reconnaissance: Attackers scan the internet automatically to find systems with misconfigurations.
- Identification: They confirm whether the environment is configured incorrectly.
- Gaining access: Using legitimate functionality or standard APIs, they request data or broaden their effective (admin) privileges.
- Collecting data: Sensitive items such as authentication-related information are gathered and exfiltrated.
- Misusing data: Stolen data can be used for extortion, resale, phishing campaigns, or further intrusion attempts.
Importantly, attackers often blend their requests into normal-looking traffic patterns. Because they use standard platform features, the behavior can be hard to distinguish from routine use—making misconfiguration risks a challenge for detection alone.
From data theft to extortion and downstream fraud
Once data is obtained, financial motivation typically follows. Organizations may be pressured to pay to prevent publication of stolen information. In some cases, attackers also incorporate media-related pressure by contacting journalists or posting details on public channels, amplifying the urgency to respond.
Beyond extortion, the stolen data can be used for other forms of harm. Names, phone numbers, email addresses, and internal notes can enable phishing, fraud, and targeted outreach to employees or customers. These datasets are also frequently traded through underground marketplaces.
Preventing misconfiguration risks: practical measures
Reducing misconfiguration risks starts before a system is ever exposed in production. The key is to prevent unsafe configuration from the outset and to maintain it as environments evolve.
Create an up-to-date inventory
Begin by building and maintaining a current inventory of platforms, cloud services, and applications. Map configuration settings and access rights across environments so you know what exists and who can do what.
Apply least privilege
Use the principle of least privilege. Separate administrator and user roles, disable anonymous access where it is not strictly required, and pay extra attention to guest accounts and application-level permissions.
Require multi-factor authentication for admins
Make multi-factor authentication (MFA) mandatory for all administrator accounts. Even when a misconfiguration exists, stronger authentication can reduce the likelihood of successful misuse.
Harden before go-live
Avoid relying on default settings. Adjust insecure defaults before systems enter active use. Also consider adopting hardening benchmarks and guidance such as CIS Benchmarks or NIST recommendations.
Detection is harder when attackers use legitimate features
Because misuses can be carried out via normal platform functions, simply looking for “obvious hacking” may not be enough. Instead, focus detection on behavioral anomalies—things like unusual access patterns, unexpected volumes of requests, and changes in context.
Turn on audit logging and ensure logs are collected centrally. Then analyze them on a regular basis rather than waiting for an incident. This makes it easier to spot patterns that deviate from baseline usage.
If something goes wrong: assume exposure happened
Preparedness matters because time is rarely on your side. If you discover that an access misconfiguration existed long enough to allow access, treat it seriously.
In incident response, assume that the data that should have been protected—and was visible or reachable—may also have been taken. The longer a misconfiguration remains, the higher the chance that it was eventually exploited.
When personal data might be involved, follow applicable guidance for notifying affected individuals. For example, the Data Protection Authority (AP) provides information on communicating about data breaches on its website.
Make it a process, not a one-time checklist
Misconfiguration risks are not new, but they remain persistent—often created under deadline pressure and left behind after initial setup. For that reason, organizations need structural attention, not only an occasional configuration review.
A practical starting point is to look at widely recognized top misconfigurations. SURF translated the top 10 misconfigurations from a joint NSA and CISA advisory into Dutch, including relevant recommendations. Use such resources to benchmark your current controls and close the most common gaps.
The core idea is simple: closing the “door” begins with knowing whether it is open in the first place. When visibility and governance improve, misconfiguration risks shrink.
Where to go deeper
If you want additional context and more detail on how misconfigurations can enable access to sensitive data, the NCSC published a CTI report titled “Misconfiguraties bieden kwaadwillenden toegang tot gevoelige gegevens”. It is available through the NCSC Community, which requires membership.
With better inventory, least-privilege access, hardened defaults, strong authentication, and targeted detection, you can significantly reduce the chance that a configuration slip turns into a breach.
Source: https://www.ncsc.nl/expertblogs/misconfiguraties-bieden-open-deur-tot-gevoelige-gegevens
