CVE-2026-58659: PyTorch Lightning RCE

Q: Is CVE-2026-58659 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-58659, increasing the risk of exploitation.

Q: How to fix CVE-2026-58659?

1) Upgrade PyTorch Lightning to the version containing commit d710d68 (post 2.6.5) immediately. 2) Until patched, do not load checkpoints from untrusted or external sources — treat all `.ckpt` files as executable code. 3) Where external checkpoints must be used, load them in an isolated/sandboxed environment (container with no network/credential access) before promoting to production pipelines. 4) Scan checkpoint files with tools like `picklescan` or `fickling` to detect unsafe deserialization payloads before loading. 5) Monitor training/inference hosts for unexpected process spawns or module imports correlated with checkpoint-loading calls. 6) Audit CI/CD and model-registry pipelines for any automated checkpoint loading from external or user-submitted sources.

Q: What systems are affected by CVE-2026-58659?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, MLOps/checkpoint management.

Q: What is the CVSS score for CVE-2026-58659?

CVE-2026-58659 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.63%.

CISO Take

PyTorch Lightning's checkpoint loader trusts an internal `_instantiator` hyperparameter enough to import and execute an attacker-named Python module, which defeats the `weights_only=True` protection that teams rely on to treat checkpoints as inert data rather than executable code. With 1,694 downstream projects depending on this library and checkpoints routinely passed between researchers, CI jobs, and shared model repositories, a single poisoned file can propagate widely even though this sits at CVSS 7.8 rather than critical severity. There is no CISA KEV listing, no public exploit code, and EPSS is only 0.33% (top-75th percentile), so this is not yet an actively exploited threat — but attack complexity is low and no privileges are required, only that a user be induced to load the file, which is routine in ML workflows. Patch to the version containing commit d710d68 immediately; until then, treat any checkpoint sourced outside your own trusted training pipeline as untrusted executable code, not data. Detection teams should monitor for anomalous module imports or subprocess activity triggered from `LightningModule.load_from_checkpoint` calls in training and inference logs.

Sources:NVDGitHub AdvisoryEPSSOpenSSFATLAS

What is the risk?

High local-vector risk: CVSS 7.8 with low attack complexity and no privileges required means any workflow that ingests third-party checkpoints is exposed, though the requirement for user interaction and the absence of KEV listing, public exploit, or scanner tooling keeps current real-world exploitation likelihood low (EPSS 0.33%, top 75th percentile). The real driver of risk here is scale of exposure (1,694 dependents, OpenSSF Scorecard of only 5.9/10, 7 other CVEs in the same package) rather than active in-the-wild attacks — this is a supply-chain-style risk that could escalate quickly if weaponized checkpoint-sharing becomes common.

How does the attack unfold?

Distribution

Attacker crafts a checkpoint file with a malicious _instantiator hyperparameter and distributes it via a shared model repository or direct delivery.

AML.T0010.001

User Execution

A developer calls LightningModule.load_from_checkpoint on the file, trusting weights_only=True to keep it safe.

AML.T0011.000

Exploitation

The _load_state function imports and instantiates the attacker-controlled module, bypassing the weights_only protection.

AML.T0018.002

Impact

Arbitrary code executes with the privileges of the training or inference process, compromising the host and any accessible data or credentials.

AML.T0112.001

Distribution

Attacker crafts a checkpoint file with a malicious _instantiator hyperparameter and distributes it via a shared model repository or direct delivery.

AML.T0010.001

User Execution

A developer calls LightningModule.load_from_checkpoint on the file, trusting weights_only=True to keep it safe.

AML.T0011.000

Exploitation

The _load_state function imports and instantiates the attacker-controlled module, bypassing the weights_only protection.

AML.T0018.002

Impact

Arbitrary code executes with the privileges of the training or inference process, compromising the host and any accessible data or credentials.

AML.T0112.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PyTorch Lightning	pip	< 2.6.6	`2.6.6`
31.4KOpenSSF 5.91.7K dependentsPushed yesterday56% patched~348d to patchFull package profile →
PyTorch Lightning	pip	—	No patch
31.4KOpenSSF 5.91.7K dependentsPushed yesterday56% patched~348d to patchFull package profile →

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 50% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVLocal

ACLow

PRNone

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade PyTorch Lightning to the version containing commit d710d68 (post 2.6.5) immediately. 2) Until patched, do not load checkpoints from untrusted or external sources — treat all .ckpt files as executable code. 3) Where external checkpoints must be used, load them in an isolated/sandboxed environment (container with no network/credential access) before promoting to production pipelines. 4) Scan checkpoint files with tools like picklescan or fickling to detect unsafe deserialization payloads before loading. 5) Monitor training/inference hosts for unexpected process spawns or module imports correlated with checkpoint-loading calls. 6) Audit CI/CD and model-registry pipelines for any automated checkpoint loading from external or user-submitted sources.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionSupply ChainFrameworkModelAML.T0010.001- AI Software AML.T0011.000- Unsafe AI Artifacts AML.T0018.002- Embed Malware AML.T0050- Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-Security of AI systems throughout the lifecycle

NIST AI RMF

MANAGE 1.1-Ongoing monitoring and management of AI risks including third-party components

OWASP LLM Top 10

LLM05-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-58659?

PyTorch Lightning's checkpoint loader trusts an internal `_instantiator` hyperparameter enough to import and execute an attacker-named Python module, which defeats the `weights_only=True` protection that teams rely on to treat checkpoints as inert data rather than executable code. With 1,694 downstream projects depending on this library and checkpoints routinely passed between researchers, CI jobs, and shared model repositories, a single poisoned file can propagate widely even though this sits at CVSS 7.8 rather than critical severity. There is no CISA KEV listing, no public exploit code, and EPSS is only 0.33% (top-75th percentile), so this is not yet an actively exploited threat — but attack complexity is low and no privileges are required, only that a user be induced to load the file, which is routine in ML workflows. Patch to the version containing commit d710d68 immediately; until then, treat any checkpoint sourced outside your own trusted training pipeline as untrusted executable code, not data. Detection teams should monitor for anomalous module imports or subprocess activity triggered from `LightningModule.load_from_checkpoint` calls in training and inference logs.

Is CVE-2026-58659 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-58659, increasing the risk of exploitation.

How to fix CVE-2026-58659?

1) Upgrade PyTorch Lightning to the version containing commit d710d68 (post 2.6.5) immediately. 2) Until patched, do not load checkpoints from untrusted or external sources — treat all `.ckpt` files as executable code. 3) Where external checkpoints must be used, load them in an isolated/sandboxed environment (container with no network/credential access) before promoting to production pipelines. 4) Scan checkpoint files with tools like `picklescan` or `fickling` to detect unsafe deserialization payloads before loading. 5) Monitor training/inference hosts for unexpected process spawns or module imports correlated with checkpoint-loading calls. 6) Audit CI/CD and model-registry pipelines for any automated checkpoint loading from external or user-submitted sources.

What systems are affected by CVE-2026-58659?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, MLOps/checkpoint management.

What is the CVSS score for CVE-2026-58659?

CVE-2026-58659 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.63%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingMLOps/checkpoint management

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0011.000Unsafe AI Artifacts

AML.T0018.002Embed Malware

AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 1.1

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

PyTorch Lightning through 2.6.5, fixed in commit d710d68, contains a remote code execution vulnerability in the _load_state function that imports and executes attacker-controlled module names from checkpoint _instantiator hyperparameters. Attackers can craft malicious checkpoint files that bypass weights_only=True protections to execute arbitrary code when LightningModule.load_from_checkpoint is called.

Exploitation Scenario

An attacker crafts a PyTorch Lightning checkpoint file whose `_instantiator` hyperparameter references a malicious, attacker-controlled module path instead of a legitimate class. The attacker distributes this checkpoint disguised as a useful pretrained model or fine-tuning checkpoint — via a public model-sharing forum, a compromised or lookalike repository, or directly to a target researcher. A developer or ML engineer, trusting that `weights_only=True` makes checkpoint loading safe, calls `LightningModule.load_from_checkpoint()` on the file. The `_load_state` function imports and instantiates the attacker's module, achieving arbitrary code execution with the privileges of the training or inference process — potentially exposing training data, cloud credentials, or other artifacts on that host.

Weaknesses (CWE)

CWE-470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')Primary CWE-470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')Primary CWE-470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

CWE-470 — Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'): The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

[Architecture and Design] Refactor your code to avoid using reflection.
[Architecture and Design] Do not use user-controlled inputs to select and load classes or code.

Source: MITRE CWE corpus.