CVE-2026-35480: go-ipld-prime DoS Vulnerability

CVE-2026-35480 Overview

CVE-2026-35480 is a Resource Exhaustion vulnerability in go-ipld-prime, an implementation of the InterPlanetary Linked Data (IPLD) spec interfaces. The library provides batteries-included codec implementations of IPLD for CBOR and JSON, along with tooling for basic operations on IPLD objects. Prior to version 0.22.0, the DAG-CBOR decoder uses collection sizes declared in CBOR headers as Go preallocation hints for maps and lists without properly capping these size hints or accounting for their cost in the allocation budget. This allows attackers to craft small payloads that trigger excessive memory allocation, leading to denial of service conditions.

Critical Impact

Small malicious CBOR payloads can exhaust system memory by declaring artificially large collection sizes, causing applications using go-ipld-prime to crash or become unresponsive.

Affected Products

• go-ipld-prime versions prior to 0.22.0
• Applications using DAG-CBOR decoding functionality from go-ipld-prime
• IPLD-based decentralized applications and protocols relying on vulnerable library versions

Discovery Timeline

• 2026-04-07 - CVE CVE-2026-35480 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-35480

Vulnerability Analysis

This vulnerability stems from improper handling of CBOR collection size declarations in the DAG-CBOR decoder. When parsing CBOR data, the decoder reads size hints from headers that indicate the expected number of elements in maps or lists. The Go runtime uses these hints to preallocate memory for the collections, which is normally an optimization to reduce repeated memory allocations during data structure growth.

However, the decoder fails to implement two critical safety measures: it does not cap the maximum size hint values, and it does not deduct the cost of these preallocations from its internal allocation budget. This creates a significant disparity between the actual payload size and the memory consumed during decoding.

An attacker can craft a minimal CBOR payload (potentially just a few bytes) that declares an enormous collection size. When the decoder processes this payload, it will attempt to preallocate memory based on the declared size rather than the actual content, resulting in memory exhaustion. This can cause application crashes, system instability, or denial of service for other processes on the same system.

Root Cause

The root cause is CWE-770: Allocation of Resources Without Limits or Throttling. The DAG-CBOR decoder trusts untrusted input (CBOR header size declarations) to determine memory allocation amounts without implementing proper validation or limits. The preallocation budget mechanism that was intended to prevent excessive memory usage failed to account for these size hints, creating a bypass that attackers can exploit.

Attack Vector

The attack vector is local, requiring the attacker to provide malicious CBOR data to an application that uses go-ipld-prime for decoding. This could occur through:

1. Processing user-uploaded CBOR files
2. Receiving CBOR data over network protocols that use IPLD
3. Parsing CBOR content from decentralized storage systems like IPFS
4. Any input path where untrusted CBOR data reaches the vulnerable decoder

The attack is straightforward: an attacker creates a CBOR payload with a header declaring a very large collection size (e.g., billions of elements) but containing minimal or no actual data. When the victim application attempts to decode this payload, the decoder preallocates memory based on the declared size, consuming system resources far beyond what the small payload would legitimately require.

Detection Methods for CVE-2026-35480

Indicators of Compromise

• Sudden spikes in memory consumption when processing CBOR data
• Application crashes with out-of-memory errors during IPLD operations
• Unusual process terminations in services that handle DAG-CBOR decoding
• System-wide memory pressure originating from IPLD-processing applications

Detection Strategies

• Monitor memory allocation patterns in applications using go-ipld-prime
• Implement logging around CBOR decoding operations to track resource usage
• Set up alerts for abnormal memory growth rates in relevant services
• Review application logs for decoding errors or allocation failures

Monitoring Recommendations

• Configure memory limits and alerts for containers or processes running go-ipld-prime
• Implement application-level metrics for CBOR decoding operations
• Monitor for repeated crash-restart cycles in IPLD-dependent services
• Track the ratio of input payload size to memory allocation during decoding

How to Mitigate CVE-2026-35480

Immediate Actions Required

• Upgrade go-ipld-prime to version 0.22.0 or later immediately
• Audit applications to identify all usage of DAG-CBOR decoding functionality
• Implement resource limits at the container or process level as a defense-in-depth measure
• Consider temporarily disabling CBOR decoding from untrusted sources if upgrade is not immediately possible

Patch Information

The vulnerability is fixed in go-ipld-prime version 0.22.0. The fix implements proper caps on collection size hints and correctly accounts for preallocation costs in the allocation budget. Users should update their go.mod file to require the patched version:

require github.com/ipld/go-ipld-prime v0.22.0

For additional details, see the GitHub Security Advisory.

Workarounds

• Implement input size validation before passing CBOR data to the decoder
• Set strict memory limits on processes that handle untrusted CBOR input
• Use resource isolation (containers, cgroups) to limit the impact of memory exhaustion
• Filter or proxy untrusted CBOR data through a validated intermediary service

# Configuration example - Set memory limits for Go applications
# Using environment variables or container limits

# For systemd service
# /etc/systemd/system/your-ipld-service.service
# [Service]
# MemoryLimit=512M
# MemoryMax=512M

# For Docker/container deployment
docker run --memory=512m --memory-swap=512m your-ipld-application

# For Kubernetes pod
# resources:
#   limits:
#     memory: "512Mi"