CVE-2024-24791: net/http HTTP/1.1 Client DoS Vulnerability

CVE-2024-24791 Overview

CVE-2024-24791 is a denial of service vulnerability in Go's net/http HTTP/1.1 client that affects how the client handles server responses to requests containing the Expect: 100-continue header. When a server responds with a non-informational status code (200 or higher) instead of the expected 100 Continue response, the client mishandles this scenario, leaving the connection in an invalid state. Subsequent requests on the affected connection will fail, enabling attackers to disrupt service availability.

Critical Impact
Attackers can exploit this vulnerability to cause denial of service against applications using Go's net/http/httputil.ReverseProxy by sending crafted requests that trigger connection invalidation, causing cascading failures for legitimate traffic.

Affected Products

Go net/http package (HTTP/1.1 client)
Go net/http/httputil.ReverseProxy
Applications and services built with affected Go versions

Discovery Timeline

2024-07-02 - CVE-2024-24791 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-24791

Vulnerability Analysis

The vulnerability exists in Go's net/http HTTP/1.1 client implementation, specifically in how it processes server responses to requests that include the Expect: 100-continue header. The HTTP/1.1 protocol defines that when a client sends a request with this header, the server should respond with a 100 Continue informational response before the client sends the request body, or respond with a final status code to reject the request early.

Go's HTTP client implementation fails to properly handle the case where a server responds with a non-informational status code (200 or higher) to such requests. This mishandling corrupts the internal state of the HTTP connection, making it invalid for subsequent use. When the connection is reused for another request, that request will fail due to the corrupted connection state.

This vulnerability is particularly impactful when exploited against net/http/httputil.ReverseProxy, a commonly used component for building API gateways, load balancers, and reverse proxy servers. An attacker can repeatedly send requests with Expect: 100-continue headers, and if the backend server responds with non-informational status codes, each such request poisons one connection in the proxy's connection pool.

Root Cause

The root cause lies in improper state management within the HTTP/1.1 client's connection handling logic. When the client sends a request with an Expect: 100-continue header, it enters a state waiting for either a 100 Continue response or a final response. However, when the server sends a non-informational response directly, the client's internal state machine fails to properly reset the connection state, leaving residual state that interferes with subsequent request processing on the same connection.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

Identifying a target application using Go's ReverseProxy or similar HTTP client functionality
Sending HTTP requests with the Expect: 100-continue header to the proxy
Ensuring the backend server responds with a non-informational status code (e.g., 200, 400, 500)
Each successful exploitation corrupts one connection, causing the next legitimate request on that connection to fail

The attack can be sustained to continuously degrade service availability by systematically poisoning connections in the proxy's connection pool.

Detection Methods for CVE-2024-24791

Indicators of Compromise

Unusual volume of HTTP requests containing Expect: 100-continue headers from single sources
Increased connection errors or request failures on reverse proxy servers
Pattern of connections being prematurely terminated or reset after specific requests
Backend server logs showing non-informational responses to requests with Expect headers

Detection Strategies

Monitor HTTP traffic for abnormal patterns of Expect: 100-continue headers, particularly from untrusted sources
Implement logging and alerting for sudden increases in HTTP client connection errors
Analyze reverse proxy logs for correlation between Expect header requests and subsequent connection failures
Deploy network intrusion detection rules to flag suspicious Expect header patterns targeting proxy endpoints

Monitoring Recommendations

Enable detailed logging on Go-based HTTP proxies to capture header information and connection lifecycle events
Set up metrics collection for connection pool health, tracking invalidation rates and error frequencies
Implement baseline monitoring for normal Expect: 100-continue usage patterns to detect anomalies
Configure alerts for elevated rates of HTTP 5xx errors following patterns of Expect header requests

How to Mitigate CVE-2024-24791

Immediate Actions Required

Upgrade Go to a patched version that addresses the net/http client connection handling issue
Review applications using net/http/httputil.ReverseProxy for exposure to untrusted traffic
Consider implementing rate limiting on incoming requests with Expect: 100-continue headers
Monitor for exploitation attempts while planning upgrade rollouts

Patch Information

The Go development team has addressed this vulnerability through code changes to the net/http package. Technical details of the fix can be found in the Go.dev Code Change. The vulnerability is tracked in the Go.dev Issue Tracker and documented in the Go.dev Vulnerability Report.

Organizations using NetApp products should also review the NetApp Security Advisory for product-specific guidance.

Workarounds

Deploy a web application firewall (WAF) or reverse proxy in front of vulnerable Go applications to filter or rate-limit requests with Expect: 100-continue headers
Configure backend servers to always respond with 100 Continue to requests with this header when appropriate, reducing the likelihood of triggering the vulnerable code path
Implement connection health checks and aggressive connection recycling to limit the impact of poisoned connections
Consider disabling HTTP/1.1 connection keep-alive for high-risk endpoints as a temporary measure to prevent connection reuse

bash

# Example: Rate limiting Expect header requests using nginx
# Add to nginx configuration for proxied endpoints
limit_req_zone $binary_remote_addr zone=expect_limit:10m rate=10r/s;

location /api/ {
    # Limit requests with Expect headers
    if ($http_expect ~* "100-continue") {
        set $limit_key $binary_remote_addr;
    }
    limit_req zone=expect_limit burst=5 nodelay;
    proxy_pass http://go_backend;
}