Summary
MONAI's NumpyReader may unsafely deserialize data when it loads .npy or .npz files with NumPy pickle support enabled. An attacker who can supply or cause a malicious array file to enter a MONAI data pipeline may execute arbitrary code in the process loading it.
Affected context
The vulnerability occurs in MONAI deployments that use the NumpyReader class to process .npy or .npz files while pickle-enabled loading remains active. It is most relevant when input files originate from untrusted users, external datasets, shared storage, model repositories, or other sources that are not fully controlled by the application.
Exploit preconditions
- Attack surface: MONAI data-loading pipelines that invoke NumpyReader for NumPy array files
- Required access: Ability to place, replace, or reference a malicious
.npyor.npzfile consumed by the pipeline - Trigger point: Loading the file through the standard MONAI data pipeline
- Why exploitation is possible: NumPy loading permits pickle deserialization, allowing crafted file contents to invoke attacker-controlled object behavior during processing
Why this happens
The underlying bug is the unconditional use of numpy.load with allow_pickle=True for input files that may not be trustworthy. Pickle is an executable serialization format rather than a data-only representation; deserializing attacker-controlled content can invoke arbitrary Python behavior. This maps to CWE-502: Unsafe Deserialization, because serialized input is reconstructed without adequately restricting executable object semantics.
Potential impact
- Arbitrary code execution in the MONAI worker or application process
- Exposure, alteration, or destruction of locally accessible data
- Credential theft from the runtime environment
- Modification of datasets, pipelines, or generated outputs
- Possible lateral movement depending on process privileges and network access
General mitigation guidance
Mitigation generally centers on treating NumPy files from outside the trust boundary as untrusted and eliminating executable deserialization from routine data loading.
Common defensive patterns include:
- Prefer data-only formats and loaders that do not support pickle objects
- Permit pickle-enabled loading only for tightly controlled, authenticated inputs
- Validate file provenance, type, structure, and expected schema before processing
- Separate ingestion and transformation workloads from sensitive services
- Run data-processing components with least privilege and restricted filesystem and network access
- Use read-only or isolated workspaces for externally sourced datasets where practical
- Apply dependency and code-review policies that flag unsafe deserialization settings
How teams detect issues like this
Detection can combine source review, automated analysis, and runtime monitoring:
- Search code and configuration for
numpy.loadcalls usingallow_pickle=True - Review every data-loading path for trust-boundary assumptions and externally controlled filenames
- Add static-analysis or dependency-policy rules for unsafe deserialization APIs
- Monitor pipeline inputs for unexpected NumPy object arrays and files from unapproved sources
- Record process behavior during ingestion, including unexpected subprocess creation, filesystem writes, or network connections
- Use automated code-review tools to identify unsafe loader settings and missing validation
