Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: LLM frameworks can turn convenience into exposure when deprecated options, external URL handling, path concatenation, SQL generation, template rendering, or code execution hooks are not tightly constrained, according to Flatt Security. The core lesson is that LLM application security still depends on input validation, sandboxing, least privilege, and strict separation of data from execution paths.
NHIMG editorial — based on content published by Flatt Security: Security Risks of LLM Frameworks with Case Studies
By the numbers:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when LLM frameworks expose code execution or dangerous request features?
A: They turn prompt or input handling into an execution path.
Q: Why do LLM frameworks create injection risk even when the model is not compromised?
A: Because the application can still be compromised through the framework boundary.
Q: How should security teams handle URLs, paths, and queries in AI applications?
A: They should validate each class of input separately and never let free-form text shape privileged operations.
Practitioner guidance
- Disable high-risk execution features by default Remove or tightly gate components that allow arbitrary code execution, dangerous request handling, or untrusted command invocation in production LLM workflows.
- Enforce allowlists for URLs and file paths Validate external URLs against an allowlist and block path strings that contain traversal patterns such as ../ before they reach loader or file APIs.
- Separate data from templates and SQL generation Keep template syntax out of user input, validate model-generated SQL before execution, and reject requests that can modify resources or escape expected structure.
What's in the full article
Flatt Security's full article covers the implementation detail this post intentionally leaves for the source:
- Code examples showing how each vulnerable LLM framework pattern is triggered in practice
- CVE-by-CVE breakdown of LangChain, LangChainjs, Haystack, and LlamaIndex failure modes
- Specific patch and mitigation examples, including validation logic and sandboxing patterns
- Developer guidance for deciding when dangerous framework features should be removed entirely
👉 Read Flatt Security's analysis of LLM framework security risks and CVEs →
LLM frameworks and injection risk: what security teams need to know?
Explore further
14/09/2026 10:11 am
Classic application security failures are reappearing inside LLM frameworks. The article’s strongest lesson is that AI orchestration does not replace secure coding discipline. SSRF, path traversal, SQL injection, and template injection all re-emerge when framework developers trust model output or user input too early. The practical conclusion is that AI application teams need the same boundary discipline they would apply to any internet-facing execution layer.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to our Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why AI toolchains should never inherit broad runtime access by default.
A question worth separating out:
Q: Should organisations sandbox every risky LLM workflow or redesign it first?
A: Redesign first when the dangerous function is not essential, because removing the feature is stronger than containing it. Use sandboxing when external execution, file access, or other high-risk operations are genuinely required. In either case, pair the design choice with minimal permissions and explicit limits on runtime behaviour.
👉 Read our full editorial: LLM framework security risks expose classic injection failures
