CVE-2024-5480

What it actually does

The vulnerability permits remote code execution by allowing unvalidated PythonUDF objects containing arbitrary callables such as eval to be deserialized and invoked on the master node during RPC operations in the torch.distributed.rpc framework.

Why it matters to the business

Attackers can fully compromise master nodes used for distributed machine learning training, resulting in theft of proprietary models, training data, and intellectual property with no authentication required.

How an attack unfolds

An attacker deploys a malicious worker process that participates in a distributed training job, serializes a PythonUDF referencing built-in functions like eval, and transmits it over the RPC channel; the receiving master deserializes and executes the function without verification, granting arbitrary command execution.

How to fix it

Upgrade PyTorch to version 2.2.2 or later where RPC function validation has been added; disable the distributed.rpc module when not required and enforce network segmentation between worker and master nodes.

How to confirm the fix worked

Confirm all PyTorch installations report version 2.2.2 or newer; review RPC-related code paths for any remaining direct use of PythonUDF or eval; test that unauthorized callables are rejected during simulated RPC exchanges.

Typical attack path

1. Attacker joins a distributed training cluster as an untrusted worker node
2. Worker constructs and serializes a PythonUDF containing dangerous callables
3. UDF is sent to the master node via multi-CPU RPC communication
4. Master deserializes and executes the UDF without validation
5. Attacker obtains code execution on the master and exfiltrates AI assets

How to detect it

Inspect RPC logs and training job logs for unexpected PythonUDF deserialization events or invocations of eval, exec, or similar builtins; correlate with network connections from untrusted worker IPs to master nodes.

What your security team should do

• Immediately inventory all PyTorch deployments and prioritize upgrade of any version prior to 2.2.2
• Restrict network access so only trusted hosts can initiate RPC connections to master nodes
• Monitor for anomalous PythonUDF traffic or unexpected eval usage in training logs
• Consider disabling torch.distributed.rpc entirely if distributed training is not essential