github.com/iskorotkov/avro/v2
A fast Go Avro codec
View on Github
Activity
- Latest release
- 2d ago
- Total releases
- 22
- Cadence
- ~15 days
- Last 12 months
- 6
Reach
- Stars
- 20
Details
- First release
- Mar 08, 2024
| Version | Released | |
|---|---|---|
v2.35.0
minor
|
v2.35.0
minor
Dependencies (7)
|
|
v2.34.0
minor
|
v2.34.0
minor
Dependencies (8)
|
|
v2.33.1
patch
|
v2.33.1
patch
Dependencies (8)
|
|
v2.33.0
minor
|
v2.33.0
minor
Dependencies (8)
|
|
v2.32.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.32.0
minor
Dependencies (8)
|
|
v2.31.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.31.0
minor
Dependencies (8)
|
|
v2.30.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.30.0
minor
Dependencies (8)
|
|
v2.29.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.29.0
minor
Dependencies (8)
|
|
v2.28.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.28.0
minor
Dependencies (8)
|
|
v2.27.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.27.0
minor
Dependencies (8)
|
|
v2.26.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.26.0
minor
Dependencies (8)
|
|
v2.25.2
patch
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.25.2
patch
Dependencies (8)
|
|
v2.25.1
patch
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.25.1
patch
Dependencies (8)
|
|
v2.25.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.25.0
minor
Dependencies (8)
|
|
v2.24.1
patch
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.24.1
patch
Dependencies (8)
|
|
v2.24.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.24.0
minor
Dependencies (8)
|
|
v2.23.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.23.0
minor
Dependencies (8)
|
|
v2.22.1
patch
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.22.1
patch
Dependencies (8)
|
|
v2.22.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.22.0
minor
Dependencies (8)
|
|
v2.21.1
patch
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.21.1
patch
Dependencies (7)
|
|
v2.21.0
minor
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.21.0
minor
Dependencies (7)
|
|
v2.20.1
initial
3 CVEs
CVE-2026-46384
GO-2026-5047
GHSA-mc57-h6j3-3hmv
Jul 27, 2026
Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
GO-2026-5048
GHSA-mx64-mj3q-7prj
Jul 27, 2026
Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires. The fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev
CVE-2026-46385
GO-2026-5046
GHSA-w8j3-pq8g-8m7w
Jul 27, 2026
CPU exhaustion in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2 The Avro array and map decoders loop over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 and arm64 targets. A producer can declare a block of up to math.MaxInt64 elements followed by EOF or any truncated payload, and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is indefinite until the worker is killed externally. A single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated, resulting in a remote, unauthenticated denial-of-service. The fix exits the loop on the first inner-decode error. Fixed in
2.33.0
References Updated Aug 05, 2026 · Source: OSV.dev |
v2.20.1
initial
Dependencies (7)
|