CVE-2025-48976

What it actually does

CVE-2025-48976 is a denial-of-service flaw in Apache Commons FileUpload caused by insufficient limits on resource allocation while parsing multipart request headers. A remote unauthenticated attacker can send specially crafted multipart/form-data requests containing excessively large or numerous per-part headers, causing the application to consume excessive memory and/or CPU during request parsing. Applications that accept file uploads or otherwise parse multipart HTTP requests using Apache Commons FileUpload versions 1.0 through 1.5, or 2.0.0-M1 through 2.0.0-M3, are potentially affected. Successful exploitation can degrade service responsiveness or crash the affected Java process, depending on heap size, request concurrency, reverse-proxy limits, and application error handling.

Why it matters to the business

Exploitation can make upload-enabled web applications slow, unstable, or unavailable, disrupting customer-facing services, administrative portals, APIs, and business workflows that depend on multipart form submissions. The EPSS score is high at 0.67267, indicating elevated likelihood of exploitation despite the CVE not being listed in CISA KEV and not being marked as ransomware-related. Because Apache Commons FileUpload is a widely reused Java library and may be bundled transitively inside frameworks, products, and packaged applications, exposure can exist even where the library is not directly managed by application teams. Organizations should treat internet-facing upload endpoints as higher priority for remediation.

How an attack unfolds

An attacker first identifies a web endpoint that accepts multipart/form-data requests, commonly file upload, form submission, import, attachment, or API ingestion functionality. The attacker then sends crafted multipart requests where the body contains unusually large multipart header sections or a high number of multipart headers. Vulnerable versions of Apache Commons FileUpload allocate resources while parsing those headers without sufficiently restrictive limits, allowing the request itself to force memory or CPU consumption. By repeating the request, sending requests concurrently, or sustaining them over time, the attacker can exhaust application resources, trigger garbage-collection pressure, cause request worker starvation, or crash the Java process with out-of-memory errors. Activity associated with MadeYouReset-style denial-of-service campaigns should be considered relevant threat context when reviewing abnormal multipart traffic, although exploitation of this specific issue may not leave a unique artifact beyond resource-exhaustion symptoms and malformed multipart request patterns.

How to fix it

Upgrade Apache Commons FileUpload to a fixed version: 1.6 or later for the 1.x line, or 2.0.0-M4 or later for the 2.x milestone line. For source builds tracking the upstream Git repository, ensure the fix containing commit f3e030f09ac8b01b684466c793dec86eafe1e4c9 or a later release is present. For Mageia 4 packaging referenced in the input, php-smarty is listed as fixed in 3.1.21-1.mga4. Because Commons FileUpload is often transitive, review software composition analysis, dependency lockfiles, application server libraries, shaded JARs, vendor products, and container images for embedded vulnerable copies. As defense in depth, enforce strict reverse-proxy and application-layer limits on maximum request body size, multipart header size, number of parts, number of headers per part, upload duration, and concurrent upload requests. Apply rate limiting and authentication where feasible for upload endpoints, and configure JVM memory, circuit breakers, and request timeouts to fail safely under abusive multipart traffic.

How to confirm the fix worked

Confirm the deployed runtime no longer contains Apache Commons FileUpload versions 1.0 through 1.5 or 2.0.0-M1 through 2.0.0-M3. Validate using dependency scanners, SBOMs, build manifests, package inventories, container image scans, and direct inspection of deployed JARs, including shaded or vendor-bundled libraries. For Maven-based applications, verify dependency trees resolve to commons-fileupload:commons-fileupload 1.6 or later, or the relevant 2.x artifact at 2.0.0-M4 or later. After patching, perform controlled negative testing against non-production systems with oversized multipart header sections to confirm requests are rejected early with bounded memory use. Review reverse-proxy, WAF, and application configuration to ensure multipart header, body, concurrency, and timeout limits are active. Monitor production after deployment for absence of upload-related OutOfMemoryError events, abnormal JVM garbage collection, request thread exhaustion, and spikes in malformed multipart requests.

Typical attack path

1. Identify an internet-accessible application endpoint that accepts multipart/form-data requests, such as file uploads or attachment submissions.
2. Confirm the application processes multipart requests using a vulnerable Apache Commons FileUpload version or a product that embeds it.
3. Construct multipart HTTP POST requests with excessive per-part header data, unusually numerous part headers, or oversized header blocks.
4. Send the crafted requests repeatedly or concurrently to maximize memory and CPU pressure during multipart parsing.
5. Cause degraded response times, elevated JVM garbage collection, request thread exhaustion, HTTP 5xx errors, or process termination.
6. Continue or periodically repeat the traffic to maintain service disruption until rate limits, request-size controls, or patched library versions stop the attack.

How to detect it

Look for evidence of attempted or successful denial-of-service through multipart request parsing. Relevant log sources include web server access logs, reverse-proxy logs, WAF logs, load balancer logs, application logs, JVM logs, garbage-collection logs, container restart events, APM traces, and host telemetry. Hunt for spikes in HTTP POST requests with Content-Type multipart/form-data, especially to upload, attachment, import, profile image, document, media, or form-submission endpoints. Pay attention to requests with unusually large headers, abnormal Content-Length values, many repeated multipart boundaries, malformed multipart parsing errors, long request durations, client disconnects, HTTP 400/413/429/500/502/503 responses, and concentrated traffic from a small number of source IPs. On Java systems, correlate traffic bursts with OutOfMemoryError, Java heap space errors, GC overhead limit exceeded messages, high garbage-collection pause times, request thread exhaustion, pod or service restarts, and application server crash loops. Because this vulnerability is a DoS condition, there may be no persistent payload or file artifact; detection depends primarily on traffic pattern analysis and resource-exhaustion telemetry. When reviewing threat context, include searches for denial-of-service campaigns or tooling labeled MadeYouReset where those labels are present in threat intelligence, WAF, or IDS metadata.

• Content-Type: multipart/form-data
• multipart/form-data; boundary=
• Content-Disposition: form-data
• org.apache.commons.fileupload
• FileUploadException
• OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError
• GC overhead limit exceeded
• HTTP 413
• HTTP 429
• HTTP 500
• HTTP 502
• HTTP 503
• MadeYouReset

What your security team should do

• Prioritize patching internet-facing applications that accept file uploads or multipart form submissions and use Apache Commons FileUpload directly or transitively.
• Inventory all applications, containers, vendor packages, and build artifacts for vulnerable Apache Commons FileUpload versions, including shaded JARs and bundled application-server libraries.
• Upgrade to Apache Commons FileUpload 1.6 or 2.0.0-M4 or later, or consume vendor-provided fixed packages that include the upstream fix.
• Add or tighten edge controls for multipart/form-data requests, including request body size, multipart header size, number of parts, upload timeout, and per-client rate limits.
• Create detection logic for bursts of multipart POST requests with unusually large header sections, repeated malformed multipart parsing failures, and concurrent upload requests from the same source.
• Review logs and telemetry since publication for signs of resource-exhaustion attacks against upload endpoints, especially periods with elevated HTTP 5xx responses, JVM memory pressure, or application restarts.
• Ensure incident response runbooks cover denial-of-service containment actions such as temporarily disabling upload endpoints, blocking abusive IPs, enabling stricter WAF rules, and increasing edge filtering.
• Track vendor advisories for products embedding Apache Commons FileUpload, because remediation may require vendor upgrades rather than direct library replacement.