# LLM-Mediated Web Attack Payload in Outbound HTTP

- **Severity:** High
- **Signature ID:** `7c4e1b0a-9d3f-4a52-b8e1-2f6c5d0a91e7`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM01 (Prompt Injection), LLM05 (Improper Output Handling)

## Summary

An LLM-based agent can be tricked into producing text that looks like a classic web attack payload — a SQL injection string, an XSS script tag, a template injection expression, a command injection sequence, or a path traversal string — and then sending that text out in an HTTP request. This rule flags the moment that payload leaves the agent as HTTP traffic, before anyone knows whether the receiving system actually acted on it.

## How the attack works

An attacker crafts input to the LLM so that the model, acting as a 'confused deputy', generates attacker-controlled text containing a known injection pattern (SQL syntax, script tags, expression-language syntax, shell metacharacters, XML external-entity references, or path traversal sequences). The agent then embeds this text in an outbound HTTP request — as body content or in the query string — directed at some backend API, database proxy, or web endpoint. The rule watches only this HTTP hand-off point; it has no visibility into the database, template engine, or XML parser on the receiving end, so it cannot confirm the payload was actually interpreted as code by whatever received it.

## Why it matters

If the downstream system does interpret the payload, the result can be data theft or corruption (SQLi), stored script execution against other users (XSS), server-side code execution (SSTI/command injection), disclosure of internal files or cloud metadata (XXE/SSRF/path traversal). Even when this rule fires without confirmation of a successful sink, it means an AI agent produced and transmitted attacker-shaped exploit text, which is itself a sign the input filtering or prompt handling upstream failed.

## What you can do

- Treat every alert as a signal to check what received the request and whether it parsed the payload as code, not as proof of compromise.
- Add strict output filtering and encoding on anything an LLM agent sends to HTTP APIs, databases, or template engines, regardless of this detection.
- Review the target endpoints of flagged requests for injection-safe handling (parameterized queries, output encoding, safe XML parsing, sandboxed templates).
- If your security team runs DAST/fuzzing tools through the same agent pipeline, tag or corpus-mark that traffic so it isn't confused with a real attack path.

## Known benign look-alikes

- Application security teams running DAST, fuzzing or penetration-testing tooling through an agent - suppressed by filter_testing_corpus when the tool name or a known payload corpus appears in the same request body, but a hand-rolled scanner with no recognisable marker will still be reported.
- CI pipelines posting security test-suite fixtures (XSS/SQLi assertion vectors) to a test-reporting or coverage API - suppressed by filter_testing_corpus.
- Documentation, knowledge-base or ticketing writes describing an injection vulnerability, including CVE write-ups and remediation guides - suppressed by filter_documentation.
- WAF, ModSecurity CRS, Sigma, Snort or Suricata signature-management API calls that carry attack patterns as rule bodies - suppressed by filter_security_control_config.
- Legitimate GraphQL or ORM traffic containing the literal word UNION or SELECT - not matched, because every SQLi pattern requires a preceding quote, paren or semicolon syntax break rather than the bare keyword.
- Templating and i18n payloads that use {{ }} or ${ } interpolation - not matched, because the SSTI patterns require an arithmetic probe, a dangerous runtime internal, or a JNDI/Java reflection token rather than bare interpolation.
- Cloud SDKs fetching instance metadata directly - not matched, because the SSRF patterns require the metadata endpoint to appear as a parameter or JSON string value inside a request body, not as the request destination itself.
- Markdown or HTML content-management writes that include a <script> tag - not matched unless an execution sink such as document.cookie, eval( or alert( is also present within the same tag.
- Windows-style relative paths containing ..\ in build tooling - only matched when a named sensitive target such as win.ini or web.config also appears, or when the dot-dot is percent-encoded.

## References

- https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/
- https://owasp.org/Top10/A03_2021-Injection/
- https://atlas.mitre.org/techniques/AML.T0051

---
Source: https://www.netzilo.com/threats/llm-mediated-web-attack-payload
