CVE-2023-24998

What it actually does

The library processes an unbounded number of multipart request parts without enforcement of FileUploadBase#setFileCountMax, allowing resource exhaustion through allocation of per-part objects and buffers until memory or CPU limits are reached.

Why it matters to the business

Applications relying on the library can be forced offline or slowed to unusability by a single remote request or short series of requests, producing unplanned downtime and support load until the service is restarted or the configuration is hardened.

How an attack unfolds

An attacker identifies a web endpoint that accepts multipart uploads backed by the vulnerable library, crafts a request containing thousands of empty or minimal parts, and transmits it; because no part-count limit is active by default, the server exhausts heap or thread resources and becomes unresponsive. The same technique can be repeated across multiple connections for amplified effect.

How to fix it

Upgrade apache/commons-fileupload to the fixed commit 1d9a750e5091b6e36aa81c2277200a4b2b5ecd8a (equivalent to release 1.5 or later) and explicitly invoke FileUploadBase#setFileCountMax with a reasonable positive integer before processing any uploads.

How to confirm the fix worked

Confirm the library version is 1.5 or newer via dependency inspection or manifest; attempt an upload with more parts than the configured FileCountMax and verify the request is rejected with an exception rather than processed; monitor heap and thread metrics under load.

Typical attack path

1. Map application endpoints accepting multipart/form-data uploads
2. Generate a single HTTP request containing a large number of parts (exceeding any implicit limits)
3. Transmit the request (optionally in a loop or from multiple sources)
4. Observe server-side resource consumption leading to denial of service

How to detect it

Inspect application and web-server logs for multipart requests containing unusually high part counts; correlate with spikes in memory or CPU usage on upload-handling threads; review any custom error logs that record part-processing exceptions.

What your security team should do

• Immediately upgrade all instances of commons-fileupload to the fixed commit or 1.5+ release
• Add explicit FileCountMax configuration in every upload-handling code path
• Review and test other file-upload limit settings (size, file count, request size) at the same time
• Add monitoring for sudden spikes in multipart part counts or memory usage