CVE-2023-37475 Overview
CVE-2023-37475 is a denial of service vulnerability affecting the Hamba avro library, a Go language encoder/decoder implementation of the Apache Avro codec specification. The vulnerability allows attackers to trigger an unrecoverable memory exhaustion condition by passing a specially crafted string to the github.com/hamba/avro/v2.Unmarshal() function, resulting in a fatal runtime: out of memory error that can crash applications consuming Avro-encoded data.
Critical Impact
Attackers can cause complete denial of service by exploiting unbounded memory allocation during Avro deserialization, crashing Go applications that process untrusted Avro data without any possibility of recovery.
Affected Products
- Hamba avro for Go versions prior to 2.13.0
- Applications using github.com/hamba/avro/v2.Unmarshal() to process untrusted input
- Go services implementing Avro codec deserialization
Discovery Timeline
- 2023-07-17 - CVE-2023-37475 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2023-37475
Vulnerability Analysis
This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption). The fundamental issue lies in how the Hamba avro library handles slice allocation during the deserialization process. When processing Avro-encoded data through the Unmarshal() function, the library reads size information directly from the input data to determine memory allocation requirements for byte slices. An attacker who controls the input can specify arbitrarily large size values, causing the Go runtime to attempt allocation of excessive memory amounts, ultimately exhausting available system memory and triggering an unrecoverable fatal error.
The vulnerability is particularly severe because Go's runtime: out of memory panic cannot be caught or recovered using standard error handling mechanisms like recover(), meaning any exploitation attempt results in immediate and complete application termination.
Root Cause
The root cause of CVE-2023-37475 is the absence of bounds checking on size values read from input data before allocating memory for byte slices. The library trusted the size field embedded in Avro-encoded messages without validating whether the requested allocation was reasonable or within safe limits. This allowed malicious input to dictate memory allocation behavior, enabling resource exhaustion attacks.
Attack Vector
The attack vector is network-based, requiring no authentication or user interaction. An attacker can exploit this vulnerability by:
- Crafting a malicious Avro-encoded message containing a manipulated size field with an extremely large value
- Sending this payload to any service that deserializes Avro data using the vulnerable Unmarshal() function
- The library reads the malicious size value and attempts to allocate the specified amount of memory
- The Go runtime exhausts available memory and triggers a fatal, unrecoverable panic
- The target application crashes completely, achieving denial of service
The security patch introduces a maxByteSliceSize constant to limit slice allocations:
"github.com/modern-go/reflect2"
)
+const maxByteSliceSize = 1024 * 1024
+
// DefaultConfig is the default API.
var DefaultConfig = Config{}.Freeze()
Source: GitHub Commit b4a402f4
The patch also adds string handling improvements in reader.go:
"errors"
"fmt"
"io"
+ "strings"
"unsafe"
)
Source: GitHub Commit b4a402f4
Detection Methods for CVE-2023-37475
Indicators of Compromise
- Sudden application crashes with fatal error: runtime: out of memory messages in logs
- Abnormal memory consumption patterns preceding service termination
- Repeated service restarts or container OOM (Out of Memory) kills
- Unusual Avro message payloads with disproportionately small data but large declared sizes
Detection Strategies
- Monitor application logs for Go runtime fatal errors, specifically runtime: out of memory panics
- Implement memory usage monitoring with alerts for rapid consumption spikes in services processing Avro data
- Audit dependencies to identify usage of github.com/hamba/avro/v2 versions prior to 2.13.0
- Deploy network traffic analysis to detect anomalous Avro message sizes relative to payload content
Monitoring Recommendations
- Configure memory limit alerts at 80% threshold for containers and processes handling Avro deserialization
- Enable structured logging to capture correlation between incoming requests and memory allocation patterns
- Set up dependency scanning in CI/CD pipelines to flag vulnerable avro library versions
- Implement rate limiting on endpoints accepting Avro-encoded input to reduce impact of exploitation attempts
How to Mitigate CVE-2023-37475
Immediate Actions Required
- Upgrade the Hamba avro library to version 2.13.0 or later immediately
- Audit all Go applications and microservices for usage of github.com/hamba/avro/v2.Unmarshal()
- Review network exposure of services processing Avro-encoded data and restrict access where possible
- Implement container memory limits to prevent single service crashes from affecting entire hosts
Patch Information
The vulnerability has been addressed in commit b4a402f4 which introduces a maximum byte slice size configuration option. This fix is included in release version 2.13.0. The patch adds a hard limit of 1MB (1024 * 1024 bytes) as the default maximum for byte slice allocations, preventing attackers from triggering unbounded memory consumption.
For detailed patch information, refer to:
Workarounds
- There are no known workarounds for this vulnerability; upgrading to version 2.13.0 or later is required
- As a temporary measure, restrict network access to services processing Avro data to trusted sources only
- Deploy the affected services behind API gateways with request size limits and rate limiting
- Consider running vulnerable services in isolated environments with strict memory quotas to limit blast radius
# Update the Hamba avro dependency to the patched version
go get github.com/hamba/avro/v2@v2.13.0
# Verify the installed version
go list -m github.com/hamba/avro/v2
# Run go mod tidy to clean up dependencies
go mod tidy
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

