LLM framework security risks expose classic injection failures

At a glance

What this is: Flatt Security maps six LLM framework failure patterns, including SSRF, path traversal, SQL injection, RCE, SSTI, and DoS, back to familiar application security controls.

Why it matters: It matters because AI application teams often inherit classic injection and execution risks through framework abstractions, so IAM, platform, and application security owners need to govern prompts, paths, URLs, and execution boundaries together.

Context

LLM frameworks reduce development effort by wrapping retrieval, tool use, template handling, and execution into reusable abstractions, but those abstractions also concentrate security decisions in a few risky interfaces. When user input can shape URLs, file paths, SQL, templates, or code execution, the problem is no longer just model quality. It becomes an application security and governance issue, with clear identity implications when agents or tools act on behalf of users or services.

The article is best read as a reminder that familiar injection classes do not disappear in AI applications. They reappear through prompt pipelines, tool connectors, and helper functions, which means security teams need controls that treat LLM frameworks as execution surfaces rather than passive libraries.

Key questions

Q: What breaks when LLM frameworks expose code execution or dangerous request features?

A: They turn prompt or input handling into an execution path. If code execution, arbitrary requests, or similar features are left enabled, a crafted prompt can become server-side command execution, internal network access, or data exfiltration. The key failure is not the model itself but the framework’s willingness to treat untrusted text as trusted instruction.

Q: Why do URLs, paths, and SQL become high-risk in LLM applications?

A: Because the framework may pass untrusted text directly into a sensitive sink. Without strict validation, a URL can trigger SSRF, a path can escape its directory, and generated SQL can alter data unexpectedly. The security issue is not the AI model alone. It is the failure to constrain what the model output is allowed to become.

Q: What do security teams get wrong about prompt engineering tools?

A: They often treat them as developer productivity tools instead of control systems. The better platforms help prove that a prompt change is safe, detectable, and reversible. If the workflow does not include test data, metrics, and production monitoring, it is not yet managing operational risk.

Q: Should organisations treat LLM framework risks as application security or AI governance?

A: Both, but application security comes first because the failures are concrete injection and execution problems. AI governance sets the rules for acceptable behaviour, while application security enforces those rules at the URL, path, query, template, and command boundary. If the boundary is weak, governance statements alone will not prevent exploitation.

Technical breakdown

Deprecated options create hidden execution paths in LLM frameworks

LLM frameworks often keep experimental or deprecated switches for developer convenience, but those options can quietly preserve unsafe behaviours in production. If a tool allows arbitrary code execution, unrestricted requests, or other high-flexibility functions, the framework becomes an execution broker rather than a simple orchestration layer. The security issue is not the model itself. It is the combination of permissive framework defaults, untrusted input, and insufficient review of what the helper function can actually do at runtime. That is why design-time decisions matter so much here: once the application exposes a dangerous option, later validation is often too late.

Practical implication: remove or disable dangerous framework options before deployment, and treat any code-execution feature as a high-risk capability boundary.

External URLs, file paths, and SQL become attack surfaces when user input is passed through

Several case studies in the article show the same pattern: a framework accepts external input and passes it into a sensitive sink without strict validation. A URL loader can be abused for server-side request forgery, path concatenation can be abused for traversal, and natural-language SQL generation can become SQL injection when the output is not constrained. These are classic injection problems, but the AI layer makes them easier to miss because the dangerous action may be hidden behind a convenience API. The underlying defect is not novelty. It is failure to validate what the framework is asked to fetch, open, or query.

Practical implication: validate URLs, paths, and generated SQL with allowlists and structural checks before the framework can act on them.

Template rendering and tool execution need sandboxing, not trust

LLM frameworks frequently mix data with templates, or allow generated text to flow into code-like execution environments. That creates server-side template injection and remote code execution risk when attacker-controlled content reaches a rendering engine or command interface. The article’s lesson is that sandboxing helps only when it is paired with strict separation of template logic from user data and with very narrow execution permissions. In practice, these controls are about preserving a hard boundary between what the user can influence and what the server will execute. Without that boundary, the framework becomes a code path disguised as a helper library.

Practical implication: keep templates immutable, sandbox renderers, and restrict any external command execution to the smallest possible permission set.

Threat narrative

Attacker objective: The attacker aims to turn convenience functions inside the LLM stack into unauthorized data access, code execution, or service compromise.

1. Entry occurs when an attacker supplies malicious input through a URL field, path field, natural-language query, or template parameter exposed by an LLM framework.
2. Credential or execution abuse follows when the framework passes that input into a sensitive sink such as a request handler, SQL generator, template engine, or code execution helper without validation.
3. Impact is achieved through SSRF, path traversal, SQL injection, RCE, or service disruption, depending on which sink the attacker reaches first.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM framework security is still application security, not model security. The article’s real value is that it strips away AI novelty and exposes familiar injection patterns in new wrappers. That matters because many teams are treating framework abstraction as a security control when it is really a new trust boundary. Practitioners should assume the old rules still apply: validate inputs, constrain sinks, and govern what the framework is allowed to execute.

Classic injection failures become easier to miss when they are hidden inside orchestration layers. Prompt pipelines, tool connectors, and helper libraries can obscure the moment where user-controlled data becomes an executable action. The governance gap is not lack of AI policy alone. It is weak control over the transition from text handling to request, query, render, or code execution. Security teams need to review that boundary as aggressively as they review direct application code.

LLM application teams now need a named concept for this risk: execution-sink leakage. That is the point where a framework turns untrusted text into a live request, query, template, or command without adequate validation. Once that boundary is crossed, conventional injection threats reappear under AI branding. The practitioner conclusion is straightforward: treat every framework helper that touches a sink as part of the attack surface.

Identity and authorization assumptions also change once agents can act through framework tools. When an LLM is allowed to fetch URLs, read files, query databases, or execute code on behalf of a user, the relevant question is not only whether the input is valid. It is whether the resulting action should inherit the same authority as the requester. That makes least privilege and explicit authorization checks essential for agentic and non-agentic AI systems alike.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Execution-sink leakage: the key governance risk is the point where a framework turns untrusted text into a live request, query, template, or command. Security teams should map those sinks explicitly, because AI wrappers often hide where the trust boundary really sits.

LLM adoption will keep expanding, but the control model has to stay grounded in input validation, sandboxing, and least privilege. In practice, the organisations that fare better will be the ones that review framework helpers as privileged code paths, not as neutral orchestration layers.

For practitioners

• Disable dangerous framework options by default Remove experimental, deprecated, or overly permissive functions from production builds unless the business case is explicit and reviewed.
• Validate all externally supplied URLs and paths Apply allowlists, character restrictions, and root-boundary checks before a loader or file helper accepts user-controlled input.
• Constrain generated SQL and template inputs Use strict query whitelisting, separate template logic from data, and reject any input that can change execution structure.
• Sandbox any required code or command execution Keep execution in a restricted environment, remove unnecessary imports and system calls, and time out long-running requests.
• Review AI tool permissions as an access problem Treat URL fetches, database queries, file reads, and code execution as privileged actions that require explicit approval boundaries.

Key takeaways

• LLM frameworks do not eliminate classic injection risk. They often repackage it inside loaders, query builders, renderers, and execution helpers that accept untrusted input.
• The most common failure is a weak boundary between text and action. Once user-controlled content reaches a request, query, template, or command sink, the framework can become the attack path.
• Security teams should govern these systems like application code with privileged operations. That means strict validation, sandboxing, removal of unnecessary execution features, and explicit least-privilege boundaries.

Key terms

• LLM Application Framework: An LLM application framework is a software layer that reduces the custom code needed to build model-powered products. It can handle retrieval, orchestration, prompt optimization, structured output, or streaming. The value is less about the model itself and more about organizing the surrounding application logic reliably.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Path Traversal: A bug where crafted path segments such as ../ allow input to escape an intended directory boundary. In practice, it turns a normal file operation into a boundary break, which is especially dangerous when the affected service runs with non-human identity privileges and touches production data or secrets.
• Server-Side Template Injection: Server-side template injection occurs when untrusted data is interpreted by a template engine as executable template syntax. In identity and platform systems, it can become a privilege problem because the attack executes inside a service that may already hold access to cluster resources, tokens, or other sensitive controls.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and identity practitioners build stronger control models for systems that act on behalf of users or services.