Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ONNX ConvTranspose shape inference performed an out-of-bounds read when the weight tensor had fewer than three dimensions and the model did not provide a `kernel_shape` attribute. The inference function derived an empty `effective_kernel_shape` vector from the undersized weight tensor, then indexed that vector once for each spatial dimension of the input tensor. A crafted model passed `onnx.checker.check_model()` and caused SIGSEGV when passed to `onnx.shape_inference.infer_shapes()`. Technical details For an input shape such as `[1, 1, 5]`, shape inference computes one spatial input dimension. A weight shape such as `[1, 3]` has no spatial dimensions, so deriving `kernel_shape` from dimensions 2 onward produces an empty vector. The output loop nevertheless accesses `effective_kernel_shape[0]`. The defect affected both the older `convTransposeShapeInference_opset11()` path and the then-current ConvTranspose inference implementation. Impact An application that…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ONNX's Python tensor-materialization helpers could allocate memory according to attacker-controlled tensor dimensions without verifying that a packed sub-byte payload contained the declared number of elements. A very small model could therefore cause a disproportionately large allocation when an application called `onnx.numpy_helper.to_array()` or constructed `onnx.reference.ReferenceEvaluator` with the model. The issue affected `UINT2`, `INT2`, `UINT4`, `INT4`, and `FLOAT4E2M1` tensors stored in either `raw_data` or packed `int32_data`. Technical details The vulnerable `_unpack_2bit()` and `_unpack_4bit()` paths first allocated a small array based on the available packed bytes, then resized it to the shape declared in `TensorProto.dims`. They did not first confirm that the payload encoded enough logical elements for that shape. For example, the reporter demonstrated a 66-byte model containing one packed byte and a declared dimension of 700,000,000. The model passed…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ONNX shape inference did not safely validate the required Scan `num_scan_inputs` attribute. Two malformed values could terminate or disrupt the process: 1. If the attribute was missing, `ctx.getAttribute("num_scan_inputs")` returned null and was dereferenced. 2. If the attribute was negative, conversion to `size_t` produced a very large value that reached a vector allocation and raised `std::length_error`. The negative-value variant passed `onnx.checker.check_model()` before reaching shape inference. Technical details The vulnerable Scan inference implementations used the following pattern: ```cpp auto num_scan_inputs = narrow_cast (ctx.getAttribute("num_scan_inputs")->i()); ``` This code neither checked the returned pointer nor rejected a negative signed value before converting it to an unsigned size. The pattern was present in the current Scan inference function and the older opset 8 and 9 paths. The fix uses the required-attribute helper and checked narrowing: ```cpp…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ONNX shape inference performed an out-of-bounds read when processing a malformed RNN, GRU, or LSTM node from opsets 1–6 whose first input had a rank other than three. `RNNShapeInference_opset1_to_6()` checked whether the input shape was present but accessed `dim(0)` and `dim(1)` without first checking its rank. A crafted model could therefore terminate a process that called `onnx.shape_inference.infer_shapes()`. The model passed `onnx.checker.check_model()` before reaching the vulnerable path. Technical details The vulnerable code read dimensions unconditionally: ```cpp if (hasInputShape(ctx, 0)) { const auto& first_input_shape = getInputShape(ctx, 0); seq_length = first_input_shape.dim(0); batch_size = first_input_shape.dim(1); } ``` For an undersized shape, protobuf's repeated-field access read outside the intended array in release builds. The observed result was SIGSEGV; sanitizer and debug builds terminated on a protobuf bounds check. The newer opset 7–13 and opset…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Heap-buffer-overflow READ (16 bytes) in Gemm76::adaptgemm76() (onnx/versionconverter/adapters/gemm76.h:41) when ConvertVersion() processes a model with a Gemm node whose input tensors have fewer than 2 dimensions. The adapter accesses Bshape[1] without checking rank. On Release builds the OOB read is silent; ASan confirms 16-byte read past a 48-byte allocation. Details The Gemm 7→6 downgrade adapter reads input shapes without bounds checking: The PoC has input B with shape [28] (1 dimension). Bshape has 1 element. Accessing Bshape[1] reads 16 bytes past the std::vector<Dimension internal storage into adjacent heap memory. The same unchecked pattern applies to Ashape[0] and Ashape[1] at lines 34 and 36. Entry point: onnx.versionconverter.convertversion(model, 6) — different from the InferShapes bugs reported in separate advisories. This triggers during opset downgrade (7→6). PoC 186-byte PoC. ASan confirms: heap-buffer-overflow READ of size 16 at gemm76.h:41, 0 bytes after…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Null pointer dereference (SIGSEGV) in Upsample67::adaptupsample67() (onnx/versionconverter/adapters/upsample67.h:31) when convertversion() processes a model with an Upsample node that has zero inputs. The adapter accesses node-inputs()[0]-sizes() without checking input count. 107-byte PoC crashes on Release build. This is the same class of bug as the Cast adapter advisory (separate report) but in a different adapter, different file, and different operator. Details The Upsample 6→7 adapter validates attributes but not inputs: The PoC has an Upsample node at opset 6 with the required widthscale and heightscale attributes but zero inputs. The attribute assertions pass, then node-inputs()[0] on an empty ArrayRef: - Release builds (NDEBUG): bounds-check assertion compiled out → reads garbage pointer → SIGSEGV - Debug builds: assert(Index < Length) at arrayref.h:159 → SIGABRT An Upsample node with zero inputs passes graphProtoToGraph() because the import code only resolves input…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The saveexternaldata method seems to include multiple issues introducing a local TOCTOU vulnerability, an arbitrary file read/write on any system. It potentially includes a path validation bypass on Windows systems. Regarding the TOCTOU, an attacker seems to be able to overwrite victim's files via symlink following under the same privilege scope. The mentioned function can be found here: https://github.com/onnx/onnx/blob/main/onnx/externaldatahelper.py#L188 Details Toctou The vulnerable code pattern: There is a time gap between os.path.isfile and open with no atomic file creation flags (e.g. OEXCEL | OCREAT) allowing the attacker to create a symlink that is being followed (absence of ONOFOLLOW), between these two calls. By combining these, the attack is possible as shown below in the PoC section. Bypass There is also a potential validation bypass on Windows systems in the same method (https://github.com/onnx/onnx/blob/main/onnx/externaldatahelper.py#L203) allowing absolute…
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
- Issue: Symlink traversal in external data loading allows reading files outside the model directory. - Affected code: onnx/onnx/checker.cc: resolveexternaldatalocation used via Python onnx.externaldatahelper.loadexternaldataformodel. - Impact: Arbitrary file read (confidentiality breach) when a model’s external data path resolves to a symlink targeting a file outside the model directory. Root Cause - The function resolveexternaldatalocation(basedir, location, tensorname) intends to ensure that external data files reside within basedir. It: - Rejects empty/absolute paths - Normalizes the relative path and rejects .. - Builds datapath = basedir / relativepath - Checks exists(datapath) and isregularfile(datapath) - However, std::filesystem::isregularfile(path) follows symlinks to their targets. A symlink placed inside basedir that points to a file outside basedir will pass the checks and be returned. The Python loader then opens the path and reads the target file. Code…
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The issue is in onnx.load — the code checks for symlinks to prevent path traversal, but completely misses hardlinks, which is the problem, since a hardlink looks exactly like a regular file on the filesystem. The Real Problem The validator in onnx/checker.cc only calls issymlink() and never checks the inode or stnlink, so a hardlink walks right through every security check without any issues. Impact Especially dangerous in AI supply chain scenarios like HuggingFace — a single malicious model is enough to silently steal secrets from the victim's machine without them noticing anything.
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ExternalDataInfo class in ONNX was using Python’s setattr() function to load metadata (like file paths or data lengths) directly from an ONNX model file. The problem? It didn’t check if the "keys" in the file were valid. Because it blindly trusted the file, an attacker could craft a malicious model that overwrites internal object properties. Why its Dangerous Instant Crash DoS: An attacker can set the length property to a massive number like 9 petabytes. When the system tries to load the model, it attempts to allocate all that RAM at once, causing the server to crash or freeze Out of Memory. Access Bypass: By setting a negative offset -1, an attacker can trick the system into reading parts of a file it wasn't supposed to touch. Object Corruption: Attackers can even inject "dunder" attributes like class to change the object's type entirely, which could lead to more complex exploits. Fixed: https://github.com/onnx/onnx/pull/7751 object state corruption and DoS via…
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability via symlink allows to read arbitrary files outside model or user-provided directory. Details The following check for symlink is ineffective and it is possible to point a symlink to an arbitrary location on the file system: https://github.com/onnx/onnx/blob/336652a4b2ab1e530ae02269efa7038082cef250/onnx/checker.cc#L1024-L1033 `std::filesystem::is_regular_file` performs a `status(p)` call on the provided path, which follows symbolic links to determine the file type, meaning it will return true if the target of a symlink is a regular file. PoC ```python Create a demo model with external data import os import numpy as np import onnx from onnx import helper, TensorProto, numpy_helper def create_onnx_model(output_path="model.onnx"): weight_matrix = np.random.randn(1000, 1000).astype(np.float32) X = helper.make_tensor_value_info("X", TensorProto.FLOAT, [1, 1000]) Y = helper.make_tensor_value_info("Y", TensorProto.FLOAT, [1, 1000]) W =…
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
What's the issue Passing silent=True to onnx.hub.load() kills all trust warnings and user prompts. This means a model can be downloaded from any unverified GitHub repo with zero user awareness. On top of that, the SHA256 integrity check is useless here — it validates against a manifest that lives in the same repo the attacker controls, so the hash will always match. Impact Any pipeline using hub.load() with silent=True and an external repo string is silently loading whatever the repo owner ships. If that model executes arbitrary code on load, the attacker has access to the machine. Resolved by removing the feature References - Write-up
Recommended action: Upgrade to 1.21.0rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in the downloadmodel function of the onnx/onnx framework, before and including version 1.16.1, allows for arbitrary file overwrite due to inadequate prevention of path traversal attacks in malicious tar files. This vulnerability can be exploited by an attacker to overwrite files in the user's directory, potentially leading to remote command execution.
Recommended action: Upgrade to 1.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in the downloadmodelwithtestdata function of the onnx/onnx framework, versions before 1.16.2, allow for arbitrary file overwrite due to inadequate prevention of path traversal attacks in malicious tar files. This vulnerability enables attackers to overwrite any file on the system, potentially leading to remote code execution, deletion of system, personal, or application files, thus impacting the integrity and availability of the system. The issue arises from the function's handling of tar file extraction without performing security checks on the paths within the tar file, as demonstrated by the ability to overwrite the /home/kali/.ssh/authorizedkeys file by specifying an absolute path in the malicious tar file.
Recommended action: Upgrade to 1.16.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of the package onnx before and including 1.15.0 are vulnerable to Directory Traversal as the externaldata field of the tensor proto can have a path to the file which is outside the model current directory or user-provided directory. The vulnerability occurs as a bypass for the patch added for CVE-2022-25882.
Recommended action: Upgrade to 1.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of the package onnx before and including 1.15.0 are vulnerable to Out-of-bounds Read as the ONNXASSERT and ONNXASSERTM functions have an off by one string copy.
Recommended action: Upgrade to 1.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of the package onnx before 1.13.0 are vulnerable to Directory Traversal as the externaldata field of the tensor proto can have a path to the file which is outside the model current directory or user-provided directory, for example "../../../etc/passwd"
Recommended action: Upgrade to 1.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.