CVE-2025-29908: Netty QUIC Codec Hash DoS Vulnerability

CVE-2025-29908 Overview

A hash collision vulnerability has been identified in the Netty QUIC codec, a QUIC codec for Netty that leverages the quiche library. The vulnerability exists in the hash map implementation used to manage QUIC connections, allowing remote attackers to cause significant CPU load on affected servers through a Hash DoS (Denial of Service) attack. By initiating connections with deliberately crafted colliding Source Connection IDs (SCIDs), an attacker can exploit the algorithmic complexity of hash table operations to degrade server performance.

Critical Impact

Remote attackers can cause significant CPU exhaustion on servers running vulnerable Netty QUIC codec versions by exploiting hash collisions in connection management, potentially leading to service degradation or unavailability.

Affected Products

• Netty QUIC Codec (netty-incubator-codec-quic) versions prior to 0.0.71.Final
• Applications and services utilizing the vulnerable Netty QUIC codec for QUIC protocol handling
• Java-based network applications implementing QUIC via Netty's incubator codec

Discovery Timeline

• 2025-03-31 - CVE-2025-29908 published to NVD
• 2025-04-01 - Last updated in NVD database

Technical Details for CVE-2025-29908

Vulnerability Analysis

This vulnerability represents an Algorithmic Complexity Attack targeting the connection management subsystem of the Netty QUIC codec. The QUIC protocol uses Source Connection IDs (SCIDs) to uniquely identify connections, and the codec stores these in a hash map data structure. When an attacker crafts multiple connection requests with SCIDs that produce hash collisions, the hash map degrades from O(1) average-case lookup to O(n) worst-case performance for each operation.

The attack requires only network access with no authentication, making it trivially exploitable from remote locations. While the vulnerability does not compromise data confidentiality or integrity, it can significantly impact service availability by monopolizing CPU resources on the target server.

Root Cause

The root cause lies in the use of a standard HashMap implementation for managing QUIC connections without adequate protection against hash collision attacks. The original implementation relied on Java's default hashing mechanism for connection ID storage, which is predictable and can be targeted by attackers who understand the hash function characteristics.

The vulnerable code path existed in the connection channel mapping logic within io.netty.incubator.codec.quic.QuicheQuicCodec, where incoming connections were tracked using a susceptible hash structure.

Attack Vector

The attack is network-based and can be executed remotely without authentication. An attacker initiates multiple QUIC connections to the target server, each with a carefully selected Source Connection ID designed to collide with others in the hash table. As the number of colliding entries grows, hash table operations become increasingly expensive, consuming excessive CPU cycles.

The attack is particularly effective because:

1. QUIC connection initiation is lightweight for the attacker
2. The server must process each connection request
3. Hash collision resolution overhead compounds with each colliding entry

/*
 * Copyright 2025 The Netty Project
 *
 * The Netty Project licenses this file to you under the Apache License,
 * version 2.0 (the "License"); you may not use this file except in compliance
 * with the License. You may obtain a copy of the License at:
 *
 *   https://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 * License for the specific language governing permissions and limitations
 * under the License.
 */
package io.netty.incubator.codec.quic;

import org.jetbrains.annotations.NotNull;
import org.jetbrains.annotations.Nullable;

import java.nio.ByteBuffer;
import java.security.SecureRandom;
import java.util.HashMap;
import java.util.Map;
import java.util.Objects;

/**
 * We use a custom hash that uses SipHash 1-3 to prevent
 * <a href="https://github.com/ncc-pbottine/QUIC-Hash-Dos-Advisory">Hash Denial-of-Service Attacks</a>.
 */

Source: GitHub Commit e059bd9b

The patch introduces a new ConnectionIdChannelMap class that implements SipHash 1-3, a cryptographically secure hash function with randomized keys, preventing attackers from predicting hash outputs and engineering collisions.

Detection Methods for CVE-2025-29908

Indicators of Compromise

• Unusual CPU utilization spikes on servers running QUIC services without corresponding increase in legitimate traffic
• High volume of QUIC connection initiations from single or distributed sources with abnormal connection ID patterns
• Degraded response times for QUIC-based services coinciding with connection storms
• Memory growth in hash map structures within the Netty QUIC codec

Detection Strategies

• Monitor server CPU utilization and correlate with QUIC connection rates to identify anomalous patterns
• Implement network-level monitoring to detect high volumes of QUIC Initial packets from suspicious sources
• Deploy application performance monitoring (APM) to track Netty codec performance metrics and hash map operations
• Analyze QUIC connection logs for patterns of rapidly initiated and abandoned connections

Monitoring Recommendations

• Configure alerting thresholds for CPU usage on QUIC-serving applications with automatic escalation
• Implement rate limiting on QUIC connection initiation at the network perimeter
• Deploy SentinelOne Singularity to monitor for anomalous process behavior and resource consumption patterns
• Enable detailed logging of connection management operations during incident investigation

How to Mitigate CVE-2025-29908

Immediate Actions Required

• Upgrade Netty QUIC codec to version 0.0.71.Final or later immediately
• Audit all applications and services for usage of netty-incubator-codec-quic and schedule updates
• Implement network-level rate limiting for QUIC traffic as a temporary protective measure
• Monitor affected systems closely for signs of exploitation during the patching window

Patch Information

The vulnerability is fixed in Netty QUIC codec version 0.0.71.Final. The patch replaces the vulnerable standard HashMap implementation with a custom ConnectionIdChannelMap that uses SipHash 1-3 with randomly generated keys. This cryptographic hash function prevents attackers from predicting hash outputs and engineering collisions.

For detailed patch information, refer to the GitHub Security Advisory GHSA-hqqc-jr88-p6x2 and the security commit.

Workarounds

• Deploy network-level rate limiting on UDP port 443 (or configured QUIC ports) to limit connection initiation rates
• Implement firewall rules to restrict QUIC access to trusted IP ranges where feasible
• Consider temporarily disabling QUIC and falling back to TCP/TLS for critical services until patching is complete
• Deploy a reverse proxy or load balancer with QUIC DoS protection capabilities in front of vulnerable services

# Example: Rate limit QUIC traffic using iptables (Linux)
# Limit new UDP connections on QUIC port to 100/second per source IP
iptables -A INPUT -p udp --dport 443 -m state --state NEW -m recent --set
iptables -A INPUT -p udp --dport 443 -m state --state NEW -m recent --update --seconds 1 --hitcount 100 -j DROP

# Example: Maven dependency update to patched version
# Update pom.xml to use fixed version
# <dependency>
#     <groupId>io.netty.incubator</groupId>
#     <artifactId>netty-incubator-codec-quic</artifactId>
#     <version>0.0.71.Final</version>
# </dependency>