CVE-2025-48976: Apache Commons FileUpload Multipart Header Denial of Service Vulnerability
7.5
Basic Information
JavaTechnical Details
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.apache.commons:commons-fileupload2-core | maven | >= 1.0, < 1.6.0 | 1.6.0 |
| org.apache.commons:commons-fileupload2-core | maven | >= 2.0.0-M1, < 2.0.0-M4 | 2.0.0-M4 |
Vulnerability Intelligence
Miggo AI
Miggo AIRoot Cause Analysis
The vulnerability (CVE-2025-48976 / GHSA-vv7r-c36w-3prj) is a Denial of Service in Apache Commons FileUpload due to 'Allocation of resources for multipart headers with insufficient limits'. The provided commit bf68f63cfb312ef4710fb3dfb4d8e4e1665f4497 has a message 'Sort members' and shows reordering of methods within org.apache.commons.fileupload2.core.MultipartInput.Builder, including setPartHeaderSizeMax and getPartHeaderSizeMax.
While this commit doesn't show a direct logic change for enforcing header size limits (which would typically be in the header parsing code itself, likely within the MultipartInput class), the Builder is responsible for configuring the partHeaderSizeMax limit.
The identified functions are part of this configuration process:
org.apache.commons.fileupload2.core.MultipartInput.Builder.setPartHeaderSizeMax(int): Allows setting the header size limit.org.apache.commons.fileupload2.core.MultipartInput.Builder.get(): Instantiates theMultipartInputobject, passing the configuredpartHeaderSizeMaxto its constructor.
If, prior to the set of changes that this commit is part of, this configuration mechanism was flawed (e.g., the set limit was not correctly propagated, a default was insecure, or the parser ignored the configured limit), these builder methods would be involved in the pathway to the vulnerability. The vulnerability itself—excessive resource allocation—would occur in the actual header parsing logic within the MultipartInput object, which is not visible in this specific patch. The assumption is that this 'Sort members' commit was part of a larger fix that ensured these limits became effective, or that the reordering itself subtly fixed an issue with how partHeaderSizeMax was handled by the builder.
The confidence is 'medium' because the commit itself is not an explicit security fix altering parsing logic but rather a refactoring of the configuration interface. The link to the vulnerability relies on the advisory's assertion that this commit is related to the fix, implying the previous state of this configuration code was deficient in establishing proper limits for the parser.