Which versions of PyTorch Lightning are affected by EUVD-2026-44751?

A vulnerability in PyTorch Lightning through version 2.6.5 allows attackers to execute arbitrary code on systems when users load malicious machine learning model files, threatening AI/ML…. A patch is available.

Is there a public PoC exploit available for EUVD-2026-44751?

Yes, a public proof-of-concept exploit is available for EUVD-2026-44751. Prioritise patching immediately. EPSS: 0.2%.

How to fix or mitigate EUVD-2026-44751?

Within 24 hours, inventory all systems running PyTorch Lightning and determine current versions in use across development, testing, and production environments. Within 7 days, upgrade all instances to the patched version per vendor release (addressing the instantiator allowlist security fix in PR #21832), prioritizing any systems that load external or open-source model checkpoints. Within 30 days, validate functionality across all ML pipelines, implement policies restricting checkpoint loading to trusted sources only, and establish a process for monitoring PyTorch security advisories.

PyTorch Lightning EUVD-2026-44751

Q: What is the CVSS score of EUVD-2026-44751?

EUVD-2026-44751 has a CVSS 4.0 base score of 8.4 (High). CVSS vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-58659 HIGH

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

2026-07-15 VulnCheck

GHSA-qqmf-gpg7-g8gw

RCE Pytorch Lightning Checkpoint

8.4

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.4 HIGH

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.8 HIGH

Local because a checkpoint file must be loaded (AV:L) with required victim interaction (UI:R); crafting the file needs no attacker privileges (PR:N), and code execution yields full C/I/A impact.

3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

7.8 HIGH

qualitative

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 15, 2026 - 17:46 vuln.today

Analysis Generated

Jul 15, 2026 - 17:46 vuln.today

CVE Published

Jul 15, 2026 - 17:02 cve.org

HIGH 8.4

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1,700 pypi packages depend on pytorch-lightning (663 direct, 1,111 indirect)

Ecosystem-wide dependent count for version 2.6.6.

DescriptionCVE.org

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.

AnalysisAI

Remote code execution in PyTorch Lightning through 2.6.5 allows an attacker who can get a victim to load a malicious checkpoint file to execute arbitrary code. The flaw lives in the _load_state routine, which imports and calls the module path named in a checkpoint's _instantiator hyperparameter, letting a crafted .ckpt bypass torch's weights_only=True safeguard when LightningModule.load_from_checkpoint is invoked. Reported by VulnCheck, it is fixed in commit d710d68 (PR #21832) via an instantiator allowlist, and publicly available exploit code exists though it is not listed in CISA KEV.

Technical ContextAI

PyTorch Lightning is a widely used high-level training framework layered on top of PyTorch. Checkpoints are Python objects serialized with torch.save; recent PyTorch versions added weights_only=True to torch.load to block the classic pickle-based code-execution path during deserialization. This vulnerability is a distinct, application-level bypass: Lightning stores an _instantiator hyperparameter (an import path string) inside the checkpoint's hyper_parameters, and _load_state in src/lightning/pytorch/core/saving.py dynamically imports and invokes whatever module path that string names. This is a textbook CWE-470 (Use of Externally-Controlled Input to Select Classes or Code / unsafe reflection) issue - trusted control flow is driven by attacker-controlled data, so weights_only=True offers no protection because the dangerous import happens in Lightning's own logic after load, not inside pickle. The affected package is cpe:2.3:a:lightning-ai:pytorch-lightning.

RemediationAI

Upgrade to a PyTorch Lightning build containing fix commit d710d689510d50e800f53b3cd773cbca20b1f86f (PR #21832), which restricts the checkpoint _instantiator hyperparameter to an allowlist (_ALLOWED_INSTANTIATORS = lightning.pytorch.cli.instantiate_module and pytorch_lightning.cli.instantiate_module) and raises a ValueError on any other path; the upstream fix is confirmed, but a specific tagged/PyPI release version is not stated in the provided data, so verify the fixed version against the vendor advisory (https://www.vulncheck.com/advisories/pytorch-lightning-arbitrary-code-execution-via-instantiator-hyperparameter) before pinning. Until patched, only load checkpoints from trusted, provenance-verified sources and never load third-party or user-uploaded .ckpt files, since weights_only=True does NOT mitigate this bug; as a compensating control, inspect a checkpoint's hyper_parameters['_instantiator'] value before loading and reject anything that is not an lightning.pytorch.cli / pytorch_lightning.cli instantiate_module path, or run load_from_checkpoint inside a sandboxed, network-isolated, least-privilege process so any code execution is contained. The trade-off of restricting to trusted checkpoints is operational friction in workflows that consume community models, and manual _instantiator inspection is error-prone compared with upgrading.