AI-powered scanner vulnerabilities

Application security teams often deploy AI-powered scanners that use Large Language Models (LLMs) to scan web applications for vulnerabilities.

While designed to improve security testing efficiency, these agents introduce a new attack surface. If a scanner can be influenced by attacker-controlled content, it may be manipulated into performing unintended actions, accessing internal resources, or exfiltrating sensitive information.

In this section, we'll explore how these agents operate and the techniques that can be used to compromise the scanning environment.

What are AI-powered web application security scanners?

AI-powered scanners are web security testing tools that combine traditional crawling and request generation with LLM-driven reasoning. Like traditional Dynamic Application Security Testing (DAST) scanners, they can:

• Authenticate as users.
• Crawl applications.
• Send HTTP requests.
• Chain multiple actions.

Traditional vs. AI-powered scanners

The key difference between traditional and AI-powered scanners is how decisions are made.

Traditional scanners use a rigid, instruction-based architecture. Because these tools lack semantic understanding, they cannot "read" a page to determine its purpose. Instead, they rely on pattern matching and known vulnerability signatures.

In contrast, AI-powered scanners replace rigid logic with autonomous reasoning. Rather than following a static script, these tools use LLMs to interpret web content and plan their next actions.

Some key behaviors of AI-powered scanners from a security perspective include:

• Using LLM reasoning to decide what to test next. They evaluate the state of the application to determine a logical next step.
• Interpreting application responses semantically. They "read" the text in a response to understand its context, enabling them to identify complex business logic that a traditional scanner might ignore.
• Selecting tools and constructing requests based on model output. Some AI scanners use "tool-calling" capabilities to interact with APIs, databases, or UI elements based on their own internal reasoning.

AI-powered scanner vulnerabilities

Most AI-powered scanner vulnerabilities arise when attacker-controlled content influences the scanner's reasoning and tool usage. This occurs because these scanners treat the text they analyze as a source of information to plan their next move. If the AI model cannot reliably distinguish between application data and instructions, then untrusted content can alter scanner behavior.

Indirect prompt injection in AI-powered scanners

Indirect prompt injection is a significant risk with AI agents. This occurs when an attacker embeds malicious instructions in stored content, which the scanner then treats as part of its action plan.

The attack typically follows this sequence:

1. Malicious instructions are embedded in stored content, for example, within comments or blog posts.
2. The scanner reads this content during its crawl process.
3. The LLM interprets the injected text as actionable instructions rather than passive data.
4. The scanner executes tool calls or generates requests based on the injected text.

This can lead to tool misuse. Some common consequences of this include:

• Performing unintended state-changing actions. For example, the scanner might delete users or modify account settings.
• Accessing sensitive data. The scanner may be instructed to access database records or configuration files.
• Making unauthorized internal requests. The scanner may interact with internal APIs that are not exposed to the public internet.

These vulnerabilities can have severe consequences because scanners often run inside internal networks, operate with authenticated sessions, and have access to APIs or services unavailable to external users.

Conceptually, this attack resembles Cross-Site Request Forgery (CSRF). In both cases, the attacker cannot directly perform the protected action themselves. Instead, they trick a more-privileged actor into doing it on their behalf. In this scenario, that actor is an LLM-driven autonomous agent rather than the user's browser.

Crafting effective injection prompts

The phrasing and framing of an injection prompt can significantly affect its chances of success. A simple instruction like "delete user carlos" is less likely to succeed than one that presents itself as authoritative or legitimate.

Common techniques include:

• Adopting a persona: Framing the instruction as coming from a trusted source, such as a security researcher or system administrator, can make the LLM more likely to comply.
• Social engineering: Presenting the instruction as a legitimate request (for example, a security finding that requires verification) can make the instruction appear credible and reduce the chance the model refuses it.
• Urgency and consequence: Implying that the instruction is required to prevent harm or data loss can reinforce compliance.

Data exfiltration via AI-powered scanners

Data exfiltration is a common consequence of indirect prompt injection. While an attacker might use prompt injection to trigger state-changing actions, they can also use it to disclose sensitive information that is otherwise inaccessible.

The attack typically follows this sequence:

1. The scanner retrieves sensitive data as part of its normal testing workflow, such as crawling an admin-only configuration page or an internal API.
2. The attacker provides malicious instructions via untrusted content, for example a product review, that the scanner processes during its crawl.
3. The injected prompt directs the LLM to disclose the sensitive data.
4. The scanner outputs the sensitive data to a location visible to the attacker, for example by posting it in a public-facing form or a feedback field.

For example, a scanner might be tricked into "testing" an internal endpoint and then posting the retrieved credentials publicly.

Exploiting routing-based SSRF to bypass restrictions

Even if high-risk APIs are restricted and sensitive data is protected, AI-powered scanners can still be manipulated into making unintended internal requests. This is because scanners typically run inside the internal network and can construct arbitrary HTTP requests, effectively making them a programmable Server-Side Request Forgery (SSRF) vector.

One way to exploit this is through routing-based SSRF. This can occur via several mechanisms, including open redirects, URL interpretation discrepancies between components, and Host header manipulation. In each case, the attacker exploits a flaw in how the application or its infrastructure handles request routing to redirect the scanner to an unintended destination.

Host header manipulation is a particularly powerful technique in this context. Web applications often use the Host header to route requests to the correct internal service. By modifying this header, an attacker can redirect the scanner's requests to internal services that would normally be inaccessible from the public internet.

The attack typically follows this sequence:

1. The attacker injects a prompt instructing the scanner to send a request to an internal path, such as /admin, with a modified Host header pointing to an internal IP address.
2. The scanner executes the request from its privileged position inside the internal network.
3. The response is processed by the scanner and can be exfiltrated back to the attacker, for example by posting it as a comment.

This chains three elements that individually pose significant risk, but together enable a potentially even more severe attack:

• Prompt injection gives the attacker control over the scanner's reasoning.
• Host header manipulation controls where the request is routed.
• The scanner's privileged network position provides access to internal resources an external attacker cannot reach directly.

In this scenario, the scanner is not just a victim of an attack, but a tool used to exploit classic web vulnerabilities from a position of trust that an external attacker could not otherwise reach.

Defending against AI-powered scanner vulnerabilities

To mitigate the risks associated with AI-powered scanners, we recommend you apply robust security principles that assume the scanner's reasoning engine can be compromised. Even if an attacker successfully influences the LLM's plan via indirect prompt injection, the scanner's environment and permissions should remain constrained.

Secure design principles

We recommend you apply the following design principles:

• Restrict scanner credentials and access controls. Apply the principle of least privilege by providing the scanner only with the permissions necessary for the current test.
• Separate scanning identity from admin identity. When configuring an AI-powered scanner, use dedicated testing accounts that do not share the same permissions as real admin users to prevent privilege escalation.
• Apply server-side controls to the scanner. Do not assume an LLM-driven scanner will correctly enforce policy or "refuse" malicious instructions. Always enforce access controls at the application or API level rather than relying on the model's internal logic.
• Treat all user-modifiable content as untrusted input. Assume any text retrieved from a database, such as a comment or profile field, is a potential injection vector that can alter the scanner's behavior.