Critical torch.load Vulnerability: 3 RCE Flaws Every MLOps Team Must Patch

🔴 CVSS 9.8 (Critical) · torch.load vulnerability in PyTorch weights_only=True · CVE-2025-32434 · Fixed in 2.6.0
🟠 CVSS 7.8 (High) · Transformers Trainer checkpoint loading · CVE-2026-1839 · Fixed in 5.0.0rc3
🟠 CVSS 7.8 (High) · Transformers from_pretrained() config injection · CVE-2026-4372 · Fixed in 5.3.0 (March 4, 2026)

A critical torch.load vulnerability sat inside the exact flag PyTorch shipped to make checkpoint loading safe. Three CVEs across two libraries that sit underneath nearly every production AI pipeline share the same root failure: a documented “safe” model-loading mode that an attacker could walk straight through.

PyTorch’s weights_only=True, the flag introduced specifically to stop arbitrary code execution from untrusted checkpoints was bypassed by CVE-2025-32434 (CVSS 9.8), fixed in PyTorch 2.6.0. The fix didn’t fully close the gap: Hugging Face Transformers’ own Trainer class called torch.load() internally without weights_only=True to restore RNG state from a checkpoint, a separate bug now tracked as CVE-2026-1839, fixed in Transformers 5.0.0rc3. Then, in a refactor shipped the same general period, Transformers’ from_pretrained() picked up a third hole: CVE-2026-4372 (CVSS 7.8), where a poisoned config.json could trigger code execution with no flags, no trust_remote_code=True, and no user interaction patched in Transformers 5.3.0 on March 4, 2026.

If your pipeline calls from_pretrained() on models you didn’t train, runs Trainer against checkpoints from outside your team, or pins an older PyTorch for “stability,” you have exposure to check today.

Why This torch.load Vulnerability Matters More Than a Normal CVE

None of these three CVEs require an attacker to already have access to your systems. The entire attack surface is: someone on your team downloads and loads a model. Hugging Face Hub hosts well over a million public models, and Pluto Security’s own telemetry on CVE-2026-4372 found peak weekly vulnerable installs of the affected Transformers versions reaching into the millions in the weeks before the patch shipped, with roughly a third of all Transformers installs during the exposure window landing on a vulnerable release.

For teams running inference or fine-tuning in production, this is not a hypothetical supply-chain risk. It’s three confirmed, independently-disclosed exploit chains that each bypassed the specific control your security review probably signed off on — weights_only=True, or trust_remote_code=False.

Vulnerability Summary

How Each One Actually Works

CVE-2025-32434: torch.load() defaults to Python’s pickle module, which can execute arbitrary code on deserialization. PyTorch’s fix was weights_only=True, restricting the unpickler to an allowlist of tensor-building classes. A researcher (Ji’an Zhou) found a path around that allowlist anyway. The official PyTorch advisory confirms the bypass affects all versions through 2.5.1, fixed in 2.6.0.

CVE-2026-1839: Even after PyTorch shipped that fix, Transformers’ own Trainer class didn’t fully adopt it. The _load_rng_state() method calls torch.load() on a checkpoint file (rng_state.pth) without passing weights_only=True, on any environment running torch >= 2.2 paired with a pre-2.6 PyTorch. A malicious checkpoint dropped into a training run’s resume path executes code the moment training resumes. Fixed in Transformers 5.0.0rc3.

CVE-2026-4372: Discovered by researcher Yotam Perkal at Pluto Security, this one lives in Transformers’ kernel-dispatch path, introduced in a refactor shipped in v4.56.0 (released August 29, 2025). A crafted config.json can set an internal attribute — _attn_implementation_internal — that gets picked up during from_pretrained() and used to load an attacker-controlled kernel package, with no trust_remote_code=True flag required. The bug shipped silently and stayed exploitable for roughly six months before the fix landed in Transformers 5.3.0 on March 4, 2026.

Are You Affected by This torch.load Vulnerability? Check These Three Things

1. Your PyTorch version

# Check installed PyTorch version
python3 -c "import torch; print(torch.__version__)"

# Across Docker images in use
docker images --format '{{.Repository}}:{{.Tag}}' | while read img; do
  echo "$img:"
  docker run --rm "$img" python3 -c "import torch; print(torch.__version__)" 2>/dev/null
done

# Inside Kubernetes pods
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[].spec.containers[].image' | sort -u

Anything reporting 2.5.1 or earlier is exposed to CVE-2025-32434, even if your code already calls weights_only=True.

2. Your Transformers version

# Check installed Transformers version
python3 -c "import transformers; print(transformers.__version__)"

# Search requirements files across services
grep -rE "transformers(==|>=|<=)?" --include="requirements*.txt" .
grep -rE "transformers" --include="pyproject.toml" .

Anything below 5.0.0rc3 is exposed to CVE-2026-1839 if you use Trainer to resume from checkpoints. Anything between 4.56.0 and 5.2.x is exposed to CVE-2026-4372.

3. Whether you’re loading models or checkpoints you didn’t produce

# Find from_pretrained calls pulling external repo IDs
grep -rn "from_pretrained(" --include="*.py" . | grep -v "^\./tests"

# Find Trainer usage that resumes from a checkpoint argument
grep -rn "resume_from_checkpoint" --include="*.py" .

Every hit is a place an untrusted artifact — model weights, a config file, or a checkpoint — could reach your runtime.

The Fix for This torch.load Vulnerability and Its Transformers Counterparts

Upgrade all three components — they are independent fixes for independent bugs, and patching one does not patch the others:

# PyTorch: must be 2.6.0 or later
pip install --upgrade "torch>=2.6.0"

# Transformers: must be 5.3.0 or later to cover all three CVEs
pip install --upgrade "transformers>=5.3.0"

If you can’t upgrade Transformers immediately, reduce exposure with these mitigations:

Option 1 — Sandbox model loading
Run from_pretrained() and training-resume calls inside containers with no credential access and restricted egress. If a malicious config or checkpoint does execute code, it has nowhere to send data and nothing to steal.

Option 2 — Pin to known-safe repositories
Restrict automated pipelines to organizations you control or explicitly trust. Don’t let CI/CD pull arbitrary repo IDs from user input or unreviewed pull requests.

Option 3 — Audit cached configs and checkpoints

# Search local HF cache for the specific malicious field used in CVE-2026-4372
grep -rn "_attn_implementation_internal" ~/.cache/huggingface/ 2>/dev/null

A hit doesn’t confirm exploitation on its own, but it’s worth investigating before you trust that cached model.

Option 4 — Don’t treat trust_remote_code=False as your only boundary
This was the exact assumption CVE-2026-4372 broke. Treat it as one layer of defense, not the whole wall.

The Pattern to Remember

Three CVEs, two libraries, roughly a year apart, the same structural mistake each time: a “safe” loading mode that didn’t audit every adjacent code path behind it. If your team’s security review for ML pipelines currently stops at “we use weights_only=True” or “we don’t set trust_remote_code,” that review is checking controls that have already failed at least once each. Expect a fourth.

Run the three checks above against your production training and inference services today — that’s the only way to know if you’re still exposed to any of these three CVEs right now.

FAQ

SOURCES

1. PyTorch Security Advisory — GHSA-53q9-r3pm-6pq6 / CVE-2025-32434, published April 17, 2025
2. GitHub Advisory Database — CVE-2025-32434 record (affected: pytorch ≤2.5.1; fixed: 2.6.0)
3. GitLab Advisory Database — CVE-2025-32434
4. GitHub Advisory Database — CVE-2026-1839 / GHSA-69w3-r845-3855, “HuggingFace Transformers allows for arbitrary code execution in the Trainer class”
5. GitLab Advisory Database — CVE-2026-1839, April 7, 2026
6. Pluto Security — Unauthenticated Remote Code Execution in HuggingFace Transformers via Config Injection (original CVE-2026-4372 disclosure by researcher Yotam Perkal)
7. eSecurity Planet — Hugging Face Vulnerability Allows Remote Code Execution
8. CSO Online / Let’s Data Science — Hugging Face Transformers contains critical remote code execution vulnerability (notes CVE-2026-1839 fix in 5.0.0rc3 separately from CVE-2026-4372)
9. CyberPress — Critical Hugging Face Transformers Flaw Enables Remote Code Execution
10. CybersecurityNews — Critical Hugging Face Transformers Vulnerability Enables Remote Code Execution Attacks
11. NVD — CVE-2025-32434
12. NVD — CVE-2026-4372 (verify current enrichment status directly — NVD’s enrichment priority changed April 2026)

Note on CVSS scoring: CVE-2025-32434 is most commonly cited as CVSS 3.1 score 9.8 (Critical) across NVD-derived trackers; the GitHub Security Advisory itself separately lists a CVSS 4.0 score of 9.3. Both reflect Critical severity; this article uses 9.8 as the predominant figure in third-party tracking.