Summary
MONAI's bundle configuration engine can resolve _target_ values to arbitrary importable callables and evaluate $ expressions as Python code. If a victim loads a malicious bundle with monai.bundle.load() or monai.bundle.run(), an attacker may execute arbitrary code in the application's runtime context.
Affected context
The vulnerability occurs in MONAI bundle workflows that process configuration-controlled _target_ values or $ expressions during bundle loading or execution. Risk is higher when bundles can be obtained from untrusted publishers, shared repositories, external users, or other sources that are not subject to strong integrity and trust controls.
Exploit preconditions
- Attack surface: MONAI bundle configuration processing
- Required access: Ability to publish, replace, or otherwise influence a bundle that a victim loads
- Trigger point: Invocation of
monai.bundle.load()ormonai.bundle.run()on the malicious bundle - Why exploitation is possible: Configuration values can select importable callables without an allow list, while
$expressions are evaluated as Python code
Why this happens
The underlying bug is the treatment of bundle configuration as executable behavior rather than constrained data. Resolving arbitrary _target_ values permits configuration to select importable Python callables without an explicit trust policy, and evaluating $ expressions with Python eval() enables code execution from attacker-controlled expressions. This behavior maps to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code, because untrusted input is incorporated into a dynamic execution mechanism.
Potential impact
- An attacker may execute arbitrary code within the process loading the bundle
- The application environment could be compromised
- Credentials, datasets, or configuration secrets may be exposed
- Attackers could modify model behavior or poison generated results
- Additional systems may be affected if the runtime has excessive permissions
General mitigation guidance
Mitigation generally focuses on treating bundle configuration as untrusted data and removing dynamic execution from normal loading paths.
Common defensive patterns include:
- Replacing Python
eval()with a non-executable expression parser or a narrowly defined declarative syntax - Enforcing an explicit, minimal allow list for permitted target classes and functions
- Validating bundle structure and types against a strict schema before resolving targets or expressions
- Requiring signed bundles or authenticated, integrity-protected distribution channels
- Separating bundle inspection from execution and using isolated, least-privileged runtimes for untrusted content
- Limiting access to secrets, host resources, filesystems, and network services available to the bundle process
How teams detect issues like this
High-level detection can include:
- Static analysis rules identifying calls to
eval()or equivalent dynamic evaluation in configuration-processing code - Code review checks for configuration-driven imports, callable resolution, and missing target allow lists
- Repository searches for bundle loaders that execute expressions before schema validation
- Policy enforcement requiring signed or approved bundles before execution
- Runtime monitoring for unexpected imports, subprocess creation, filesystem access, or network activity during bundle loading
Automated security review tools can help identify dynamic execution patterns, but findings should be confirmed against the application's trust boundaries.
