CVE-2023-45290

What it actually does

A flaw in Go's standard library for parsing multipart forms allows an attacker to cause uncontrolled memory allocation. By sending a request with a single, extremely long line within a form part, an attacker can bypass the total form size limit, forcing the server to allocate a massive amount of memory. This leads to memory exhaustion and a denial-of-service condition, crashing the application process.

Why it matters to the business

An attacker can render any Go-based web application that processes forms or file uploads unavailable to legitimate users. This can lead to service outages, disruption of business operations, violation of service level agreements (SLAs), and reputational damage. The vulnerability impacts service availability but does not lead to data theft.

How an attack unfolds

An attacker with the ability to send requests to a Go-based web service (e.g., a user with a low-privileged account) identifies an endpoint that accepts `multipart/form-data`, such as a file upload or a form submission page. The attacker crafts a malicious HTTP POST request containing a multipart form. Within one of the form's parts, they inject a single line of data that is exceptionally long. When the vulnerable Go application receives this request and calls an affected function like `Request.ParseMultipartForm` or `Request.FormFile`, it attempts to read the entire long line into a buffer in memory. Because the check is bypassed, the server allocates an enormous amount of memory, leading to memory exhaustion and causing the operating system's Out-Of-Memory (OOM) killer to terminate the application process, resulting in a denial of service.

How to fix it

This vulnerability is addressed in the Go standard library. Developers must update their Go development environment to a patched version (Go 1.22.1 or 1.21.8 or newer) and recompile and redeploy all Go applications. Simply updating the Go runtime is not sufficient; the application binaries themselves must be rebuilt with the fixed compiler.

How to confirm the fix worked

To validate the fix, verify that all Go applications have been recompiled using a non-vulnerable version of the Go toolchain (1.22.1+, 1.21.8+). This can be confirmed by checking build logs, CI/CD pipeline configurations, or by inspecting the Go version information embedded in the compiled binaries. To test for exposure, a security team can send a test request with a multipart form containing a very long line to a non-production instance and monitor for excessive memory consumption. A patched system will handle the request without significant memory spikes, while a vulnerable one will exhibit memory exhaustion.

Typical attack path

1. The attacker identifies a target web application built with a vulnerable version of Go that processes `multipart/form-data` requests.
2. The attacker crafts a malicious HTTP POST request containing a multipart form with an abnormally long line in one of its parts.
3. The attacker sends this request to the application's endpoint.
4. The server attempts to parse the malicious form, triggering excessive memory allocation.
5. The application server crashes due to memory exhaustion, resulting in a denial of service for all users.

How to detect it

Monitor for signs of exploitation by observing application server metrics. A sudden, sharp increase in memory usage on a Go application server, followed by a process crash or restart, is a strong indicator of an attack. Review web server and application logs for HTTP 5xx errors, out-of-memory (OOM) log entries, or other crash-related messages that correlate with incoming POST requests to endpoints that handle multipart forms. Application Performance Monitoring (APM) tools are highly effective for detecting the memory allocation anomalies characteristic of this attack.

What your security team should do

• Immediately identify all production applications built with the Go programming language.
• Coordinate with development teams to upgrade their Go toolchains to a patched version (Go 1.22.1+ or 1.21.8+) and trigger a rebuild and redeployment of all identified applications.
• Monitor application performance and memory usage for Go applications to detect anomalies that could indicate attempted or successful exploitation.