vLLM RCE shows AI security failures start in API infrastructure

At a glance

What this is: This is an analysis of CVE-2025-62164 in vLLM, where a malicious API request can trigger remote code execution or denial of service through unsafe deserialization.

Why it matters: It matters because AI serving stacks are becoming part of the identity and access control surface, and a compromised inference API can become a foothold for lateral movement, shadow AI exposure, and broader runtime compromise.

By the numbers:

• A newly discovered critical flaw ( CVE-2025-62164 ) in vLLM allows attackers to achieve Remote Code Execution (RCE) or crash servers simply by sending a malicious API request.

👉 Read Salt's analysis of the vLLM remote code execution flaw and AI API risk

Context

AI API security fails when serving layers trust payloads before validating structure and provenance. In this case, the weakness sits in the inference infrastructure rather than the model itself, which makes the issue relevant to AI platform teams, application security, and identity governance where API access becomes the real control boundary.

The identity angle is indirect but real. Shadow AI instances, service endpoints, and internal API calls all create non-human access paths that need inventory, policy, and runtime monitoring. When those paths are not governed, a simple request can become code execution, service disruption, or an internal pivot point.

Key questions

Q: What breaks when unsafe deserialisation affects AI serving APIs?

A: Unsafe deserialisation breaks the assumption that API payloads are passive data. In AI serving stacks, a crafted request can become code execution, memory corruption, or a crash before any model-level safety control has a chance to act. The practical failure is at the boundary where the runtime trusts the payload too early.

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. If the host can call internal APIs or hold service credentials, attackers can use it as a pivot point. That is why identity scope and network segmentation matter together.

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. If a service account or token can invoke AI infrastructure, then that credential becomes the real control point. The mistake is treating AI risk as a model problem instead of an access governance problem.

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.

Technical breakdown

Unsafe deserialization in AI inference APIs

Deserialization is the process of converting structured data back into an object the server can use. In vulnerable AI serving stacks, prompt embeddings and similar payloads are often accepted as data blobs and unpacked by the API layer. If the server trusts that input before verifying structure, type, and bounds, a crafted payload can confuse memory handling and steer execution into attacker-controlled behaviour. The risk is not unique to AI, but AI APIs are especially exposed because they often carry complex binary or encoded formats that standard controls do not understand.

Practical implication: validate AI API payload structure before deserialisation and treat model-serving endpoints as high-risk application interfaces.

Why SAST and WAF controls miss AI API abuse

Static analysis checks code in isolation, so it often misses security failures that emerge from library interactions or upstream dependency changes. In this case, a PyTorch change altered default checks, and the issue surfaced only when vLLM consumed that behaviour in production. Traditional WAFs also struggle because the request looks like ordinary API traffic with encoded data, not obviously malicious commands. That creates a blind spot where the security stack sees a request, but not the semantics of the AI payload.

Practical implication: add runtime API inspection and dependency-aware testing instead of relying on code scans or generic perimeter filtering.

How lateral movement can begin from an inference server

Once an attacker gets execution on an inference node, the concern shifts from the model to the surrounding environment. Inference servers often hold credentials, can call internal services, and sit close to data pipelines or orchestration layers. That means a compromise can be used to reach databases, internal APIs, or management planes. The technical issue is not just initial exploitation but the trust placed in the server's ability to make privileged east-west calls once it is inside the network.

Practical implication: segment inference workloads, restrict east-west API access, and monitor for abnormal internal service calls from AI runtimes.

Threat narrative

Attacker objective: The attacker aims to gain code execution or service disruption on AI inference infrastructure, then use that position to extend access into adjacent internal systems.

1. Entry occurs when an attacker sends a malicious API request to the vLLM Completions API carrying a crafted payload disguised as legitimate AI data.
2. Escalation follows when unsafe deserialisation causes memory corruption, which can crash the server or enable remote code execution on the inference host.
3. Impact is achieved when the attacker uses that foothold to disrupt service or pivot toward internal systems reachable from the compromised inference server.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Unsafe deserialisation is a governance gap, not just a coding flaw. The vLLM case shows what happens when upstream library behaviour changes and downstream teams assume the payload contract remains safe. That creates a dependency risk that fits directly into NIST-CSF and OWASP-NHI thinking, because the exposed surface is a workload identity path, not just a function call. Practitioners should inventory which AI runtimes are trusted to accept complex binary inputs.

Shadow AI exposure: unmanaged inference endpoints become high-value entry points when teams spin up AI services outside security visibility. The article's description of hidden experimental instances is the same structural problem seen in other non-human identity sprawl: services exist before they are governed. That makes discovery and policy enforcement a prerequisite for any AI programme that handles internal data or can reach production networks. Practitioners should bind AI runtime discovery to access control and monitoring.

Runtime inspection has to understand AI payload semantics. Generic network controls struggle when malicious input looks like a normal encoded request body. The security model therefore needs behavioural detection at the API layer, plus egress controls on the inference environment itself. Without both, defenders see traffic volume but not intent. Practitioners should move toward AI-aware runtime controls rather than depending on perimeter tooling alone.

From our research:

• 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.
• For a governance model that maps identity lifecycle controls to non-human systems, see Top 10 NHI Issues.

What this signals

API-layer AI security will increasingly overlap with workload identity governance. As AI inference becomes a normal production dependency, the question changes from whether a model is safe to whether the service endpoint is trusted, inventoried, and constrained. Teams should expect AI runtime controls to converge with non-human identity policy, especially where internal APIs and service credentials are involved.

The operational signal is that generic perimeter tooling will keep missing high-risk AI payloads because the control failure happens after the request is already deemed legitimate. That pushes practitioners toward runtime visibility, dependency-aware testing, and east-west restrictions on AI workloads. The strongest programmes will manage inference services as privileged identities, not as ordinary application nodes.

For practitioners

• Inventory every exposed AI serving endpoint Build a live register of model-serving APIs, internal inference nodes, and experimental deployments. Include shadow AI instances, because untracked endpoints are the easiest path to unreviewed access and unmonitored runtime behaviour.
• Block unsafe deserialisation paths Review how prompt embeddings, tensors, and other binary payloads are parsed. Reject malformed or unexpected structures before deserialisation, and test dependency updates for behaviour changes that alter default validation.
• Constrain east-west access from inference servers Treat the inference host as a privileged workload with tightly scoped network permissions. Limit outbound calls to approved internal services and alert on any new database, management, or orchestration traffic.
• Add AI-aware API anomaly detection Use runtime controls that can distinguish normal model requests from payloads that are oversized, structurally inconsistent, or semantically invalid. Generic WAF signatures are not enough for AI traffic.
• Tie dependency changes to security regression tests Any update in a model-serving dependency should trigger a targeted test of parsing, validation, and request-handling behaviour. Upstream changes can reintroduce exposure even when application code is unchanged.

Key takeaways

• CVE-2025-62164 shows that AI security failures often start in the serving layer, not the model itself.
• Unsafe deserialisation, dependency drift, and blind WAF assumptions create a realistic path from one API request to RCE.
• Practitioners need discovery, runtime inspection, and constrained east-west access for AI inference workloads.

Key terms

• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• East-west traffic: East-west traffic is communication that moves between systems inside an environment rather than entering or leaving it. In microsegmentation programmes, it is the traffic most likely to expose hidden trust assumptions and is therefore the main target for workload-level policy.
• Runtime API Monitoring: Runtime API monitoring inspects API traffic and behaviour while the service is live, rather than only during scheduled scans. It looks for abuse patterns, abnormal request sequences, and misused credentials, making it especially useful where machine-to-machine access changes faster than review cycles.

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

👉 The full Salt article covers the attack path, runtime detection logic, and mitigation framing in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational risks created by AI and service workloads.