CVE-2026-46385: iskorotkov/avro CPU exhaustion in array and map decoders

CVE-2026-46385 · Severity: high · CVSS 7.5 · Published 2026-05-29

The iskorotkov/avro library, a high-performance Go-based tool for processing Avro data, is vulnerable to a denial-of-service attack. An attacker can send a specially crafted data payload that causes the library to enter an extremely long processing loop, effectively freezing the application and consuming 100% of a CPU core. This can lead to service outages or system crashes if multiple malicious requests are processed simultaneously.

Technologies: github.com/hamba/avro/v2 (Go), github.com/iskorotkov/avro/v2 (Go), Hamba Avro/V2. Vendors: Go, Hamba.

Quick answers

Is CVE-2026-46385 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-46385 being exploited in the wild.
How severe is CVE-2026-46385?
High severity, with a CVSS score of 7.5, published 29 May 2026.
Which products and versions are affected?
github.com/hamba/avro/v2 (Go) SEMVER:introduced=0; github.com/iskorotkov/avro/v2 (Go) < 2.33.0, SEMVER:introduced=0,fixed=2.33.0; Hamba Avro/V2 < 2.33.0.
Is there a fix for CVE-2026-46385?
Yes. github.com/iskorotkov/avro/v2 (Go): upgrade to 2.33.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-46385 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-46385?
Check whether you run github.com/hamba/avro/v2 (Go), github.com/iskorotkov/avro/v2 (Go) or Hamba Avro/V2 at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • github.com/iskorotkov/avro/v2 (Go): upgrade to 2.33.0 or later
    go get github.com/iskorotkov/avro/v2@v2.33.0

Technical details

The vulnerability exists in the Avro array and map decoders within `codec_skip.go` and `reader_generic.go`. When decoding blocks, the library reads an attacker-controlled block-count value (up to math.MaxInt64) and iterates that many times. If the underlying reader encounters an error (such as EOF from a truncated payload), the inner decoder short-circuits, but the outer loop continues to iterate without checking the reader's error state. On 64-bit systems, this results in up to 9.2 quintillion no-op iterations, pinning a CPU core indefinitely. The issue is fixed in version 2.33.0 by adding an error check inside the loop body to terminate execution immediately upon the first inner-decode failure.

Affected products

  • iskorotkov avro/v2 < 2.33.0
  • hamba avro/v2 <= 2.31.0

Identifiers

  • CVE-2026-46385
  • GHSA-w8j3-pq8g-8m7w
  • GO-2026-5046

Timeline

  • 2026-05-11: advisory: GitHub Security Advisory published by iskorotkov
  • 2026-05-29: disclosed: CVE-2026-46385 published to NVD

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.