Go Multipart DoS CVE-2023-24536: Patching and Mitigations

The Go standard library’s multipart form parser contained a deceptively simple weakness that, in April 2023, was assigned CVE-2023-24536: specially crafted multipart requests can force Go programs to burn CPU and memory at scale, creating a reliable denial‑of‑service (DoS) vector against web servers, proxies, and any service that accepts multipart/form-data uploads.

Background​

Multipart form handling is a routine part of web servers: file uploads, HTML forms, and many API clients rely on the same parsing code paths. In Go, the relevant pieces live in the standard library packages mime/multipart, net/http, and net/textproto. Because these packages are part of the standard runtime, a large surface of services — from small self‑hosted APIs to large cloud agents and vendor software built with Go — inherits any bug in those parsers.
CVE-2023-24536 is not an exotic remote‑code‑execution bug; it is a resource‑consumption problem. That class of flaws can be just as operationally devastating because they let an unauthenticated remote actor exhaust CPU, memory, or other resources simply by sending crafted inputs. The vulnerability was reported and fixed as part of the Go security updates that produced Go 1.19.8 and Go 1.20.3.

---

What went wrong (technical overview)​

At a high level, multipart parsing in Go exhibited three related shortcomings that together produced a scalable attack path:

• Under-counted memory accounting: mime/multipart.Reader.ReadForm attempted to cap the total memory used while parsing a multipart form, but its bookkeeping could undercount actual usage. That allowed large numbers of parts to be accepted even when the program expected the total footprint to remain bounded.
• GC pressure from many small allocations: even when the raw bytes of an upload were not enormous, forms composed of thousands of individual parts produce a huge number of short‑lived allocations. That pattern stresses the garbage collector and CPU in ways a single large allocation does not, and the original limits did not consider that dimension.
• Large number of transient buffers: ReadForm could create many transient buffers during parsing. The sheer count of these short buffers amplified GC and scheduling overhead, multiplying the CPU work per request.

Put together, these behaviors let an attacker craft multipart/form-data requests containing a very large number of parts — each small, but collectively expensive — and force target servers to consume disproportionate CPU and memory compared to the request size.

Affected APIs and routines​

The defect affects code paths that use:

• mime/multipart.Reader.ReadForm
• net/http request parsing that calls through to multipart (Request.FormFile, Request.FormValue, Request.ParseMultipartForm, Request.PostFormValue)
• net/textproto helper functions used by HTTP and MIME header parsing

Because these are standard library entry points, any Go program relying on the above methods was potentially exposed prior to the fixes.

---

What the Go team changed (the fixes)​

Go maintainers implemented a combination of fixes and safeguards in the releases tied to this disclosure:

• Improved memory estimation: ReadForm now estimates memory consumption more conservatively and accurately, reducing the chance of accepting many parts while underestimating the footprint.
• Hard limits with observability: The parser imposes sane defaults for multipart size and composition:
  • Forms parsed with ReadForm are limited by default to 1000 parts (this default can be adjusted via the environment variable GODEBUG=multipartmaxparts=).
  • Form parts parsed with NextPart and NextRawPart are limited to 10,000 header fields, and the total across a parsed form is also limited to 10,000 header fields (adjustable via GODEBUG=multipartmaxheaders=).
• Fewer short‑lived allocations: The implementation reduces the number of ephemeral buffers it creates during parsing, which helps reduce GC churn and CPU overhead.

These changes shipped in Go 1.19.8 and Go 1.20.3 and later. Projects and vendors building Go binaries need to adopt those releases (or downstream patches) to eliminate the vulnerability.

---

Severity and real‑world impact​

CVE-2023-24536 carries a high score in common vulnerability scoring systems (CVSS v3.x scores around 7.5), reflecting a remote, unauthenticated attack surface that yields high availability impact without requiring privileges or user interaction. The pragmatic result is the ability to turn an HTTP endpoint into a choke point: an attacker can send repeated, lightweight requests that force servers to perform expensive parsing work, eventually saturating CPU or causing out‑of‑memory conditions.
This vulnerability is especially dangerous when:

• Services accept multipart uploads from untrusted clients (file upload endpoints, webhook receivers, public APIs).
• The vulnerable Go process runs as a frontline service behind a public IP or unfiltered load balancer.
• The process lives inside a shared environment (container hosts, multi‑tenant VMs) where one pinched process can affect neighboring workloads.
• Vendor products bundle vulnerable Go runtimes; that creates a large downstream attack surface in appliances, agents, and cloud images. Enterprise advisories from vendors such as IBM and Red Hat called out the issue in product‑specific bulletins.

Note: the attack requires sending multipart/form-data content with many parts; it’s not an arbitrary HTTP header trick. That makes detection possible (see mitigation and detection below), but it also means many naïve servers are exposed because developers often rely on standard parsers without additional constraints.

---

Who discovered it and timelines​

The Go team publicly credited Jakob Ackermann (handle @das7pad) for reporting related parsing issues. The fixes and release notes were published alongside the 1.19.8 and 1.20.3 releases and announced via Go’s mailing list. Multiple downstream advisories followed in April 2023 as vendors reconciled the risk in packaged Go runtimes and the software they ship.

---

Practical mitigation and remediation steps​

If you operate Go services (or software that embeds Go runtimes), take the following steps without delay:

1. Upgrade Go:
   1. Update your build environments and CI images to at least Go 1.19.8 or Go 1.20.3 (or a later, supported release that incorporates the fixes).
   2. Rebuild and redeploy binaries — remember that Go binaries include the standard library at build time, so updating the runtime on the developer/CI side is required to purge the vulnerable code from shipped artifacts.
2. For packaged distributions, apply vendor patches:
   • If you rely on OS packages (distribution Go packages or vendor snapshots), upgrade the OS packages or apply vendor security updates provided by your distribution vendor (Red Hat, Debian, Ubuntu, etc.). Many vendors published advisories and patches after the Go releases.
3. Add application‑level protections:
   • Enforce per‑request limits at the reverse proxy or web server layer (max request size, body size limits, per‑connection rate limits).
   • Use a Web Application Firewall (WAF) or upstream filter to block requests that contain suspicious multipart headers or an unusually large number of parts.
   • Validate client input and reject multipart submissions that do not match expected shapes (for example, a file upload endpoint that expects one file and a couple of metadata fields should only accept that pattern).
4. Use runtime knobs for temporary hardening:
   • The Go runtime exposes GODEBUG=multipartmaxparts= and GODEBUG=multipartmaxheaders= to tune the parser limits. These can be set to stricter values as a short‑term mitigation while you prepare upgrades, but note that global environment changes may affect legitimate workloads and should be tested before production rollout.
5. Observe and alert:
   • Instrument endpoints to count multipart parts per request.
   • Add alerts for sudden spikes in GC cycles, short‑lived allocation rates, or HTTP endpoints reporting back pressure and request timeouts.
   • Correlate such telemetry with client IPs and rate limits to detect and block abusive actors.
6. Supply‑chain diligence:
   • Track vendor advisories for all third‑party products you run. Vendors may ship Go‑based agents, CLI tools, or cloud images that embed affected Go versions. Microsoft’s public product attestations (and other vendor notices) help identify which packaged artifacts were known to include the vulnerable libraries; operators should review their SBOMs and vendor security pages if you run vendor images or appliances.

---

Detection and incident response​

If you suspect you have been targeted, prioritize:

• Identifying anomalous request patterns: repeated requests with multipart content and unusually many parts or headers are the primary indicator.
• Looking for resource exhaustion signs: process restarts, OOM kills, unexpectedly high CPU utilization concentrated in Go processes, or a surge in GC activity.
• Extracting offending requests (if traffic is logged) and analyzing them in a safe sandbox to reproduce the pattern against an instrumented test build.

If you confirm exploitation, apply network‑level rate limiting or temporary filtering on the offending endpoints while the full remediation (rebuild and redeploy) is rolled out.

---

Broader lessons for service authors and ops teams​

1. Standard libraries are attack surfaces. A vulnerability in a widely used standard library has outsized impact because it propagates to many applications transparently. Treat supplied runtimes and standard libraries as part of your security inventory.
2. Limits are multidimensional. It’s not enough to cap total bytes; modern runtimes and GC architectures mean work can be expensive even on many small allocations. Defenses should consider counts of objects, header fields, and internal allocation patterns, not just raw size.
3. Build reproducible pipelines. Because Go embeds the standard library at compile time, rebuilding with patched toolchains is the only reliable fix for many downstream products. CI/CD pipelines must make it straightforward to update compilers and rebuild artifacts when security updates appear.
4. Maintain aggressive observability. High‑cardinality or very small allocations can be invisible in coarse metrics. Track allocation rates, GC pause times, application‑level counters (e.g., multipart part counts), and request shape distributions so you can spot anomalous, expensive parsing workloads quickly.

---

Supply-chain and vendor impact​

Multiple vendors and distributions published advisories and mitigation guidance after the Go fixes. Large enterprise and distribution vendors (for example, IBM and Red Hat) incorporated the fixes into their own product advisories and packages, reflecting the reality that a vulnerable Go runtime can be embedded in many downstream products. Operators should consult vendor advisories for step‑by‑step remediation if they use vendor‑shipped binaries or images.
WindowsForum’s archive of security discussion shows sustained coverage of Go standard library DoS issues and Microsoft’s product‑level attestations for open‑source components in cloud images; those discussions are useful for understanding how large cloud vendors map vulnerable upstream components to specific product artifacts.

---

Risk assessment and decision framework​

For defenders deciding whether to prioritize this CVE, consider:

• Exposure: Is the vulnerable code reachable from untrusted networks? Public web endpoints and APIs that accept multipart uploads are high‑exposure.
• Volume: Can attackers easily reach the endpoint at scale (no upstream rate limiting or IP filtering)? High-volume attack potential increases urgency.
• Shared environments: If the vulnerable service runs in a multi‑tenant environment, the blast radius includes neighbors and host resources, raising operational impact.
• Vendor dependencies: If you run third‑party products built with Go, check vendor patch status; some vendors may require you to apply their patch bundles rather than rebuild from source.

If your exposed services meet any of the above high‑risk criteria, treat this as high priority: rebuild with patched Go versions or apply vendor security updates immediately.

---

Example hardening checklist (quick wins)​

• Rebuild any Go binaries with Go 1.19.8, 1.20.3, or later.
• Configure upstream proxies to reject requests whose Content-Type is multipart/* when uploads are not needed.
• Enforce max request body sizes on reverse proxies and load balancers.
• Add a rule to WAF policies to deny multipart requests that contain more than X separators or more than Y header lines (tuned to your normal traffic).
• Temporarily set GODEBUG=multipartmaxparts=500 if your application only ever expects a handful of parts — test this first in staging.

---

Conclusion​

CVE-2023-24536 is a textbook example of how parsing logic — not just memory safety bugs — can deliver high‑impact denial of service. The vulnerability exploited realistic, common usage patterns (multipart/form-data uploads) and relied on the interplay between bookkeeping, allocation patterns, and garbage collection pressure to magnify the cost of parsing many small parts.
The fixes are straightforward in principle — ship accurate accounting, add limits, and reduce transient allocations — and they are already incorporated in Go releases 1.19.8 and 1.20.3. But the operational burden remains: because Go links its standard library into application binaries at build time, organizations must rebuild and redeploy to be safe, and third‑party vendors must ensure their published artifacts are rebuilt with fixed runtimes.
If you run public Go services, treat this issue as a high priority: upgrade toolchains or apply vendor updates, harden your front‑end filters, and add observability to detect suspicious multipart traffic. These steps will turn an exploitable parser weakness into an operationally manageable risk.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center