DEV Community

CVE Reports
CVE Reports

Posted on • Originally published at cvereports.com

GHSA-XHJ4-G6W8-2XJW: CVE-2026-33524: Unbounded Memory Allocation in go-zserio

#security #cve #cybersecurity

CVE-2026-33524: Unbounded Memory Allocation in go-zserio

Vulnerability ID: GHSA-XHJ4-G6W8-2XJW
CVSS Score: 7.5
Published: 2026-04-24

The go-zserio library suffers from an Unbounded Memory Allocation vulnerability (CWE-770) during the deserialization of structured data. An unauthenticated remote attacker can trigger an immediate Out-of-Memory (OOM) crash by sending a crafted payload with a forged length field, resulting in a Denial of Service (DoS).

TL;DR

A critical flaw in go-zserio allows attackers to trigger massive memory allocations via forged length fields in incoming network payloads. This causes immediate Out-of-Memory crashes and Denial of Service. The vulnerability is patched by introducing bounded, incremental memory allocation.

⚠️ Exploit Status: POC

Technical Details

  • Vulnerability Class: Unbounded Memory Allocation
  • CWE ID: CWE-770
  • Attack Vector: Network
  • CVSS v3.1 Score: 7.5
  • Impact: Denial of Service (Availability)
  • Privileges Required: None
  • Patch Status: Patched

Affected Systems

  • github.com/woven-by-toyota/go-zserio
  • go-zserio: < commit 39ef1decde7e9766207794d396018776b33c6e45 (Fixed in: commit 39ef1decde7e9766207794d396018776b33c6e45)

Code Analysis

Commit: 39ef1de

Implement bounded memory allocation using io.LimitReader and capacity limits for array initialization.

Mitigation Strategies

  • Upgrade go-zserio dependency to a patched version incorporating commit 39ef1decde7e9766207794d396018776b33c6e45.
  • Tune environment variables ZSERIO_MAX_INITIAL_ARRAY_SIZE and ZSERIO_MAX_INITIAL_BLOB_SIZE to the minimum required values for legitimate payloads.
  • Implement strict payload size limits at the network edge (WAF/API Gateway).

Remediation Steps:

  1. Identify all projects depending on github.com/woven-by-toyota/go-zserio.
  2. Update the go.mod file to require the patched version of the module.
  3. Run go mod tidy and go test to ensure compatibility with the new bounded limits.
  4. Deploy the updated application to all environments.
  5. Configure operating system limits to restrict maximum memory per process, preventing system-wide OOM cascades.

References

Read the full report for GHSA-XHJ4-G6W8-2XJW on our website for more details including interactive diagrams and full exploit analysis.

Top comments (0)