Avro/V2 — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/avro/v2/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioMon, 18 May 2026 13:02:19 +0000Avro Map Decoder Vulnerable to Denial-of-Service via Unbounded Memory Allocationhttps://feed.craftedsignal.io/briefs/2026-05-avro-map-dos/Mon, 18 May 2026 13:02:19 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-avro-map-dos/The Avro map decoder accepted attacker-controlled block-element counts, leading to unbounded map growth and potential denial-of-service via memory exhaustion; upgrading to v2.33.0 requires explicit configuration of MaxMapAllocSize to mitigate the vulnerability.The Avro map decoder in iskorotkov/avro/v2 prior to version 2.33.0 is vulnerable to a denial-of-service attack due to unbounded memory allocation. The decoder processes attacker-controlled block-element counts from the wire format without enforcing an upper bound on the map size. This allows a malicious producer to declare an arbitrarily large map, either in a single block or chunked across multiple blocks, leading to excessive memory consumption and potentially crashing the application due to out-of-memory errors. The vulnerability exists because the map decoder lacked the Config.MaxMapAllocSize limit that was present in the slice decoder to prevent similar attacks against arrays. To mitigate this, version 2.33.0 introduces Config.MaxMapAllocSize, but it’s opt-in, requiring explicit configuration to activate the limit.

Attack Chain

  1. Attacker crafts a malicious Avro payload with an extremely large map size declaration.
  2. The payload is sent to a vulnerable Avro decoder instance.
  3. The decoder reads the initial block header, which specifies a large element count.
  4. Without MaxMapAllocSize configured, the decoder attempts to allocate memory for the map based on the attacker-controlled size.
  5. If the initial block isn’t large enough to exhaust memory, the attacker splits the large map into smaller blocks, each declaring element counts below a per-block threshold.
  6. The decoder reads subsequent block headers and continues allocating memory, growing the map incrementally.
  7. The cumulative memory allocation exceeds available resources.
  8. The application crashes due to an out-of-memory (OOM) error, resulting in a denial-of-service.

Impact

Successful exploitation of this vulnerability can lead to a denial-of-service condition. The affected service becomes unavailable, impacting all users. The severity depends on the resources allocated to the affected service and the size of the map specified in the malicious payload. If not properly configured, applications using affected versions of the Avro decoder are susceptible to memory exhaustion, potentially leading to service outages.

Recommendation

  • Upgrade to github.com/iskorotkov/avro/v2 version 2.33.0 or later and explicitly set a non-zero value for Config.MaxMapAllocSize based on your schema’s requirements as described in the mitigation section.
  • If using github.com/hamba/avro/v2, migrate to github.com/iskorotkov/avro/v2 >= v2.33.0 and configure MaxMapAllocSize due to the archived nature of the original module.
  • Deploy the Sigma rule “Detect Avro Decoder Unbounded Map Allocation Attempt” to monitor for unusually large map allocation attempts in Avro decoding processes.
  • Implement resource constraints, such as memory limits within child processes or cgroups, to contain potential OOM errors if immediate upgrades are not feasible.
  • Reject inputs from untrusted sources lacking resource controls to prevent potential exploitation attempts.
]]>mediumadvisorydenial-of-servicememory-exhaustionavrodata-serialization