CVE-2026-1839, published April 7, 2026 on NVD and fixed in Transformers v5.0.0rc3, is straightforward on the surface: a missing weights_only=True in (see also load_prompt path traversal) one torch.load() call. The problem is that the mitigation already in place — a safe_globals context manager wrapping that call — silently does nothing on PyTorch 2.2 through 2.5. Teams that upgraded Transformers but kept PyTorch pinned for compatibility reasons are still exposed.
What the Vulnerability Actually Does — _load_rng_state() and the Pickle Path
In src/transformers/trainer.py at line 3059, the _load_rng_state() method calls torch.load() on the rng_state.pth file written at each checkpoint during training. That file stores the random number generator state and is read back when resuming an interrupted run. The call passes no weights_only argument, defaulting to False — which means Python’s pickle module handles deserialization with full code execution capabilities.
pickle is not a data format; it is a serialization protocol that can instantiate arbitrary Python objects and call arbitrary constructors during deserialization. Any file that reaches torch.load() with weights_only=False is effectively a program that runs on load. An attacker who can substitute rng_state.pth with a crafted payload gets arbitrary code execution in the context of the training process.
NVD classifies this as CWE-502 (Deserialization of Untrusted Data) with a CVSS 6.5 Medium rating under vector CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:H. The score is depressed by AC
The surrounding code in trainer.py does not lack awareness of the problem. According to the fix commit, other torch.load() calls in the same file already used weights_only=True. This was an isolated oversight at line 3059, not a systemic disregard for pickle safety.
Why safe_globals Doesn’t Help You on PyTorch < 2.6 — the Silent No-Op
The code at line 3059 already wrapped the torch.load() call in a safe_globals context manager — apparently as a mitigation. The problem is that safe_globals is a PyTorch 2.6 construct. On PyTorch 2.2 through 2.5, the restricted unpickler that safe_globals gates does not exist. The context manager accepts the call, does nothing, and returns without error.
This is the core gap: the code looks protected. A code reviewer reading trainer.py would see the safe_globals wrapper and reasonably conclude the load was guarded. The guard is inert below 2.6.
PyTorch 2.6 was the release that flipped torch.load()’s default from weights_only=False to weights_only=True, and safe_globals — which lets callers whitelist specific Python globals needed for legitimate deserialization — only has meaning in that context. On older runtimes, weights_only defaults to False and there is nothing to gate.
The fix by contributor ColeMurray adds two changes at that line: a call to check_torch_load_is_safe() before the load (which validates the environment can actually enforce safety), and the explicit weights_only=True parameter on the torch.load() invocation itself. Both changes are in commit 03c8082.
The Version-Pinning Trap: Who Is Still Exposed After Patching Transformers
The practical exposure maps to environments running Transformers with torch>=2.2 paired with PyTorch < 2.6. This combination is not unusual. PyTorch 2.6 initially broke checkpoint resumption for some Transformers users: GitHub issue #34631 documents that rng_state.pth files contained numpy globals that fell outside the new weights_only allowlist, causing training resumption to fail after upgrading to 2.6. Teams hit by that regression had rational reasons to pin back to 2.5.
The result is a version-combination vulnerability. A team could read the CVE-2026-1839 advisory, upgrade Transformers to v5.0.0rc3, and remain fully exploitable because their pinned PyTorch 2.5 install makes the patch’s safety check either ineffective or a runtime error rather than a genuine guard. Standard patch advisories do not catch this because they frame the fix as “upgrade the package named in the CVE.” The correct remediation requires auditing the PyTorch version in every training environment independently of the Transformers version.
The CUDA and NCCL dependency chain is the most common reason for PyTorch version pinning in production training clusters. Teams running CUDA 11.x drivers or specific NCCL builds for multi-node communication may find that upgrading to PyTorch 2.6 requires re-qualifying their entire training stack — a non-trivial lift that creates real incentive to remain on an older torch release, which is exactly the range where CVE-2026-1839 is exploitable.
The Trust Boundary Shift — Mid-Training Checkpoints Are Now an Attack Surface
The recurring pattern in ML framework pickle CVEs — lmdeploy CVE-2025-67729, multiple PyTorch Lightning CVEs — has been framed around model distribution: a user downloads a malicious .pt file from a public hub, the unsafe load fires on ingest, and the threat is contained to the download step. The Transformers Trainer case is structurally different.
rng_state.pth is not a third-party artifact. It is written by the training process itself, to a directory controlled by the team running the job. The implicit threat model in most MLOps setups treats internal training output directories as trusted — access-controlled, written by known processes, not requiring content inspection. CVE-2026-1839 breaks that assumption. Any path that results in a malicious file reaching rng_state.pth before the next resume — a compromised training node, a poisoned upstream data pipeline, a misconfigured storage write permission — becomes a code execution vector.
This pushes the trust boundary inward. Vetting what enters a model registry is no longer sufficient. The question is: who can write to the training checkpoint directory, and how is that write access audited between job completion and job resumption?
Exploitability in Practice: Shared Storage, Distributed Training, and AC Caveats
The CVSS AV:L (local) attack vector invites dismissal as a “local-only” issue. In distributed training, “local” means “accessible from any node with access to the shared storage layer.” Training checkpoints on large jobs commonly land on NFS mounts, S3 buckets, or GPFS/Lustre filesystems. A compromised compute node, a misconfigured IAM policy on the checkpoint bucket, or a rogue job on a multi-tenant cluster can all plant a malicious rng_state.pth before the next resume.
AC:H reflects that exploitation requires correctly timing the file substitution before the Trainer resumes and crafting a pickle payload that executes in the target Python environment without obvious error. UI:R means the trigger is the legitimate training resume operation — not an action the attacker controls directly. These factors reduce the base score but do not eliminate the threat in environments where checkpoint directories are accessible across jobs or administrative boundaries.
No in-the-wild exploitation of CVE-2026-1839 appears in CISA’s Known Exploited Vulnerabilities catalog or NVD as of April 24, 2026. The vulnerability is not listed in the KEV catalog, which is a meaningful data point — but not a permanent status.
The $125 bounty awarded through huntr for a finding that reaches C
, A, and arbitrary code execution in the context of a training cluster illustrates how underpowered ML framework bug bounty programs remain. Traditional software security programs typically price a local-to-RCE with high confidentiality and availability impact in the four-to-five figure range.Fix, Detection, and What ML Teams Should Do Right Now
The patched code ships in Transformers v5.0.0rc3. As of April 24, 2026, this is still a release candidate; verify whether v5.0.0 stable has shipped before deciding between upgrading to rc3 or waiting for the stable release. The release notes entry reads: “Fix unsafe torch.load() in _load_rng_state allowing arbitrary code execution” by ColeMurray.
Upgrading Transformers alone is insufficient if PyTorch is below 2.6. The correct remediation sequence:
- Audit PyTorch versions across all training environments — development, CI, and every production cluster independently. An environment at PyTorch 2.2–2.5 paired with pre-fix Transformers is fully exposed; an environment at PyTorch 2.2–2.5 paired with the patched Transformers may still be exposed depending on how
check_torch_load_is_safe()behaves at runtime when it detects the unsafe version. - Plan a PyTorch 2.6 migration accounting for the
rng_state.pthnumpy-globals issue in issue #34631. Existing checkpoints created under PyTorch < 2.6 may need to be regenerated or migrated once thesafe_globalsallowlist is updated in the patched code. - Treat checkpoint directories as an attack surface. Apply the same write-access controls to training checkpoint paths that you would to a model registry. Read-only access controls on consuming processes are not sufficient if write access to the directory is poorly scoped.
- Do not resume from checkpoints in locations accessible to untrusted parties, even if those checkpoints were generated by your own jobs. The security guarantee depends on the path remaining write-controlled from creation to resumption.
CVE-2026-1839 is the latest instance of a pattern that has hit lmdeploy, PyTorch Lightning, and other ML frameworks: torch.load() without weights_only=True in a code path that processes attacker-reachable files. The lesson each iteration reinforces is that ML framework safety guarantees are version-conditional. A context manager that appears to be a mitigation can be a no-op. The torch.load pickle problem is not resolved by any single version bump in any single dependency; it requires verifying that the specific version combination in each training environment actually enforces the guarantees the code implies.
Frequently Asked Questions
How does this differ from the SGLang torch.load vulnerability Groundy covered?
SGLang CVE-2026-5760 targets the model-download path — loading a third-party .pt file from a hub — whereas CVE-2026-1839 targets training checkpoint resumption from files the team’s own process wrote. The attack surfaces are inverted: one requires vetting external inputs, the other requires protecting the integrity of internal pipeline outputs between job steps.
Are inference-only serving endpoints affected?
No. The vulnerable _load_rng_state() path is exclusive to the Trainer class and only fires during checkpoint resumption. Model-weight loading for serving endpoints uses separate code paths in Transformers that already passed weights_only=True before this fix. Inference deployments are outside the vulnerability’s reach regardless of PyTorch version.
How does CVE-2026-1839 relate to CVE-2026-24747, the PyTorch safe-mode bypass?
They are separate issues. CVE-2026-24747 is a flaw in PyTorch’s own safe_globals enforcement, while CVE-2026-1839 is a missing weights_only=True in Transformers’ consumer code. SecurityOnline.info covered the PyTorch-level bypass but did not address the Transformers Trainer specifics — so teams tracking only PyTorch advisories may miss that their checkpoint loads remain unprotected even after applying PyTorch-side patches.
Who runs the huntr platform that handled this disclosure?
huntr is an AI/ML-focused bug bounty platform backed by Palo Alto Networks’ Prisma AIRS team. That a vendor-backed, category-specific platform priced a CWE-502 with C
/A impacts at $125 — compared to four-to-five-figure payouts for equivalent findings in general-purpose programs — suggests the underfunding is structural to the ML security market, not merely a platform maturity issue.