Which ONNX versions are affected and what is the fix?

Per the four GitHub advisories, the onnx Python package is affected through 1.21.0 (the Scan flaw from 1.4.0, the ConvTranspose flaw from 1.2.1) and patched in 1.22.0. PyPI shows 1.22.0 uploaded on June 15, 2026, and 1.23.2 is the latest release as of October 31.

Can these flaws run attacker code?

The advisories demonstrate only crashes (three) and memory exhaustion (one). Three say no confidentiality or integrity impact was demonstrated, and the packed-tensor advisory says memory corruption and code execution were not demonstrated. That is not a claim that code execution is impossible.

Is there evidence of exploitation?

No evidence of exploitation found as of October 31, 2026 in the CISA KEV JSON feed (released 2026-10-30T17:02Z, no ONNX entries) or in the advisory texts. CISA coordinator SSVC entries in NVD list exploitation as none.

ONNX Model-File Flaws: Crashes and 700…

Four medium-severity advisories published on October 28, 2026 describe a shared pattern in the onnx Python package (our framing, since the root causes differ): a crafted model file can still crash or exhaust the process that reads it, even after passing the library’s checker in the cases the advisories describe. They are CVE-2026-115919, CVE-2026-115920, CVE-2026-115921 and CVE-2026-115922. All four are fixed in onnx 1.22.0. The advisories demonstrate only crashes (three) and memory exhaustion (one); none demonstrates code execution or data exposure.

That makes them easy to wave away. They should not be, if your service takes ONNX files from outside.

Four different ways in

The first three hit shape inference, the step that works out tensor sizes through a graph. The advisories say the crafted models for CVE-2026-115919 and CVE-2026-115920, and the negative-value variant for CVE-2026-115921, pass onnx.checker.check_model() and fail only when onnx.shape_inference.infer_shapes() runs.

CVE-2026-115919 (GHSA-48m4-24cq-37qf, CWE-125). For RNN and LSTM nodes in opsets 1 to 6 and GRU nodes in opsets 3 to 6, the inference code read dim(0) and dim(1) of the first input without checking that it had three dimensions. The advisory says release builds read outside the array and crashed with SIGSEGV. Newer opset paths already checked the rank and were not affected.

CVE-2026-115920 (GHSA-6pwm-x34p-fvj2, CWE-125). When a model gives no kernel_shape attribute, ConvTranspose inference derived an empty kernel shape from a weight tensor with fewer than three dimensions, then indexed it once per input spatial dimension. Same result: a deterministic crash. The advisory lists ONNX 1.2.1 through 1.21.0 as affected.

CVE-2026-115921 (GHSA-m4pr-6v3c-6fgr, CWE-195 and CWE-476). The Scan operator’s num_scan_inputs attribute was dereferenced without a null check, and a negative value was converted to an unsigned size, producing a huge vector allocation and an exception. The negative variant passed the checker; the advisory is silent on the missing-attribute variant. The advisory dates the flaw to 1.4.0, the first release with that implementation.

CVE-2026-115922 (GHSA-q69g-f4f5-v8m7, CWE-789). This one is different, and the most interesting. Python helpers that unpack 2-bit and 4-bit tensors (UINT2, INT2, UINT4, INT4, FLOAT4E2M1) allocated memory from the declared tensor dimensions without checking that the payload held that many elements. The reporter’s demonstration was a 66-byte model with one packed byte and a declared dimension of 700,000,000, which allocated about 700 MB when onnx.numpy_helper.to_array() materialized it, with another large allocation in ReferenceEvaluator. Loading, checking or running shape inference alone did not trigger it. The tensor had to be materialized.

Why a medium score can still matter

All four carry the same GitHub score: 6.2, CVSS 3.1, AV:L/AC:L/PR:N/UI:N, availability high and nothing else. That is GitHub’s score as CNA. NVD lists all four as Awaiting Analysis with only that secondary score, plus a CISA coordinator SSVC entry: exploitation none, automatable no, technical impact partial.

The local vector is the part to read carefully. The advisories explain it: ONNX is a library, not a network service, so the base score assumes a local file boundary. They add that applications exposing ONNX model processing over a network should calculate an environmental score with the attack vector set to network. That is the case for model-conversion services, upload-and-validate endpoints and registries that run inference or shape checks on submitted files. The previous sentence and this one are our assessment: for those, it is that a 66-byte file taking down a worker (or eating hundreds of megabytes per request) is a cheap denial of service, repeatable by anyone who can submit a model.

A crash is not a small thing in an inference pipeline either. If shape inference runs inside the same process as serving, one bad file takes the server with it.

Timing and status

PyPI shows onnx 1.22.0 uploaded on June 15, 2026. The advisories were published 135 days later, on October 28, and the latest release is 1.23.2 (October 6). Those are upload and publication dates; the advisories do not say when the maintainers received each report. NVD published all four records on October 26, two days before the GitHub date. The public fix pull requests were merged between May 4 and June 4 (#7879, #7916, #7997, #8033, #8038), roughly five months before the advisories; that is our inference from merge dates, not a statement from any source about disclosure. The GitHub advisory database also lists earlier 2026 ONNX advisories, including path traversal, external data handling, a server-crash denial of service (CVE-2026-34445), a null dereference (CVE-2026-44512) and an out-of-bounds read (CVE-2026-63632). Our reading is that model-file parsing in this package has had steady scrutiny this year.

No evidence of exploitation found as of October 31, 2026 in the CISA KEV feed (released October 30, no ONNX entries) or in the advisory texts.

What to do

Upgrade onnx to 1.22.0 or later. Since 1.23.2 is current, there is little reason to stop at the minimum; the advisories say the maintainers re-tested the original models against published 1.23.2 wheels and they now raise InferenceError. For the packed-tensor flaw, a checker change also makes check_model() on 1.22 and later reject undersized packed payloads.
Inventory where untrusted ONNX files are parsed: upload handlers, CI jobs that validate models, notebooks that pull models from hubs.
Run model parsing, shape inference and tensor materialization in a worker with memory and CPU limits, separate from your serving process, so a crash or large allocation costs one job.
Do not treat a passing check_model() as proof a file is safe to process. Per the advisories, several of the crafted files passed it.
Our suggestion: alert on worker crashes (SIGSEGV) and out-of-memory kills shortly after model uploads.

ONNX Model-File Flaws: Crashes and 700 MB Tensors in Four CVEs (CVE-2026-115919)

Four different ways in

Why a medium score can still matter

Timing and status

What to do

References

Frequently Asked Questions