CVE-2022-41725

What it is

A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type's documentation states, "If stored on disk, the File's underlying concrete type will be an *os.File.". This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.

At a glance

Exploitability

Can be exploited over the network without logging in. High risk of service disruption.

Exploit odds

1.2% chance of exploitation in the next 30 days (EPSS).

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2023-02-28 18:15 UTC PublishedDisclosed publicly on CVE.org and NVD
2. 2026-06-17 05:03 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 1.2% in the next 30 days (EPSS).
• Severity: 7.5 HIGH (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2023-02-28 18:15 UTC

Last modified

2026-06-17 05:03 UTC

Exploit probability

1.2% · EPSS, next 30 days

Weakness

CWE-770 · Allocation without limits

Record status

Modified

Affected

• Golang Go < 1.19.6
• Golang Go 1.20.0

Attack profile CVSS 3.1 · 7.5

Attack vector

Network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2022-41725.md and follow it. Check whether this project is affected by CVE-2022-41725. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge