CVE-2024-24791

What it actually does

The vulnerability resides in Go's net/http HTTP/1.1 client, which improperly handles server responses to requests containing an 'Expect: 100-continue' header. If a server responds with a final status code (e.g., 200 OK) instead of the expected '100 Continue' informational response, the client connection is left in a corrupted, unusable state. The next request sent over this persistent connection will fail, leading to connection state desynchronization.

Why it matters to the business

This flaw can be exploited to cause a denial of service (DoS) against applications that use Go's reverse proxy functionality. An attacker can effectively poison the connection pool of a reverse proxy, causing subsequent legitimate user requests to fail. This leads to service degradation or complete unavailability, impacting user experience, damaging brand reputation, and potentially causing financial loss for services that rely on high availability.

How an attack unfolds

An unauthenticated remote attacker targets a public-facing Go application acting as a reverse proxy (using net/http/httputil.ReverseProxy). The attacker sends a specially crafted HTTP request with the header 'Expect: 100-continue'. The proxy forwards this to a backend service. If the backend responds with any status other than '100 Continue', the proxy's connection handling logic fails, leaving the connection in an invalid state but returning it to the pool. The next legitimate user whose request is assigned this poisoned connection will experience an error. By repeating this process, the attacker can exhaust the pool of valid connections, denying service to all users.

How to fix it

The vulnerability is addressed in Go versions 1.22.5 and 1.21.12. To remediate, developers must recompile affected applications using a patched version of the Go toolchain and deploy the resulting updated binaries. There is no known workaround; upgrading the Go version used for the build is the only effective mitigation.

How to confirm the fix worked

To validate the fix, verify that all relevant Go applications have been rebuilt with Go version 1.22.5, 1.21.12, or a newer version. Check build logs, CI/CD pipeline configurations, and deployed binary metadata to confirm the use of a patched toolchain. To test for exposure, a security team can run a controlled test against a non-production environment by sending a request with 'Expect: 100-continue' that elicits a non-100 response, and then verifying that subsequent requests on the same connection succeed as expected.

Typical attack path

1. An attacker identifies a target application built with Go that acts as a reverse proxy.
2. The attacker sends an HTTP request to the proxy that includes the 'Expect: 100-continue' header.
3. The proxy forwards the request to its backend service.
4. The backend service responds with a final status code (e.g., 200 OK, 404 Not Found) instead of '100 Continue'.
5. The proxy mishandles this response, corrupting the state of the underlying TCP connection.
6. The corrupted connection is returned to the proxy's connection pool for reuse.
7. A legitimate user's request is routed over the corrupted connection and fails.
8. The attacker repeats the process, poisoning more connections and escalating the denial of service.

How to detect it

Monitor logs from Go-based reverse proxies and load balancers for an unusual increase in connection errors, dropped connections, or HTTP 5xx error codes. An attack may be in progress if you observe incoming requests containing the 'Expect: 100-continue' header that are correlated with subsequent, unrelated request failures. Correlating proxy and backend application logs can help identify instances where a non-100 response to a request with an 'Expect' header is followed by connection errors.

• "Expect: 100-continue"

What your security team should do

• Identify all Go applications in your environment, particularly public-facing reverse proxies, API gateways, and load balancers, as they are the primary targets.
• Use a Software Bill of Materials (SBOM) or dependency scanner to find all applications built with vulnerable Go versions (prior to 1.22.5 and 1.21.12).
• Prioritize patching for internet-exposed services and critical internal proxies to prevent service disruption.
• Engage with development teams to ensure they upgrade their Go toolchain and redeploy all affected applications.