Notifications
Clear all
Topic starter
02/08/2026 12:13 pm
TL;DR: A critical flaw in vLLM, CVE-2025-62164, lets attackers trigger remote code execution or a crash by sending a malicious API request, showing how unsafe deserialization in AI serving infrastructure can bypass standard SAST and WAF controls, according to Salt. The real control gap is not model safety but runtime trust in API payloads.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
Q: What breaks when unsafe deserialisation affects AI serving APIs?
A: Unsafe deserialisation breaks the assumption that API payloads are passive data.
Q: Why do AI inference servers create lateral movement risk?
A: Inference servers often sit close to data, orchestration, and internal service planes, so compromise of the runtime can expose more than the model itself.
Q: What do security teams get wrong about AI access risk?
A: Many teams focus on the model while ignoring the identity path that reaches it.
Practitioner guidance
- Inventory every exposed AI serving endpoint Build a live register of model-serving APIs, internal inference nodes, and experimental deployments.
- Block unsafe deserialisation paths Review how prompt embeddings, tensors, and other binary payloads are parsed.
- Constrain east-west access from inference servers Treat the inference host as a privileged workload with tightly scoped network permissions.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- API protection platform behaviour for detecting malformed AI requests at runtime
- How the vLLM Completions API becomes observable in traffic analysis
- The specific attack-path examples Salt uses to explain east-west movement risk
- Why the vendor argues network-layer controls can stop the exploit before the server is reached
👉 Read Salt's analysis of the vLLM remote code execution flaw and AI API risk →
vLLM remote code execution: what AI API teams need to fix?
Explore further
02/08/2026 1:16 pm
AI API security is now an identity problem as much as an application problem. The server that serves model responses is also a trust boundary for non-human access, credentials, and internal service calls. When that boundary accepts untrusted payloads, the control failure is not just software correctness but governance of what is allowed to invoke AI infrastructure. Practitioners should treat inference APIs as privileged non-human identities in their own right.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should organisations govern shadow AI endpoints and model-serving APIs?
A: Organisations should treat every AI endpoint as a governed production service, even when it starts as a pilot. That means discovery, ownership, approved access paths, logging, and runtime monitoring from day one. Unregistered inference services become unmanaged entry points, which is exactly where attack paths begin.
👉 Read our full editorial: vLLM RCE shows AI security failures start in API infrastructure
