From Prompt Injection to Web Exploitation: Revisiting Classic Vulnerabilities in LLM-Integrated Applications

This paper introduces and systematizes the concept of LLM-mediated web attacks, a class of attacks in which LLM-integrated web applications create new paths from attacker-controlled input to traditional web-application sinks. The paper argues that "in LLM-integrated web applications, prompt injection is best understood as a bridge to classical web vulnerabilities: once an LLM is trusted to choose tools and construct parameters, untrusted natural-language input can be translated into privileged backend actions."

The paper provides a structured analysis of representative LLM2 X variants, where (X) denotes the corresponding classical vulnerability class. These include:

• LLM2 SQLi: the model may generate or modify SQL queries that reach a database layer

• LLM2 CommandInjection: it may construct tool-call arguments that are passed to a vulnerable command-execution component, such as an MCP server

• LLM2 SSTI: model output may be interpreted as server-side template code

• LLM2 XXE: model-generated XML may later be parsed by an unsafe XML parser

• LLM2 SSRF and LLM2 IDOR: the model may construct requests to backend APIs or resources that lack proper request validation or access-control checks

• LLM2 CSRF: a classical CSRF mechanism may target LLM-specific state, such as an agent memory endpoint, causing poisoned context to be stored and later retrieved by the model

• LLM2 XSS: model-generated HTML or JavaScript-bearing content may become dangerous when rendered unsafely by the frontend

The paper notes that "the LLM usually does not create the underlying vulnerability itself; rather, it acts as a mediation layer, and in some tool-enabled settings as a confused deputy, carrying attacker influence into components that trust model-generated or model-influenced content. It also clarifies that prompt injection is not required in every case. For example, in LLM2 CSRF, the initial step may be a forged authenticated request that poisons an LLM-related state component, such as persistent memory, without requiring the model to process a malicious prompt at that moment."

As an experimental case study, the paper implements TicketOracle, a Flask-based LLM-integrated web application for evaluating LLM2 SSRF across five attack scenarios and seven LLMs. The testbed consists of a public-facing application and a localhost-only administrative API, with an AI assistant implemented as a tool-using agent that can fetch URLs. The five attack scenarios are:

1. Internal Port Probing (DA1): The attacker forces the model to send requests to a specific port on the host... and infers from the agent's reply whether a service is listening.

2. Sensitive Data Leak (DA2): The attacker forces the model to fetch a URL that points to a protected administrative endpoint... The endpoint can return user records... which the agent then summarizes in its natural-language reply.

3. Unauthorized State Change (DA3): The attacker forces the model to access a URL corresponding to a state-changing administrative route... Then, the agent reports the confirmation returned by the route in its natural-language reply.

4. Blind SSRF (DA4): The attacker forces the model to fetch a URL whose response body is empty by design but whose side effect on application state is identical to that of DA3.

5. Indirect Prompt Injection (IA): "the attacker plants a review that contains a hidden instruction for the agent. Later a benign user asks the agent for that event; the agent reads the review as part of its tool result and treats the embedded instruction as authoritative."

The experiments were conducted with seven LLMs: Llama 3.3 70B Instruct, Qwen3 Coder 480B, DeepSeek R1, GPT-oss 120B, GPT-5.2, Gemini 3 Pro Preview, and Claude Opus 4.6. The results show that "under the non-hardened variant, the four direct scenarios (DA1-DA4) succeeded against five of the seven models, typically at or near ceiling against three models (Llama, Qwen, DeepSeek), with more mixed behavior on GPT-two." Specifically:

• Llama 3.3 70B Instruct reached ceiling on every direct scenario.

• Qwen3 Coder 480B and DeepSeek R1 reached ceiling on DA2 and DA3 but scored 7/10 on DA4 (Blind SSRF) and, in Qwen's case, 9/10 on DA1.

• Claude Opus 4.6 and GPT-5.2 were the only models that not a single attack was successful.

• GPT-oss exhibited a less uniform profile, scoring 3/10 on DA1, 10/10 on DA3, and 0/10 on both DA2 and DA4.

• Gemini 3 Pro Preview refused DA1 and DA4 but did not refuse the two endpoint-fetching scenarios, scoring 7/10 on DA2 and 10/10 on DA3.

The paper concludes that susceptibility varies substantially across models, suggesting that the vulnerability is rooted in the surrounding application architecture while the likelihood of successful exploitation depends strongly on the model. The prompt-hardened variant blocked all four direct scenarios across every model in the panel, as expected, but did not provide a uniform guarantee against stored or indirect prompt injection: in some cases, the same hardening could still be bypassed when the adversarial instruction arrived inside tool-returned data. Specifically, Llama 3.3 results shifts from 6/10 to 10/10, GPT-oss moves from 5/10 to 0/10, and the other five models remain at 0/10 for the IA scenario under hardening.

The paper concludes with mitigation strategies across four layers:

• Prompt-Level Mitigations: Prompt-level restrictions aim to constrain the model before its output reaches the execution point... should be treated as a guardrail rather than the ultimate security boundary.

• Model-level Mitigations: newer model variants often appear to enforce stricter behavior against offensive security prompts... this behavior should not be treated as a security guarantee.

• Application-Level Mitigations: "Mitigations enforced in the application's own logic are the most important protections, because unlike prompt-level restrictions, they do not depend on the model's compliance... Model-generated parameters should therefore be treated as untrusted input and validated before they are used."

• Network-Level Mitigations: Deny-by-default egress rules and explicit allow-lists of trusted destinations can remove the agent's ability to reach internal targets in the first place.

The paper's contributions are: (1) introducing and systematizing LLM-mediated web attacks, (2) experimenting with 7 different models in the LLM2 SSRF attack scenario, and (3) releasing the TicketOracle testbed as open-source.

Based on this paper, I can implement the following concrete improvements to AI systems:

1. Input/Output Validation Layer for Tool Calls

• Add a mandatory validation layer that treats all model-generated tool parameters as untrusted input, regardless of how benign the prompt appears.

• Implement schema-based validation for every tool call (e.g., URL must match an allowlist regex, SQL queries must pass through a parameterized query builder, file paths must be canonicalized and checked against permitted directories).

• The improved system can reject or sanitize any tool argument that does not conform to strict application-level rules, independent of model behavior.

2. Network Egress Control Integration

• Integrate a deny-by-default egress firewall that restricts the agent's network access to a pre-approved allowlist of domains and IP ranges.

• The system can automatically block any HTTP request to localhost, private IP ranges (e.g., 127.0.0.0/8, 10.0.0.0/8, 169.254.169.254), or non-allowlisted external hosts before the request is sent.

• This makes SSRF attacks impossible even if the model is fully compromised.

3. Context-Aware Privilege Separation

• Implement a privilege separation mechanism where the LLM operates with the minimum necessary permissions for each task.

• For example, a read-only agent cannot invoke state-changing API routes; a summarization agent cannot access user records unless explicitly authorized per-request.

• The improved system can enforce role-based access control on every tool invocation, based on the current user's session and the specific task context, rather than trusting the model's judgment.

4. Stored-Data Integrity Checking

• Add a content-integrity check for all data retrieved from external sources (e.g., reviews, documents, web pages) before it is fed into the model's context.

• The system can detect and neutralize hidden instructions embedded in tool-returned data by stripping out non-content markup, separating data from executable directives, or using a separate data channel that the model cannot treat as authoritative commands.

• This mitigates indirect prompt injection attacks where adversarial instructions arrive via tool results.

5. Response Sanitization for Frontend Rendering

• Apply output encoding and sanitization to all model-generated HTML, JavaScript, or XML before it is rendered in the frontend.

• The improved system can automatically escape or strip dangerous constructs (e.g., ``, event handlers, external entity references) to prevent XSS and XXE, regardless of what the model generates.

6. Anomaly Detection on Tool-Call Patterns

• Add a monitoring layer that tracks the sequence and frequency of tool calls per session, flagging unusual patterns (e.g., a single prompt triggering multiple internal port scans, or repeated requests to admin endpoints).

• The system can automatically halt execution and require human approval when such anomalies are detected, providing a runtime safety net.

7. Hardened Prompt Template with Data/Instruction Separation

• Redesign the system prompt to explicitly instruct the model that tool-returned data is untrusted and must never be treated as instructions, while also embedding this as a structural constraint (e.g., using special tokens to mark data boundaries).

• The improved system can combine this with the validation layer to reduce reliance on model compliance, making indirect injection significantly harder.

What the improved AI system can do:

• Operate safely in web-integrated environments even when the underlying LLM is susceptible to prompt injection, because security does not depend on model behavior.

• Perform legitimate tool-using tasks (e.g., fetching URLs, querying databases) while being structurally incapable of reaching internal-only resources or executing unauthorized state changes.

• Resist both direct and indirect prompt injection attacks, including those that arrive via stored data, by treating all external content as data, not commands.

• Provide a clear audit trail of all tool calls and their validation results, enabling post-hoc security review and rapid incident response.

• Maintain functionality across diverse LLMs (including weaker or more gullible models) without requiring model-specific hardening, because the security boundary is enforced at the application and network layers.