CVE-2016-3092

What it actually does

The MultipartStream parser in Apache Commons Fileupload accepts an attacker-supplied boundary string of arbitrary length and performs expensive linear-time processing on it, resulting in sustained high CPU consumption and denial of service.

Why it matters to the business

Web applications and servers that accept multipart uploads become unresponsive or experience severe performance degradation, disrupting service availability for legitimate users until the malicious traffic stops.

How an attack unfolds

An attacker locates any HTTP endpoint that processes multipart/form-data requests, crafts a single request whose Content-Type header contains an extremely long boundary value, and sends it to the server; the vulnerable parser loops over the boundary repeatedly, consuming CPU until the request completes or times out.

How to fix it

Upgrade Apache Commons Fileupload to version 1.3.2 or later; if using Apache Tomcat, upgrade to 7.0.70+, 8.0.36+, 8.5.3+, or 9.0.0.M7+. Where immediate patching is impossible, place a web application firewall rule that rejects or truncates Content-Type headers whose boundary parameter exceeds a few hundred characters.

How to confirm the fix worked

Inventory deployed versions of commons-fileupload.jar and Tomcat; confirm the library version is 1.3.2 or newer; optionally replay a long-boundary test request in a lab environment and verify that CPU usage remains within expected bounds.

Typical attack path

1. Scan for publicly reachable endpoints that accept file uploads or multipart POSTs
2. Send a test request with a moderately long boundary to confirm the parser is reachable
3. Transmit a single request containing a boundary string thousands of characters long
4. Observe sustained high CPU usage on the target process and repeat as needed to maintain denial of service

How to detect it

Review web server access logs for multipart Content-Type headers containing unusually long boundary values; correlate with process CPU or thread-dump spikes in Tomcat worker threads; examine any WAF or load-balancer logs for rejected oversized headers after mitigation is applied.

• Content-Type: multipart/form-data; boundary= followed by several thousand characters
• High CPU consumption in org.apache.commons.fileupload.MultipartStream
• Repeated requests from the same source IP containing boundary strings longer than 1024 bytes

What your security team should do

• Prioritize patching of any internet-facing Tomcat or Fileupload instances within 30 days
• Add boundary-length validation at the WAF or reverse-proxy layer as a compensating control
• Monitor CPU and request-processing latency metrics for sudden spikes correlated with multipart requests