Back

LLM Security: Concrete Risks and Defenses

Publication date: 2025-09-29
TIPS

TL;DR


Real issues have hit live LLM stacks: unauthenticated code execution and DoS in inference servers (e.g., NVIDIA Triton, vLLM), risky loader paths and converters in model toolchains (e.g., Transformers), and injection paths in app frameworks (e.g., LangChain). Below: where things fail, why it matters, and LLM-specific fixes that target those failure modes—plus how BaseFortify turns new CVEs into actionable threats the moment they match your recorded components.

 

The modern LLM stack

 

  • Model & weights (hosted or self-hosted).
  • Inference runtime/server (e.g., NVIDIA Triton, vLLM, TF-Serving, ONNX Runtime).
  • Orchestration & gateway (Kubernetes/Docker, Ray, NGINX/Kong).
  • Application layer (chat/RAG apps, agents, tool calling).
  • Retrieval layer (vector DBs, search, file/HTML parsers).
  • SDKs & client libs (openai, anthropic, transformers, langchain, etc.).
  • Observability (prompt/response logs, metrics, cost/rate guards).

 

What actually breaks

 

1) Inference servers: unauth RCE & DoS

 

NVIDIA Triton Inference Server: recent releases have patched chains that allowed remote code execution via exposed HTTP/Python backends. If internet-exposed or weakly gated, attackers can run code, exfiltrate models, or tamper with outputs.

 

vLLM: malformed or adversarial requests have triggered crashes/DoS in specific guided-parameter paths in past versions; fixes landed in subsequent releases.

 

  • Fixes that matter here: keep inference ports private behind an authenticated gateway (mTLS/API keys + IP allowlist); upgrade promptly to patched releases; enforce request size/time limits at the gateway; drop unknown guided-param keys before they reach the server.

 

2) Model toolchains & SDKs: code-execution & trust boundaries

 

Hugging Face Transformers: unsafe loaders and conversion utilities have historically opened RCE/DoS avenues—especially when running with trust_remote_code or processing third-party repos.

 

LangChain (and experimental chains): prompt-driven paths into SQL/graph/query layers have enabled injection when outputs are executed directly; experimental utilities have included code-execution risks when misconfigured.

 

  • Fixes that matter here: disable unsafe loaders (no trust_remote_code in prod); pin model repos by commit; run converters in throwaway/offline containers; route any model-produced SQL/commands through allow-listed, parameterized, read-only adapters; remove unused experimental chains.

 

3) Service-side incidents around hosted models

 

DeepSeek: service-side flaws (e.g., web XSS) and misconfigurations have been reported; even if you don’t self-host, your prompts and outputs may traverse these systems.

 

Anthropic developer tools: issues in community/auxiliary tooling (e.g., MCP inspection utilities) show that “developer-only” surfaces can still become enterprise entry points.

 

  • Fixes that matter here: treat SaaS LLMs as third-party services—data minimization, regional routing, per-provider API keys with tight scopes; keep a service record of advisories/incidents per provider; decide in advance whether your app fails-open or fails-closed if a provider blocks or degrades requests.

 

4) Retrieval & post-processing: injection and poisoning

 

Hostile content in retrieved PDFs/HTML can steer tools or inject scripts when answers are rendered. Tokenizers/parsers occasionally carry their own vulnerabilities.

 

  • Fixes that matter here: tag and segregate retrieved content inside prompts (the model should “know” it’s untrusted); sanitize HTML/Markdown on render; never auto-follow URLs proposed by the model; prefer curated corpora or a proxy that strips scripts and trackers.

 

5) Observability & secrets: leakage vectors

 

Prompts, documents, tool results, and API keys can leak through logs and traces; cost/rate spikes can mask abuse or agent loops.

 

  • Fixes that matter here: redact logs at source; store hashes/metadata instead of raw PII/secrets; enforce budget/rate guards per user/tool; alert on unusual tool mixes or egress destinations.

 

How BaseFortify helps (what actually triggers action)

 

In BaseFortify, risk isn’t raised by tagging a node—action starts when a published CVE matches a recorded component. The practical move is to enter your LLM stack components using only what BaseFortify tracks: vendor, product, and version. That includes inference servers (e.g., nvidia, triton_inference_server), application frameworks (e.g., huggingface, transformers; langchain, langchain), orchestration and gateways (e.g., anyscale, ray; nginx, nginx), vector/database layers, and the GPU stack (driver/CUDA/cuDNN). When a new CVE lands for any of those components and matches your version, BaseFortify automatically creates a threat on the affected node, so you can prioritize remediation and track closure.

 

Try out tracking LLM-related CVEs today, for free! You can register at https://basefortify.eu/register And immediately add up to 3 devices and 100 components to your watch list. Within minutes you will see if you are vulnerable. By registering you will be able to read our full CVE report, including out Q & A and consult with our A.I. on the best steps to mitigate your risk.

 

References