Description

MONAI through 1.6.0 contains a remote code execution vulnerability in the bundle configuration engine that resolves _target_ values to arbitrary importable callables without an allow list and passes $ expressions to Python eval(). Attackers can publish a malicious bundle with crafted configuration containing arbitrary code that executes when a victim loads the bundle using monai.bundle.load() or monai.bundle.run().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-27T02:17:22.387Z",
  "pubdate": "2026-09-27T02:17:22.387Z",
  "executiveSummary": "MONAI versions through 1.6.0 contain a critical remote code execution (RCE) vulnerability within its bundle configuration engine.\nThe vulnerability arises from insecure deserialization and dynamic evaluation of untrusted configuration files, allowing arbitrary code execution on systems that process malicious bundles.\nThe flaw affects the monai.bundle.load() and monai.bundle.run() functions, which are responsible for initializing model configurations.\nAn attacker can exploit this by distributing a crafted bundle containing malicious directives that trigger execution upon ingestion.\nThe risk is severe as it grants an attacker the ability to execute arbitrary Python code with the privileges of the user running the MONAI application.\nThis vulnerability does not require authentication to trigger; however, it necessitates user interaction or automated ingestion of a compromised bundle file.\nOrganizations relying on MONAI for medical imaging workflows should prioritize updating to a remediated version or restricting bundle sourcing to trusted, internal repositories.",
  "technicalDetails": "The vulnerability resides in the MONAI bundle configuration engine, specifically in the mechanisms used to resolve dynamic components within configuration files.\nThe configuration engine permits the use of '_target_' keys, which are intended to map configuration parameters to importable Python callables. In versions 1.6.0 and earlier, this resolution process lacks an allow-list, meaning the engine can resolve any class or function accessible within the Python path, regardless of its safety or intended use.\nFurthermore, the engine supports a '$' prefix syntax within configuration values to denote dynamic evaluation. The library processes these expressions by passing them directly to the Python 'eval()' function without sufficient sanitization or isolation.\nAn attack flow commences when a victim invokes 'monai.bundle.load()' or 'monai.bundle.run()' on an untrusted bundle. The engine parses the 'config.json' or associated YAML files within the bundle. When the parser encounters a '$' expression, it initiates the 'eval()' call, executing the embedded arbitrary Python code.\nSimultaneously, by manipulating the '_target_' parameter, an attacker can instantiate arbitrary Python objects, leading to gadget-based exploitation scenarios. By chaining these capabilities, an attacker can achieve a full remote code execution payload that executes in the context of the host process.\nThe vulnerability is inherent to the design of the configuration loader. Because 'eval()' is invoked on user-controlled input, there is no validation of the code's source or intent. The lack of an allow-list for '_target_' imports effectively bypasses intended sandboxing, granting the attacker the ability to import system-level modules (e.g., 'os', 'subprocess') to facilitate further malicious activity, such as reverse shell spawning, file exfiltration, or persistence.\nThis is a client-side or server-side processing vulnerability depending on the deployment; any automated pipeline that fetches and executes bundles from external, untrusted, or unauthenticated sources is at immediate risk. The impact is total system compromise relative to the local execution environment, as there are no inherent privilege restrictions enforced by the MONAI engine during the configuration resolution phase."
}