CVE-2023-45290: Multipart Form Parsing DoS Vulnerability

CVE-2023-45290 Overview

CVE-2023-45290 is a memory exhaustion vulnerability in Go's net/http package affecting multipart form parsing. When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion and denial of service.

Critical Impact

This vulnerability allows remote attackers to cause denial of service by sending specially crafted multipart form data with extremely long lines, bypassing form size limits and exhausting server memory.

Affected Products

• Go programming language (net/http package)
• Applications using Request.ParseMultipartForm
• Applications using Request.FormValue, Request.PostFormValue, or Request.FormFile

Discovery Timeline

• 2024-03-05 - CVE CVE-2023-45290 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-45290

Vulnerability Analysis

This vulnerability (classified as CWE-770: Allocation of Resources Without Limits or Throttling) exists in Go's multipart form parsing implementation within the net/http package. The core issue is that while Go implemented limits on the total size of parsed forms, these limits were not enforced when reading individual form lines during the parsing process.

When a multipart form is parsed, the parser reads data line by line to process form boundaries, headers, and content. An attacker can exploit this by crafting a malicious multipart form request containing extremely long lines. Since the per-line memory allocation was not subject to the overall form size limits, each long line causes unbounded memory allocation, quickly exhausting available server memory.

The vulnerability can be triggered through multiple entry points: direct calls to Request.ParseMultipartForm, or indirect parsing through Request.FormValue, Request.PostFormValue, and Request.FormFile methods that automatically parse form data when needed.

Root Cause

The root cause lies in the incomplete enforcement of memory limits during multipart form parsing. While the ParseMultipartForm function accepted a maxMemory parameter intended to limit memory consumption, this limit was only applied to the accumulated form data, not to the buffer used for reading individual lines. The line-reading buffer could grow without restriction when processing maliciously crafted input with very long lines, creating a memory exhaustion condition that bypasses the intended protections.

Attack Vector

The attack is network-based and requires low privilege to execute. An attacker sends an HTTP request with a multipart form body containing extremely long lines. The vulnerable parsing code allocates memory proportional to the line length without checking against configured limits. By repeatedly sending such requests or using a single request with multiple long lines, the attacker can exhaust server memory, causing denial of service.

The attack does not require user interaction and can be performed by any entity capable of sending HTTP requests to the vulnerable application. Web applications that accept file uploads or form submissions are particularly at risk.

Detection Methods for CVE-2023-45290

Indicators of Compromise

• Abnormally large HTTP request bodies containing multipart form data
• Sudden memory consumption spikes in Go-based web applications
• Out-of-memory errors or application crashes during form processing
• HTTP requests with unusually long lines in multipart boundaries or content

Detection Strategies

• Monitor Go application memory usage patterns for unexpected growth during HTTP request processing
• Implement request size logging at the web server or load balancer level to identify abnormally large multipart requests
• Deploy application performance monitoring (APM) to track memory allocation during form parsing operations
• Review Go runtime metrics for garbage collection pressure and heap growth anomalies

Monitoring Recommendations

• Configure alerting on memory utilization thresholds for Go-based services handling multipart forms
• Implement rate limiting on endpoints that accept multipart form data
• Monitor HTTP request sizes at ingress points (reverse proxy, load balancer)
• Track application restart frequency as a potential indicator of memory exhaustion crashes

How to Mitigate CVE-2023-45290

Immediate Actions Required

• Update Go to the latest patched version that includes the fix for this vulnerability
• Review all applications using Go's net/http package for multipart form handling
• Implement request size limits at the reverse proxy or load balancer level as defense in depth
• Consider temporarily disabling or limiting access to form upload endpoints until patching is complete

Patch Information

The Go team has released a fix that correctly limits the maximum size of form lines in the ParseMultipartForm function. The patch is tracked in Go.dev Change List CL 569341. Additional details are available in the Go.dev Issue Tracker and the official Go.dev Vulnerability Report GO-2024-2599. NetApp has also released a Security Advisory for affected products.

Workarounds

• Implement request body size limits at the reverse proxy or web server level (e.g., nginx client_max_body_size)
• Add middleware to reject requests with excessively long Content-Length headers before they reach the Go application
• Deploy rate limiting on endpoints accepting multipart form data to reduce the impact of exploitation attempts
• Consider using a WAF rule to inspect and reject malformed multipart requests with abnormally long lines

# Example nginx configuration to limit request body size
# Add to server or location block
client_max_body_size 10M;
client_body_buffer_size 128k;

# Example rate limiting for form endpoints
limit_req_zone $binary_remote_addr zone=form_limit:10m rate=10r/s;
location /upload {
    limit_req zone=form_limit burst=20 nodelay;
    proxy_pass http://go_backend;
}