Summary
MONAI contains an unsafe deserialization vulnerability in the
algo_from_pickle function, which passes pickle data directly to
pickle.loads without establishing trust in the file or validating its
contents. If an application processes an attacker-supplied pickle file,
specially crafted objects may execute arbitrary code in the application's
security context.
Affected context
The vulnerability occurs in MONAI Auto3DSeg workflows that invoke
algo_from_pickle on a .pkl file whose origin or integrity is not
reliably controlled. Risk is higher when model artifacts, algorithm
packages, or other serialized files can be uploaded, replaced, or selected
by an untrusted user or external process before deserialization.
Exploit preconditions
- Attack surface: An application or workflow that calls
monai.auto3dseg.utils.algo_from_pickle
- Required access: Ability to supply, modify, or cause selection of a
pickle file processed by the application
- Trigger point: Invocation of
pickle.loadswhile loading the file - Why exploitation is possible: Python pickle deserialization can invoke
attacker-controlled object behavior, including __reduce__, before the
resulting object is safely constrained
Why this happens
The underlying bug is the use of Python's general-purpose pickle
deserialization on data whose source and contents are not trusted. Pickle
supports object reconstruction behaviors that can execute code during
loading, so deserializing attacker-controlled bytes is not equivalent to
parsing passive data. This behavior maps to CWE-502: Deserialization of Untrusted Data.
Potential impact
- An attacker may execute arbitrary code with the privileges of the
MONAI application
- Sensitive files, credentials, or medical imaging data could be accessed
- The application environment could be modified or disrupted
- Compromised workloads could be used for lateral movement or data
tampering
General mitigation guidance
Mitigation generally focuses on eliminating unsafe deserialization of
untrusted artifacts and reducing trust in serialized inputs.
Common defensive patterns include:
- Prefer non-executable, data-only formats with strict schemas for
interoperable artifacts
- Use restricted loaders or validated formats when serialization is
unavoidable
- Permit model and algorithm files only from authenticated, integrity-
checked sources
- Separate artifact acquisition from deserialization and enforce allowlists
for permitted objects or formats
- Run processing workloads with least privilege, isolated credentials, and
restricted filesystem and network access
- Treat uploaded or externally sourced files as untrusted until verified
How teams detect issues like this
Detection programs can search source code and dependencies for calls to
pickle.loads, pickle.load, and related pickle APIs, especially where the
input originates from files, uploads, network responses, or user-controlled
paths. Code review should examine whether artifact provenance, integrity,
format restrictions, and trust boundaries are explicit before any
deserialization occurs. CI policy can prohibit unrestricted pickle loading
in application-facing code or require security review exceptions.
Automated static-analysis and software-composition-analysis tools may help
identify unsafe deserialization patterns and affected dependency usage.
