Summary
MONAI PersistentDataset and related cache helpers deserialize cached content with unsafe pickle-based mechanisms, including torch.load configurations that permit unrestricted object loading. A local user who can write to a shared or world-writable cache directory may place a malicious cache artifact that executes code when another user's pipeline reads it.
Affected context
The vulnerability can occur in MONAI pipelines that use PersistentDataset or related cache helpers with a cache directory accessible to multiple users or processes. Risk is higher when cache files are stored in shared locations such as temporary directories, HPC scratch space, or user cache paths where another local user can create or replace cached content before it is consumed.
Exploit preconditions
- Attack surface: Local filesystem access to a MONAI cache directory
- Required access: Permission to create, modify, or replace cache artifacts
- Trigger point: A victim's MONAI pipeline loads a previously stored cache entry
- Why exploitation is possible: Cached data is deserialized using pickle-compatible behavior, allowing attacker-controlled serialized objects to invoke code during loading
Why this happens
The underlying issue is unsafe deserialization of data from a cache whose integrity and ownership are not sufficiently trusted. MONAI may use torch.load with unrestricted object loading for cached MetaTensors, while related helpers invoke pickle.loads directly; both behaviors can reconstruct attacker-controlled Python objects. This maps to CWE-502: Deserialization of Untrusted Data, because serialized input is treated as trusted executable object state rather than as constrained data.
Potential impact
- An attacker may execute arbitrary code in the victim user's process context
- The victim's data, credentials, and experiment artifacts could be exposed or modified
- Shared research or machine-learning workflows could be poisoned
- A compromised process could enable further local or network-based activity
- Multi-user compute environments could experience cross-user compromise
General mitigation guidance
Mitigation generally focuses on removing executable deserialization from untrusted cache paths and enforcing cache ownership boundaries.
Common defensive patterns include:
- Prefer safe, restricted, or data-only serialization formats for cache contents
- Avoid unrestricted pickle-compatible loading for artifacts that may be modified externally
- Store caches in per-user directories with restrictive permissions and controlled ownership
- Treat shared and world-writable cache locations as untrusted input sources
- Validate cache metadata, provenance, and expected structure before consumption
- Use least-privilege process and filesystem permissions to limit the effect of code execution
- Isolate workloads that consume shared caches when cross-user access is unavoidable
How teams detect issues like this
Detection can include static analysis rules for pickle.loads, unrestricted torch.load usage, and deserialization of files from shared or temporary paths. Code review should flag cache loaders that do not authenticate artifacts, derive trust from writable directories, or deserialize before validating format and provenance. File-integrity monitoring, ownership and permission checks, and policy enforcement for shared cache locations can identify suspicious replacements. Automated code review tools may help detect unsafe deserialization patterns during development.
