TensorRT-LLM deserialization bugs expose model-serving control planes

At a glance

What this is: Two TensorRT-LLM deserialization CVEs show that model-serving control planes can become code-execution paths when untrusted bytes reach pickle-based object reconstruction.

Why it matters: Identity and access teams should care because distributed AI platforms now carry privileged service accounts, worker trust boundaries, and tenant-to-control-plane exposure that can bypass normal IAM assumptions.

By the numbers:

• NVIDIA’s published base scores place CVE-2025-33255 at 7.5 and CVE-2026-24142 at 6.3, while NVD scores both as 9.8 critical.
• CWE-502 covers deserialization of untrusted data, the exact bug class behind both TensorRT-LLM issues.

👉 Read Corgea's analysis of TensorRT-LLM deserialization CVEs and model-serving risk

Context

Unsafe deserialization remains one of the most reliable ways for attacker-controlled data to cross from input into execution. In AI serving stacks, that boundary is often hidden inside worker orchestration, serialized handles, and distributed control traffic rather than in a visible web endpoint. TensorRT-LLM is a reminder that model-serving platforms can expose privileged execution paths even when the application layer looks conventional.

The identity angle is real because these deployments depend on service accounts, worker identities, and shared cluster trust assumptions. When a serialized object is accepted from a tenant, job runner, or orchestration path, the issue is not only code execution but also whether the platform has treated that actor as sufficiently trusted. For model-serving teams, that is a governance problem as much as a software bug.

Key questions

Q: What breaks when model-serving frameworks deserialize untrusted control-plane data?

A: When model-serving frameworks deserialize untrusted control-plane data, object reconstruction can become code execution instead of data loading. That can let an attacker pivot from a job, worker, or serialized handle into the serving process itself. The failure is not just malformed input, but trust placed in bytes that should never have crossed the execution boundary.

Q: Why do distributed AI clusters make deserialization bugs more dangerous?

A: Distributed AI clusters make deserialization bugs more dangerous because orchestration, worker coordination, and cross-process state all rely on privileged paths that are often assumed to be internal. In shared or multi-tenant environments, those paths may still be reachable by untrusted jobs or compromised workers, turning a local flaw into a cluster-wide compromise risk.

Q: How do security teams know if a serving platform is using unsafe object reconstruction?

A: Security teams know a serving platform is using unsafe object reconstruction when serialized handles, checkpoints, or worker state are loaded through generic object loaders rather than strict schemas or allowlists. Another warning sign is when deserialization happens on paths reachable from tenant workloads, notebook jobs, or orchestration APIs. That is where review should start.

Q: Who is accountable when a model-serving control plane is exposed through deserialization?

A: Accountability usually sits with both the platform owner and the engineering team operating the serving stack. Platform owners must define trust zones, identity boundaries, and patch expectations, while engineers must remove unsafe loaders and validate control-plane inputs. Frameworks such as NIST CSF and OWASP NHI help teams assign those responsibilities clearly.

Technical breakdown

Why pickle-based deserialization is so dangerous

Python pickle is not a data interchange format. It is a reconstruction mechanism that can import modules and call functions while rebuilding objects. That means the deserializer, not just the parser, becomes part of the attack surface. If untrusted bytes reach pickle.loads(), an attacker can craft object reducers that trigger process execution or import paths during reconstruction. The core issue is trust boundary collapse: the code assumes the payload is already trusted, while the network or orchestration layer may be attacker-influenced.

Practical implication: treat every pickle load as a potential execution boundary and remove it from any path that can be influenced by tenants or workers.

How serialized handles become a control-plane attack path

TensorRT-LLM’s vulnerable RLHF path accepted serialized IPC handles for cross-process weight movement, then decoded base64 into pickle.loads(). Those handles are not business data. They are control-plane objects used to move model state across ranks and workers. If a compromised worker, poisoned job definition, or exposed management path can influence that object, the deserialization step becomes a privilege boundary. NVIDIA’s fix moved toward restricted unpickling and type validation, which narrows the object graph that can be reconstructed.

Practical implication: restrict serialized handle formats to explicit allowlists and validate the returned object type before the worker accepts it.

Why MPI server traffic needs the same trust review as APIs

MPI often sits behind orchestration, scale-out, or internal worker coordination, so teams assume it is trusted plumbing. In practice, the question is whether an untrusted principal can reach the bytes that feed the MPI server’s deserialization path. Shared clusters, notebook environments, and multi-tenant inference services make that question harder to answer. The risk is not Internet exposure alone. It is the combination of privileged worker identity, cross-process state transfer, and an object loader that accepts attacker-shaped payloads.

Practical implication: segment MPI and worker control ports by trust zone and audit any path that lets tenant-controlled data reach worker state reconstruction.

Threat narrative

Attacker objective: The attacker wants to convert a distributed AI control-plane boundary into code execution and then pivot into serving infrastructure or model assets.

1. Entry occurs when attacker-influenced data reaches the TensorRT-LLM deserialization path through serialized handles, job state, or MPI control traffic.
2. Escalation follows when pickle reconstructs objects or imports callable targets, turning a data boundary into code execution inside the serving process.
3. Impact is compromise of model-serving workers, adjacent credentials, model weights, or other cluster resources through the privileged control plane.

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

Model-serving control planes are becoming a new class of privileged identity surface. TensorRT-LLM shows that distributed inference frameworks are no longer just software delivery layers. They now carry worker identities, serialized state, and trust boundaries that can be abused if control traffic is not constrained. For IAM and PAM teams, this means AI platforms must be governed as privileged systems, not treated as ordinary application runtime. The practical conclusion is that model-serving infrastructure needs explicit identity and trust segmentation.

Unsafe deserialization is a governance failure, not only a code flaw. The real weakness here is the assumption that cross-process objects are trusted because they are internal. That assumption fails in multi-tenant clusters, notebook environments, and shared GPU estates where internal traffic is still attacker-reachable. The named concept is control-plane trust collapse: when orchestration state is allowed to behave like benign data. Teams should review where privileged reconstruction happens and who can influence it.

AI infrastructure security now depends on least privilege across worker accounts and orchestration paths. If a model-serving worker can deserialize attacker-shaped objects, the blast radius includes more than the application process. It can extend to service accounts, GPU nodes, and adjacent services that the worker can reach. That is a classic privilege amplification problem in a new technical wrapper. Practitioners should map these flows to NIST CSF access controls and OWASP NHI concepts before an incident forces the review.

Patch management alone is not enough when the vulnerable pattern is architectural. Upgrading TensorRT-LLM to 1.2 or later matters, but the broader issue is that distributed AI stacks increasingly embed their own mini operating systems: schedulers, IPC, plugins, tensor handles, and orchestration state. Security programmes need to decide whether these platforms are trusted execution zones or tenant-exposed systems. That decision should drive network segmentation, account scoping, and deserialization review.

Agentic and non-human identity programmes will increasingly meet AI serving risk at the control plane. As enterprises add AI agents, the same infrastructure patterns that support model serving will also support delegated task execution and tool access. That creates overlap between AI governance and NHI governance, especially where service accounts, workload identities, and agent permissions meet serialized state transfer. The practitioner conclusion is clear: identity governance must extend into AI runtime plumbing before these boundaries become routine attack paths.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• A separate finding from the same research shows that 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• From our research: Compare that governance gap with The 52 NHI breaches Report to see how weak lifecycle controls turn operational trust into repeatable exposure.

What this signals

Control-plane trust collapse is the right lens for this class of AI infrastructure risk. When distributed model-serving systems accept serialized state from workers, job runners, or tenant-adjacent paths, the governance question becomes who is allowed to influence reconstruction, not just who can invoke an API. Teams should treat worker identity, control traffic, and serialization rules as one programme.

The practical signal for practitioners is that AI platform security is converging with NHI governance. Service accounts, workload identities, and orchestration permissions now shape the blast radius of a deserialization flaw as much as the code itself. Where model-serving platforms are shared or multi-tenant, controls such as segmentation, runtime validation, and privileged account scoping need to be reviewed together.

The next wave of AI incidents will likely expose hidden assumptions in distributed infrastructure rather than only in model behaviour. That means governance teams should pair patching with architectural reviews of worker trust zones, privileged service accounts, and cross-process state transfer. The organisations that do this early will reduce the chance that an internal control plane becomes an external incident.

For practitioners

• Audit all pickle-based reconstruction paths Search serving code, worker utilities, and packaged dependencies for pickle.loads, pickle.load, and custom unpicklers. Prioritise any path that accepts job state, serialized handles, or orchestration metadata from tenants or other workers.
• Rebuild images with TensorRT-LLM 1.2 or later Update the package, then rebuild every container image and internal wheel that bundles tensorrt-llm. Version changes in the application repo are not enough if a base image still contains the vulnerable package.
• Restrict MPI and worker control ports Limit control-plane traffic to the smallest viable trust zone using security groups, Kubernetes NetworkPolicy, or equivalent segmentation. Do not allow tenant workloads or notebook jobs to reach worker-state reconstruction interfaces.
• Validate deserialized object types and allowlists Use restricted unpicklers with explicit approved imports, narrow module patterns, and post-deserialization type checks. Reject payloads that do not match the expected list of tensor-handle objects before any downstream use.
• Review worker and service-account blast radius Map which credentials, model artifacts, and adjacent services each serving worker can reach. If a deserialization flaw is reachable, assume the worker account is part of the incident scope and scope its privileges accordingly.

Key takeaways

• TensorRT-LLM shows that AI serving stacks can expose code execution through control-plane deserialization, not just through public application endpoints.
• The risk scales with trust boundaries, because tenant jobs, worker identities, and orchestration paths can all feed privileged reconstruction logic.
• Patching matters, but segmentation, allowlists, and worker-account scoping are what limit the blast radius when distributed AI infrastructure is targeted.

Key terms

• Unsafe Deserialization: Unsafe deserialization happens when software reconstructs objects from untrusted data in a way that can trigger code execution or state corruption. In practice, the risk is not the file or message itself, but the fact that the parser is allowed to invoke behaviour while rebuilding the object.
• Trust Control Plane: A trust control plane is the operational layer that collects telemetry, applies policy, and exposes evidence about identity and cryptographic state. In this article, it is the mechanism that turns control activity into measurable proof across certificates, machine identities, and exceptions.
• Serialized Handle: A serialized handle is a compact representation of runtime state used to pass objects, references, or resources between processes or workers. In distributed AI systems, handles may carry model state or tensor references, so they must be treated as privileged control data, not generic application content.
• Runner Blast Radius: The amount of access and downstream impact a compromised build runner can create. It includes credentials in memory, secrets in environment variables, and permissions inherited from the workflow, which means a small execution foothold can become a multi-system identity incident.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact TensorRT-LLM call sites affected by the deserialization flaw and the fix pattern used in the patched release
• Command-line checks for identifying vulnerable tensorrt-llm versions inside Python environments and container images
• Code review cues for spotting unsafe pickle loading in distributed inference, RLHF, and worker-state paths
• Hardening guidance for MPI control traffic, container rebuilds, and deserialization allowlists

👉 The full Corgea analysis covers vulnerable call sites, version checks, and hardening steps for distributed AI stacks.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps identity and security practitioners translate emerging AI runtime risk into practical controls and accountability.