CVE-2026-15531: HashNeRF-pytorch torch.load

CISO Take

HashNeRF-pytorch, an open-source NeRF research implementation, loads training checkpoints via torch.load in run_nerf.py without any integrity, type, or origin validation, so a maliciously crafted checkpoint file executes arbitrary code the moment it's deserialized. The attack requires local access and low privileges, which caps the CVSS at 5.3 medium and keeps it off CISA KEV, but the underlying technique — pickle-based deserialization RCE embedded in a shared model checkpoint — is a well-worn pattern in ML research tooling, and the exploit is already publicly disclosed on GitHub with a pending, unmerged fix (PR #50). This isn't infrastructure most enterprises run in production, but any research or MLOps team that pulls community NeRF checkpoints, fine-tuned weights, or shares .pth files with external collaborators inherits the same risk class as pickle-based attacks against torch, TensorFlow, and other frameworks. Track the upstream PR for merge status, and until then require checkpoint scanning (picklescan, fickling) or migration to safetensors before any untrusted checkpoint is loaded.

Sources: NVD ATLAS github.com/yashbhalgat/HashNeRF-pytorch

What is the risk?

Objectively medium per CVSS (5.3, local attack vector, low privileges required, limited confidentiality/integrity/availability impact each rated Low), but the practical severity of the underlying primitive is high: successful exploitation is full arbitrary code execution in the context of whoever runs run_nerf.py, not a bounded data leak. The attack vector is constrained to local execution of an attacker-supplied checkpoint file (PR:L, AC:L, UI:N), so remote drive-by exploitation isn't possible — the realistic path is social engineering or supply-chain distribution of a poisoned checkpoint. No EPSS score or KEV listing exists yet, and there's no Nuclei template, consistent with a niche research repo rather than widely deployed production software. The fix has been proposed (PR #50) but not merged, and the project uses a rolling-release model with no versioned patches to track.

How does the attack unfold?

Malicious checkpoint creation

Attacker crafts a poisoned checkpoint file embedding a malicious pickle payload disguised as legitimate NeRF model weights.

AML.T0011.000

Distribution

Attacker publishes or shares the checkpoint via GitHub, forums, or research collaboration channels as a seemingly legitimate pre-trained model.

AML.T0002.001

User execution

Victim loads the checkpoint locally by running run_nerf.py, which calls torch.load(ckpt_path) without validating the file's contents.

AML.T0011

Code execution / impact

Pickle deserialization triggers attacker-controlled code execution on the victim's machine, compromising local credentials, data, or connected infrastructure.

AML.T0112.001

Malicious checkpoint creation

Attacker crafts a poisoned checkpoint file embedding a malicious pickle payload disguised as legitimate NeRF model weights.

AML.T0011.000

Distribution

Attacker publishes or shares the checkpoint via GitHub, forums, or research collaboration channels as a seemingly legitimate pre-trained model.

AML.T0002.001

User execution

Victim loads the checkpoint locally by running run_nerf.py, which calls torch.load(ckpt_path) without validating the file's contents.

AML.T0011

Code execution / impact

Pickle deserialization triggers attacker-controlled code execution on the victim's machine, compromising local credentials, data, or connected infrastructure.

AML.T0112.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
HashNeRF-pytorch	—	—	No patch

Do you use HashNeRF-pytorch? You're affected.

How severe is it?

CVSS 3.1

5.3 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C Low

I Low

A Low

What should I do?

1 step

1) Track and apply GitHub PR #50 once merged upstream, or manually patch run_nerf.py to use torch.load(ckpt_path, weights_only=True) or migrate checkpoint format to safetensors, which does not support arbitrary code execution. 2) Never load checkpoint files from untrusted or unverified sources — treat community-shared .pth/.tar files as executable code, not data. 3) Scan third-party checkpoints with picklescan or fickling before loading them into any environment with sensitive access. 4) Run training/inference jobs that consume external checkpoints in sandboxed, network-isolated containers with minimal credentials attached. 5) Detection: monitor for unexpected child processes or network egress spawned during torch.load calls in ML training pipelines, and audit which teams/scripts load checkpoints from outside version-controlled, internally-vetted sources.

How is it classified?

Code Execution Supply Chain Model Framework AML.T0011 - User Execution AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE 2.3 - Mechanisms for managing risks from third-party AI resources

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-15531?

HashNeRF-pytorch, an open-source NeRF research implementation, loads training checkpoints via torch.load in run_nerf.py without any integrity, type, or origin validation, so a maliciously crafted checkpoint file executes arbitrary code the moment it's deserialized. The attack requires local access and low privileges, which caps the CVSS at 5.3 medium and keeps it off CISA KEV, but the underlying technique — pickle-based deserialization RCE embedded in a shared model checkpoint — is a well-worn pattern in ML research tooling, and the exploit is already publicly disclosed on GitHub with a pending, unmerged fix (PR #50). This isn't infrastructure most enterprises run in production, but any research or MLOps team that pulls community NeRF checkpoints, fine-tuned weights, or shares .pth files with external collaborators inherits the same risk class as pickle-based attacks against torch, TensorFlow, and other frameworks. Track the upstream PR for merge status, and until then require checkpoint scanning (picklescan, fickling) or migration to safetensors before any untrusted checkpoint is loaded.

Is CVE-2026-15531 actively exploited?

No confirmed active exploitation of CVE-2026-15531 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-15531?

1) Track and apply GitHub PR #50 once merged upstream, or manually patch run_nerf.py to use torch.load(ckpt_path, weights_only=True) or migrate checkpoint format to safetensors, which does not support arbitrary code execution. 2) Never load checkpoint files from untrusted or unverified sources — treat community-shared .pth/.tar files as executable code, not data. 3) Scan third-party checkpoints with picklescan or fickling before loading them into any environment with sensitive access. 4) Run training/inference jobs that consume external checkpoints in sandboxed, network-isolated containers with minimal credentials attached. 5) Detection: monitor for unexpected child processes or network egress spawned during torch.load calls in ML training pipelines, and audit which teams/scripts load checkpoints from outside version-controlled, internally-vetted sources.

What systems are affected by CVE-2026-15531?

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

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

CVE-2026-15531 has a CVSS v3.1 base score of 5.3 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel serving

MITRE ATLAS Techniques

AML.T0011 User Execution

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

A vulnerability has been found in yashbhalgat HashNeRF-pytorch up to 82885e698295982504eb6a26d060a6b2473e3706. Affected by this issue is the function torch.load of the file run_nerf.py of the component Checkpoint File Handler. The manipulation of the argument ckpt_path leads to deserialization. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. The pull request to fix this issue awaits acceptance.

Exploitation Scenario

An attacker publishes a NeRF checkpoint on GitHub, a research forum, or a model-sharing platform, claiming it's a pre-trained model for a popular 3D reconstruction dataset. A researcher or ML engineer, trusting the source, downloads the file and passes its path as --ckpt_path to run_nerf.py to resume training or run inference. The script calls torch.load on the file, which deserializes the embedded pickle payload and executes attacker-controlled code with the privileges of the researcher's account — potentially exfiltrating credentials, pivoting into connected cloud training infrastructure, or planting persistence on the researcher's workstation.

Weaknesses (CWE)

CWE-20 Improper Input Validation Primary CWE-502 Deserialization of Untrusted Data Primary CWE-20 Improper Input Validation CWE-502 Deserialization of Untrusted Data

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.