When we think about automated vulnerability discovery, it is natural to start with the code.
An application contains an endpoint. The endpoint processes user input. Somewhere along the way, that input reaches a sensitive operation. Perhaps there is an authorization mistake, an injection, an insecure direct object reference, or another recognizable vulnerability pattern.
This is the kind of problem that lends itself naturally to code analysis. But modern applications are rarely made up entirely of code written by the application team.
They are built on frameworks and libraries. They depend on infrastructure. They integrate with identity providers, cloud services, message brokers, databases, storage systems, third-party APIs, and specialized products.
This creates an interesting class of security problems - sometimes, the application code has no vulnerability. And yet, when we test the running application, we can discover a critical security issue. How?
When the code is doing exactly what it was designed to do
Consider a component that provides a powerful feature.
The feature itself is not a vulnerability. The underlying product is not vulnerable. The application may even use the product exactly as its documentation describes.
The problem appears when we consider the context in which that feature is exposed. A capability that is perfectly legitimate in one context can become a powerful attack primitive in another. This is what we refer to as misconfiguration.
The term can sound deceptively simple. It can make the problem seem easy to detect: find an incorrect setting, report it, and move on. In practice, it can be considerably harder.
The technology may be unfamiliar
A modern application can rely on dozens of technologies outside the application’s own codebase. Each one brings its own configuration model, security boundaries, and capabilities.
A pentest agent encountering a new product must first understand what it is and what it can do. Only then can it reason about whether its deployment creates an interesting attack surface.
The difficult question is often not, “Is this component vulnerable?” It is, “What can an attacker make this component do from this application?”
That is a fundamentally different question.
The security boundary may exist outside the source code
The relevant configuration may not exist in the repository at all.
The source code might show an application making a perfectly reasonable call to a service. The security implications depend on how that service is deployed, which interfaces it exposes, what permissions it has, and how another component is configured.
The application code alone does not necessarily describe the application’s attack surface. The deployed system does.
A feature does not have to be a vulnerability to become one
Perhaps the most subtle case is when nothing is actually broken.
A product exposes a feature intentionally; the feature works as documented. No CVE exists, and no function in the application code looks obviously dangerous. And yet, the way the application exposes that feature allows an attacker to use it in a way the developers did not intend.
This is where vulnerability discovery becomes less about finding a known bad pattern and more about understanding capabilities and consequences.
- A feature can become an attack primitive.
- A legitimate integration can become a privilege boundary violation.
- A deployment decision can turn a low-risk capability into a path toward sensitive data or privileged actions.
The vulnerability only becomes apparent when we connect the pieces.
A real example: FreeSWITCH
One example we encountered illustrates this particularly well.
During signal generation, our system identified FreeSWITCH, an open-source communications platform, as part of the technology stack.
At first glance, using FreeSWITCH seems harmless. It provides powerful telephony capabilities, and many of them are intentionally exposed through its configuration and APIs. But that is precisely what made it interesting.
FreeSWITCH exposes an Event Socket interface through mod_event_socket. Once authenticated, clients can execute FreeSWITCH API commands through the socket. The API command set includes the system command, which can execute a system command on the host. (SignalWire Documentation)
At the same time, FreeSWITCH’s SIP functionality can be configured to accept registrations. Its Sofia SIP profiles include configuration options controlling registration and authentication behavior, including options such as accept-blind-reg and accept-blind-auth. (GitHub)
None of these capabilities is a vulnerability on its own. They are features.
The interesting question is what happens when the relevant capabilities are combined with the way the instance is deployed.
An exposed registration surface can give an attacker access to telephony functionality. An exposed and insufficiently restricted Event Socket can provide access to FreeSWITCH’s API capabilities. The Event Socket documentation specifically recommends restricting remote access with a narrowly scoped ACL and a strong password when it needs to be reachable beyond the local host. (SignalWire Documentation)
The resulting security issue therefore does not sit in a vulnerable function in the application’s source code. It emerges from the configuration of a powerful third-party component and the capabilities that configuration makes reachable.
This is exactly the type of problem that traditional code-centric signal generation can miss. There is no simple sink to trace, and there may be no vulnerable line of application code.
Instead, we need to understand the technology, research its capabilities and configuration options, connect those capabilities to the attack surface, and then determine whether the combination creates a meaningful path to impact.
And that is precisely where our new capability comes in.
Introducing the Misconfiguration Researcher
We built the Misconfiguration Researcher to address this gap.
Rather than relying only on a predefined list of known misconfigurations, it starts with the technology actually present in the application.
It first identifies relevant technologies in the stack. It then researches those technologies and their security-relevant capabilities, looking for configuration combinations that could give an attacker meaningful leverage.
The goal is not simply to ask, “Is this configuration insecure?” It asks, “What does this technology enable, which configuration choices control those capabilities, and could the way this application is deployed turn them into an attack path?”
The result is a new type of security signal. Instead of finding a suspicious line of code, the system can identify a potentially dangerous system configuration and hand that hypothesis to the validation phase.
From code analysis to system understanding
This is an important distinction in how we approach automated pentesting. Modern applications are not just source code.
They are systems assembled from:
- application code
- frameworks and libraries
- infrastructure
- third-party products
- integrations
- deployment configuration
- permissions
- exposed interfaces
- and the behavior that emerges from all of them
A strong pentest needs to reason across those boundaries. That is why signal generation cannot stop at identifying suspicious code patterns.
Sometimes the most important security finding is not hiding in a vulnerable function. It is hiding in the space between components. The Misconfiguration Researcher is designed to explore that space.
