CVE-2026-34445: 
Python vulnerability analysis and mitigation

CVE-2026-34445 is an improper input validation vulnerability in the Open Neural Network Exchange (ONNX) library affecting the ExternalDataInfo class. The flaw allows network-accessible attackers to craft malicious ONNX model files that trigger denial of service, unauthorized file access, or object state corruption. All versions of ONNX prior to 1.21.0 (i.e., <= 1.20.1) are affected. The vulnerability was published on April 1, 2026, with the fix merged on March 18, 2026, and included in the 1.21.0 release. It carries a CVSS v3.1 base score of 8.6 (High) (Github Advisory, Red Hat Bugzilla).

The root cause lies in ExternalDataInfo.__init__ using Python's setattr() to blindly apply key-value pairs from a model's TensorProto.external_data field without validating the keys against an allowlist (CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes). This enables three distinct attack vectors: (1) DoS via resource exhaustion — setting length to an astronomically large value (e.g., 9 petabytes) causes the runtime to attempt a massive memory allocation, triggering an Out-of-Memory crash (CWE-400); (2) unauthorized file access — setting offset to a negative value (e.g., -1) causes file.seek(-1) to raise an OSError or read unintended file regions; (3) object corruption — injecting Python dunder attributes such as __class__ or __dict__ can corrupt the object's internal state, potentially enabling type confusion attacks. The vulnerability is triggered during onnx.load() with no explicit checker invocation required (Github Advisory, Fix PR).

Successful exploitation can cause immediate server crashes or freezes through memory exhaustion (high availability impact), allow an attacker to read unintended portions of files on the server (low confidentiality impact), and corrupt internal object state in ways that may enable further exploitation (low integrity impact). Any system or service that loads untrusted ONNX model files — including ML inference servers, model hubs, and CI/CD pipelines — is at risk. The attack requires no authentication and no user interaction, making it particularly dangerous in environments that accept user-supplied model files over a network (Github Advisory, Red Hat Bugzilla).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). No threat actor attribution has been reported. The EPSS score is approximately 0.04% (0.000400), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack is straightforward to execute — crafting a malicious ONNX protobuf file requires minimal skill — and the lack of authentication requirements lowers the barrier for exploitation in exposed environments (Github Advisory).

1. Craft a malicious ONNX model: Using the ONNX protobuf API or a hex editor, create an ONNX model file with a TensorProto that includes crafted external_data entries. For a DoS attack, set the length key to an extremely large integer value (e.g., 9000000000000000 representing ~9 petabytes).
2. Inject malicious keys (optional): For object corruption, add entries with keys such as __class__ or __dict__ as the key field in StringStringEntryProto within external_data.
3. Deliver the model: Submit the crafted .onnx file to a target service that calls onnx.load() on user-supplied models — such as an ML inference API, model validation service, or model repository.
4. Trigger loading: When the target service processes the file, ExternalDataInfo.__init__ iterates over external_data entries and calls setattr(self, entry.key, entry.value) without validation, applying the attacker-controlled keys and values.
5. Achieve impact: For DoS, the system attempts to allocate the specified petabyte-scale memory when reading external data, causing an Out-of-Memory crash. For object corruption, dunder attributes overwrite Python internals, potentially enabling type confusion for further exploitation (Github Advisory, Fix PR).

• Logs: Application logs showing MemoryError or Out-of-Memory (OOM) kill signals immediately after loading an ONNX model file; Python OSError exceptions related to file.seek() with negative offsets during model loading.
• Process Behavior: Sudden spike in memory consumption by the ONNX model-loading process, followed by process termination or system-level OOM killer activation; unexpected ValueError or OSError tracebacks in ONNX-consuming services (on patched versions, these indicate attempted exploitation).
• File System: Presence of unexpected or externally sourced .onnx files with unusually large declared length values in their external_data metadata, or files containing non-standard keys (e.g., __class__, __dict__) in TensorProto.external_data fields.
• Network: Unusual uploads of ONNX model files to inference or model-serving endpoints, particularly from untrusted or anonymous sources.

The primary remediation is to upgrade ONNX to version 1.21.0 or later, which introduces a three-layer defense: (1) a strict key allowlist (location, offset, length, checksum, basepath) blocking arbitrary attribute injection; (2) parse-time validation rejecting negative or non-numeric offset/length values; and (3) file-size validation at read time preventing memory exhaustion regardless of how the model was constructed (Fix PR, Github Advisory). For systems that cannot be immediately patched, implement strict validation and sanitization of ONNX model files before loading, restrict network access to ONNX model processing services, and monitor for abnormal resource consumption patterns. Avoid loading ONNX models from untrusted sources until the patch is applied.

The vulnerability was reported by security researcher ZeroXJacks and disclosed via the ONNX GitHub security advisory program. The ONNX maintainers responded promptly, merging the fix (PR #7751) on March 18, 2026, ahead of the public disclosure on April 1, 2026, and including it in the 1.21.0 milestone release. Red Hat tracked the issue via Bugzilla (Bug 2453930) and classified it as medium severity for their products. Social media activity was limited, with mentions on Bluesky and Mastodon from automated CVE tracking accounts (Github Advisory, Red Hat Bugzilla).