Summary
MONAI contains an eval injection vulnerability in the bundle verification flow, where a shape expression can bypass name-based validation and reach Python's eval function. An attacker who can influence bundle metadata may use object introspection expressions to execute code when the affected verification workflow processes that metadata.
Affected context
The vulnerability occurs in MONAI deployments that use the bundle verify_net_in_out CLI flow and process attacker-influenced metadata containing spatial shape expressions. It is associated with _get_fake_spatial_shape() in monai/bundle/scripts.py, which evaluates the expression after an incomplete abstract-syntax-tree allowlist check. The risk depends on whether an untrusted party can create, modify, or supply a bundle consumed by this non-default workflow.
Exploit preconditions
- Attack surface: Bundle metadata processing during the
verify_net_in_outworkflow - Required access: Ability to influence the bundle metadata or provide a crafted bundle to the verification process
- Trigger point: Evaluation of a shape expression by
_get_fake_spatial_shape(), reached through input-data and network verification logic - Why exploitation is possible: The validator rejects disallowed
ast.Namenodes but does not adequately restrict attribute, subscript, call, and constant-based expression chains before invokingeval()
Why this happens
The underlying bug is an incomplete validation strategy applied to an expression that is later executed as Python code. The helper focuses on collecting and allowlisting ast.Name nodes, but expressions can perform object introspection through other AST node types without containing a disallowed name. Passing such expressions to eval() preserves access to language features that the validator intended to exclude, mapping to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection').
Potential impact
- An attacker may execute arbitrary Python code in the MONAI process
- The affected worker or host could be compromised
- Sensitive files, environment variables, or credentials may be exposed
- Processing integrity could be undermined through model, data, or configuration tampering
- Compromised execution environments could be used for further lateral movement
General mitigation guidance
Mitigation generally centers on removing dynamic evaluation from metadata processing and treating bundle metadata as untrusted input.
Common defensive patterns include:
- Replacing
eval()with structured parsing and explicit numeric shape representations - Applying a complete AST policy only where expression support is unavoidable, rejecting attributes, calls, subscripts, introspection, and unexpected node types
- Enforcing strict schemas, type checks, and bounds for shape values before use
- Separating metadata validation from execution-capable application logic
- Restricting bundle provenance and preventing untrusted metadata from reaching verification jobs
- Running verification processes with least privilege and limited filesystem, network, and credential access
How teams detect issues like this
Detection approaches can include:
- Static analysis rules identifying
eval()and related dynamic execution APIs applied to metadata or configuration - Code review checks for AST validators that inspect only selected node types or names
- Tests using attribute, subscript, call, constant, and introspection-based expression structures to verify complete rejection
- Policy enforcement that requires typed, schema-validated metadata instead of executable expressions
- Runtime monitoring for unexpected child processes, filesystem access, or network activity during bundle verification
- Automated security review tools that flag dynamic evaluation and incomplete input sanitization
