CVE-2026-1839

What it actually does

This is an unsafe deserialization vulnerability in the HuggingFace Transformers `Trainer` checkpoint-loading path. When resuming training, `_load_rng_state()` loads a PyTorch checkpoint file such as `rng_state.pth` using `torch.load()` without `weights_only=True`. In affected combinations of Transformers with PyTorch versions earlier than 2.6, PyTorch pickle deserialization can invoke attacker-controlled Python objects during load, allowing arbitrary code execution with the privileges of the process running training. The issue is most relevant where model checkpoints, training artifacts, or experiment outputs are imported from untrusted or semi-trusted sources.

Why it matters to the business

If exploited, this flaw can let a malicious model checkpoint run code inside machine learning training or fine-tuning infrastructure. Consequences can include theft of credentials and API tokens, tampering with models or datasets, lateral movement from ML workstations or GPU servers, cryptomining, data exfiltration, or disruption of training workloads. Although it requires a user or automation workflow to load a malicious checkpoint and is not listed in CISA KEV, the impact is high because ML environments often have access to valuable data, cloud credentials, model repositories, and expensive compute resources.

How an attack unfolds

An attacker creates or modifies a PyTorch serialized checkpoint artifact, commonly named `rng_state.pth`, embedding a malicious pickle payload that executes commands when deserialized. The attacker then gets the artifact into a workflow where HuggingFace Transformers `Trainer` resumes from or loads the checkpoint, such as by publishing it in a shared model repository, attaching it to a training run, committing it to a project, or convincing a user to resume training from the supplied checkpoint. During checkpoint restoration, the vulnerable `_load_rng_state()` method calls `torch.load()` without restricting deserialization to weights-only loading. On PyTorch versions before 2.6, the intended safe globals protection does not prevent execution in this path, so the payload runs as the training process user. From there, the attacker can execute shell commands, download additional tooling, steal secrets from environment variables or configuration files, alter training outputs, or use the host as a foothold.

How to fix it

Upgrade HuggingFace Transformers to the fixed release `v5.0.0rc3` or later when available for the deployment. Where immediate upgrade is not possible, avoid loading checkpoints from untrusted sources, especially files named `rng_state.pth` or other `.pth`, `.pt`, `.bin`, or pickle-backed artifacts. Use PyTorch 2.6 or later where feasible, because safer default behavior around `weights_only` reduces exposure to pickle deserialization risks. Treat model checkpoints as executable content: only load artifacts from trusted publishers, verified repositories, signed release pipelines, or internally generated training jobs. Isolate training and fine-tuning workloads with least-privilege service accounts, restricted network egress, no long-lived secrets in environment variables, and container or sandbox boundaries. For high-risk workflows, scan or quarantine external model artifacts before use and disable automatic resume-from-checkpoint behavior for untrusted sources.

How to confirm the fix worked

Confirm the installed HuggingFace Transformers version is `v5.0.0rc3` or later, or otherwise confirm the local code path no longer calls `torch.load()` for RNG state without safe weights-only behavior. Check the PyTorch version and prioritize PyTorch 2.6 or later where compatible. Review training scripts, notebooks, CI jobs, and orchestration workflows for `resume_from_checkpoint`, automatic checkpoint restoration, or imports from public/shared model repositories. Attempt a controlled validation in a non-production sandbox by loading a benign test checkpoint and confirming that unsafe pickle execution is blocked or that the patched code path is used. Inventory locations containing `rng_state.pth` and other PyTorch checkpoint files, and verify their provenance, signatures, checksums, and repository history.

Typical attack path

1. Prepare a malicious PyTorch checkpoint file containing a pickle-based code execution payload, often using a plausible filename such as `rng_state.pth`.
2. Place the malicious checkpoint where an ML engineer, notebook, CI job, training pipeline, or automated model workflow may consume it.
3. Cause or wait for HuggingFace Transformers `Trainer` to resume training or restore RNG state from that checkpoint.
4. Trigger `_load_rng_state()` to call `torch.load()` on the attacker-controlled file.
5. Execute arbitrary Python or operating system commands under the privileges of the training process.
6. Use the obtained execution to access secrets, modify artifacts, exfiltrate data, install persistence, or pivot within the ML environment.

How to detect it

Look for evidence that a training, notebook, or CI process loaded an untrusted checkpoint and then spawned unusual processes or made unexpected network connections. Relevant sources include ML training logs, notebook server logs, CI/CD job logs, container runtime logs, EDR process telemetry, shell history, cloud audit logs, artifact repository access logs, model registry download logs, and network proxy/DNS logs. Search for checkpoint restoration events involving `rng_state.pth`, `resume_from_checkpoint`, or `torch.load`, especially when followed by child processes such as shells, curl/wget, Python one-liners, SSH, netcat, or package installation commands. Investigate newly created or modified files in model cache directories, training output directories, temporary directories, startup scripts, SSH authorized keys, cron locations, and cloud credential paths. Because payload content is attacker-controlled, there is no universal IOC; behavioral correlation around checkpoint loading followed by command execution, outbound connections, credential access, or artifact tampering is the most reliable approach.

• rng_state.pth
• resume_from_checkpoint
• _load_rng_state
• torch.load(
• weights_only=True
• transformers/trainer.py
• checkpoint-*
• /root/.cache/huggingface/
• ~/.cache/huggingface/
• /tmp/rng_state.pth
• curl http
• curl https
• wget http
• wget https
• python -c
• python3 -c
• bash -c
• sh -c
• nc -e
• ncat -e
• /bin/bash -i
• authorized_keys
• /etc/cron.d/
• /var/spool/cron/

What your security team should do

• Prioritize upgrades of HuggingFace Transformers to `v5.0.0rc3` or later in ML training, fine-tuning, notebook, CI, and GPU compute environments.
• Upgrade PyTorch to 2.6 or later where application compatibility permits.
• Block or require review for externally sourced `.pth`, `.pt`, `.pkl`, `.pickle`, `.bin`, and checkpoint directories before they are loaded by training workflows.
• Search artifact repositories, model caches, notebooks, and training workspaces for `rng_state.pth` files from untrusted or unknown origins.
• Restrict ML job permissions: remove unnecessary cloud credentials, repository tokens, SSH keys, and production data access from training runtimes.
• Add network egress controls and monitoring for training containers and GPU hosts to detect payload download, reverse shells, or data exfiltration after checkpoint load.
• Review recent training jobs that resumed from external checkpoints for anomalous child processes, unexpected outbound connections, secret access, or modified model artifacts.
• Educate ML engineers that model checkpoints can execute code and should be handled like software dependencies, not passive data files.