CVE-2026-46384: iskorotkov/avro Integer Overflow DoS Vulnerability—Patch to v2.33.0

Technical summary

The vulnerability encompasses multiple integer-handling flaws in Avro decoding paths. On 32-bit architectures (GOARCH=386, arm, mips, wasm), 64-bit wire-format values are truncated to platform-sized int before bounds-checking, allowing attackers to bypass byte-slice length limits, select incorrect union branches, or trigger OCF (Object Container Format) negative-make panics. Additionally, three platform-independent issues exist: (1) cumulative-size arithmetic in arrayDecoder.Decode, mapDecoder.Decode, and mapDecoderUnmarshaler.Decode overflows at math.MaxInt64, bypassing MaxSliceAllocSize and MaxMapAllocSize allocator caps; (2) math.MinInt negation in block-header handling; and (3) negative-size arguments passed to make([]byte, size) during OCF block reads. All three cross-platform issues cause panics or memory-allocation bypass, enabling denial-of-service on any architecture. The root cause is CWE-190 (Integer Overflow or Wraparound), where truncation and cumulative arithmetic are not properly constrained before use.

Business impact

Any application embedding iskorotkov/avro for Avro deserialization is vulnerable to remote denial-of-service attacks. If your service processes untrusted Avro payloads (e.g., from message queues, APIs, or data pipelines), a malicious actor can crash your application without authentication. This affects availability and may trigger cascading failures in dependent systems. If your deployment relies on auto-restart or load-balancing, an attacker could sustain DoS by repeatedly sending malicious payloads, consuming infrastructure resources and impacting service responsiveness.

Affected systems

All applications using iskorotkov/avro versions prior to 2.33.0 are affected. The Go runtime supports many architectures; 32-bit systems (386, arm, mips, wasm) face the most direct exploitation path via truncation tricks, while 64-bit systems (amd64, arm64) are still vulnerable via integer-overflow in cumulative size arithmetic and OCF block handling. No specific vendors or products are listed in the vulnerability record, indicating this is a community library with potentially diverse downstream users. Check your Go module dependencies for avro and verify your installed version against 2.33.0.

Exploitability

Exploitability is high. An attacker needs only network access (AV:N) and can craft a malicious Avro-encoded payload without authentication (PR:N) or user interaction (UI:N). No special conditions apply—the flaw is in the core decoding logic. Proof-of-concept crafting requires understanding of Avro wire format and Go integer semantics, but once a PoC exists, automated scanning tools could fingerprint vulnerable deployments by submitting malformed Avro data and observing application crashes or hangs. The CVSS 7.5 (HIGH) reflects the ease of exploitation and high confidence in denial-of-service outcome.

Remediation

Upgrade iskorotkov/avro to version 2.33.0 or later. This is the sole fix; no workarounds exist. If you cannot immediately patch, restrict network access to Avro-consuming endpoints, validate incoming Avro payloads against a schema whitelist, or use a rate-limiting/circuit-breaker pattern to limit the impact of repeated DoS attempts. However, these are mitigations only—patching is mandatory.

Patch guidance

In your Go project, run 'go get -u github.com/iskorotkov/[email protected]' (or later) to fetch the fixed version. Verify the upgrade with 'go mod tidy' and rebuild your application. If you are using vendored dependencies, update your vendor/ directory accordingly. After deploying the patched binary, monitor application logs for any decoding errors that may have been silently masked before; consider adding structured logging to Avro-decode error paths to catch edge cases during the transition. Test your upgrade in staging with a suite of edge-case Avro payloads to confirm stability.

Detection guidance

Monitor for repeated application crashes or panics correlated with Avro decoding. Enable structured logging in your Avro decoder (if available) to surface panics and runtime exceptions. Check Go runtime metrics (e.g., via pprof or Prometheus) for unusual goroutine exhaustion or memory allocation spikes following network input. Network-level detection is difficult without deep Avro parsing, but you can set alerts on application restart frequency or process death events when processing untrusted data. If feasible, enable Go panic recovery (defer/recover) in your application's Avro decode entry points to log panic details before the process dies, aiding forensics.

Why prioritize this

This vulnerability merits immediate patching due to its HIGH CVSS score (7.5), ease of exploitation (no auth, no user interaction, network-accessible), and 100% reliability in causing denial-of-service. Unlike memory-corruption flaws, integer-overflow DoS bugs are deterministic and can be weaponized in hours once public details emerge. Any service ingesting untrusted Avro data should patch within days, not weeks. If your application is internet-facing or processes data from external sources, prioritize this above lower-severity items.

Risk score, explained

CVSS 7.5 (HIGH) is driven by: (1) Network Attack Vector (AV:N) — no local access required; (2) Low Attack Complexity (AC:L) — no special conditions or user interaction; (3) None Privilege Required (PR:N) — anonymous attackers can trigger the flaw; (4) None User Interaction (UI:N) — the flaw is automatic upon malicious input; (5) Unchanged Scope (S:U) — the impact is confined to the affected application; (6) High Availability impact (A:H) — reliable denial-of-service is achieved. Confidentiality and Integrity are not impacted (C:N, I:N), so the score reflects DoS risk only. The severity is HIGH because DoS attacks are widely exploitable and can cascade through dependent systems.

Frequently asked questions