Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in…

CVE-2025-48976 is a resource-exhaustion denial-of-service in Apache Commons FileUpload, the de-facto multipart/form-data parsing library for the Java ecosystem. The flaw is dead simple: the library hard-coded a 10 KB ceiling on per-part header sizes but imposed no limit on the number of parts or the number of headers per part. An attacker sends a single HTTP POST with thousands of parts, each carrying dozens of custom headers, and the server allocates memory for all of them until the JVM stalls. Affected versions span commons-fileupload 1.0 through 1.5.x and commons-fileupload2-core 2.0.0-M1 through 2.0.0-M3. Because Apache Tomcat bundles its own copy of this code, Tomcat 9.0.0.M1–9.0.105, 10.1.0.M1–10.1.41, and 11.0.0.M1–11.0.7 are independently affected under the sibling CVE-2025-48988.

The vendor's HIGH / 7.5 rating is honest and well-calibrated. This is unauthenticated, low-complexity, no-interaction DoS over the network — all the attack-path knobs are turned to maximum ease. What keeps it from CRITICAL is the impact ceiling: availability loss only, with no path to code execution, data exfiltration, or privilege escalation. A restart plus a WAF rule restores service. Given the 142,000+ Maven Central dependents on commons-fileupload 1.x alone, plus Tomcat's installed base, the exposure population is enormous — but the consequence per hit is bounded at service disruption.

Why this verdict

• Unauthenticated, zero-interaction, low-complexity network attack — every multipart endpoint in every affected Java app is a target. No friction on the attacker's side of the equation.
• Massive exposure population — commons-fileupload 1.x has 142K+ Maven Central dependents; Tomcat is independently affected across three major branches. This is not a niche library.
• Weaponized public PoC — Samb102's exploit is copy-paste ready with a Docker lab, and EPSS at the 99th percentile reflects the statistical expectation of mass scanning.
• Role multiplier: Commons FileUpload and Tomcat are used across every deployment role — workstations (dev), line-of-business apps, identity providers (Keycloak on Tomcat), CI/CD (Jenkins), and monitoring dashboards. A DoS against an IdP or CI server causes cascading outages, but the blast radius remains service unavailability, not compromise. Even in the worst high-value role scenario (IdP down → auth outage across the fleet), recovery is a restart, not a forensic investigation. This keeps the floor at HIGH, not CRITICAL.
• Impact ceiling is availability-only — CVSS C:N/I:N/A:H. No memory corruption, no arbitrary write, no deserialization chain. The vulnerability cannot be upgraded to RCE by chaining with other primitives.

Why not higher?

CRITICAL requires a path to confidentiality or integrity impact, or an availability impact so catastrophic it threatens safety (OT/ICS). This CVE is pure resource exhaustion — the JVM runs out of heap and the process stalls or crashes. Recovery is a restart. Even against high-value targets like an IdP running on Tomcat, the outcome is a temporary outage, not domain takeover or data breach. There is no chain to RCE.

Why not lower?

Downgrading below HIGH would ignore the combination of zero-authentication exploitation, a weaponized public PoC, 99th-percentile EPSS, and the broadest possible Java library exposure. Any internet-facing Java application that accepts file uploads is a sitting target with no attacker prerequisites. The statistical model strongly predicts mass exploitation attempts, and the library's ubiquity means your fleet almost certainly includes affected instances.

1. Deploy WAF rules to limit multipart part count and header count — Configure your WAF (ModSecurity, AWS WAF, Cloudflare, F5 ASM) to reject requests with more than 100 parts or more than 20 headers per part. This directly blocks the attack vector. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
2. Set Tomcat maxPartCount parameter — In Tomcat's server.xml or web.xml, set <multipart-config><max-file-size> and the maxParameterCount connector attribute. Tomcat 10.1.42+ adds explicit maxPartCount; on older versions, maxParameterCount provides partial coverage. Apply to all Tomcat instances.
3. Configure JVM heap limits and container memory ceilings — Ensure -Xmx is set conservatively and Kubernetes resources.limits.memory is enforced. This converts a hang into an OOMKill + automatic restart, limiting the blast radius to seconds of downtime rather than sustained outage.
4. Rate-limit POST requests to upload endpoints — At the reverse proxy or API gateway layer, enforce per-IP rate limits (e.g., 10 multipart POSTs/minute) on known upload paths. This blunts parallelized attacks even if the payload structure isn't inspected.

Run this on any host where you need to check for vulnerable commons-fileupload JARs or Tomcat versions. Execute as any user with read access to the application's lib directories. Example: bash check_cve_2025_48976.sh /opt/tomcat /opt/myapp/WEB-INF/lib

#!/usr/bin/env bash
# check_cve_2025_48976.sh — Detect CVE-2025-48976 / CVE-2025-48988
# Usage: bash check_cve_2025_48976.sh <dir1> [dir2] ...
# Exit codes: 0 = PATCHED/UNKNOWN, 1 = VULNERABLE

set -euo pipefail

VULNERABLE=0

if [ $# -eq 0 ]; then
  echo "Usage: $0 <directory> [directory ...]"
  echo "Scans for vulnerable commons-fileupload JARs and Tomcat versions."
  exit 2
fi

for DIR in "$@"; do
  if [ ! -d "$DIR" ]; then
    echo "[SKIP] Not a directory: $DIR"
    continue
  fi

  # Check commons-fileupload 1.x (vulnerable: 1.0–1.5.x)
  find "$DIR" -name 'commons-fileupload-*.jar' 2>/dev/null | while read -r JAR; do
    VER=$(basename "$JAR" | sed -E 's/commons-fileupload-([0-9][0-9.]*).*/\1/')
    MAJOR=$(echo "$VER" | cut -d. -f1)
    MINOR=$(echo "$VER" | cut -d. -f2)
    if [ "$MAJOR" -eq 1 ] && [ "$MINOR" -lt 6 ]; then
      echo "[VULNERABLE] $JAR (version $VER < 1.6.0)"
      VULNERABLE=1
    else
      echo "[PATCHED]    $JAR (version $VER)"
    fi
  done

  # Check commons-fileupload2-core (vulnerable: 2.0.0-M1 through 2.0.0-M3)
  find "$DIR" -name 'commons-fileupload2-core-*.jar' 2>/dev/null | while read -r JAR; do
    BASENAME=$(basename "$JAR")
    if echo "$BASENAME" | grep -qE '2\.0\.0-M[123][^0-9]'; then
      echo "[VULNERABLE] $JAR (pre-2.0.0-M4)"
      VULNERABLE=1
    else
      echo "[PATCHED]    $JAR"
    fi
  done

  # Check Tomcat version via catalina.jar MANIFEST or version.sh
  CATALINA_JAR=$(find "$DIR" -name 'catalina.jar' -path '*/lib/*' 2>/dev/null | head -1)
  if [ -n "${CATALINA_JAR:-}" ]; then
    TC_VER=$(unzip -p "$CATALINA_JAR" org/apache/catalina/util/ServerInfo.properties 2>/dev/null | grep 'server.number' | cut -d= -f2 | tr -d '[:space:]')
    if [ -n "$TC_VER" ]; then
      TC_MAJOR=$(echo "$TC_VER" | cut -d. -f1)
      TC_MINOR=$(echo "$TC_VER" | cut -d. -f2)
      TC_PATCH=$(echo "$TC_VER" | cut -d. -f3)
      VULN_TC=0
      if [ "$TC_MAJOR" -eq 9 ] && [ "$TC_MINOR" -eq 0 ] && [ "$TC_PATCH" -le 105 ]; then VULN_TC=1; fi
      if [ "$TC_MAJOR" -eq 10 ] && [ "$TC_MINOR" -eq 1 ] && [ "$TC_PATCH" -le 41 ]; then VULN_TC=1; fi
      if [ "$TC_MAJOR" -eq 11 ] && [ "$TC_MINOR" -eq 0 ] && [ "$TC_PATCH" -le 7 ]; then VULN_TC=1; fi
      if [ "$VULN_TC" -eq 1 ]; then
        echo "[VULNERABLE] Tomcat $TC_VER at $(dirname "$CATALINA_JAR") (CVE-2025-48988)"
        VULNERABLE=1
      else
        echo "[PATCHED]    Tomcat $TC_VER at $(dirname "$CATALINA_JAR")"
      fi
    fi
  fi
done

if [ "$VULNERABLE" -eq 1 ]; then
  echo ""
  echo "RESULT: VULNERABLE"
  exit 1
else
  echo ""
  echo "RESULT: PATCHED (or no matching JARs found — verify manually)"
  exit 0
fi

Sources

1. GitHub Advisory — GHSA-vv7r-c36w-3prj
2. Public PoC — Samb102/POC-CVE-2025-48988-CVE-2025-48976
3. NVD — CVE-2025-48976 Detail
4. Apache Tomcat 10 Security Advisories
5. IBM Security Bulletin — WebSphere Application Server
6. Exploit Intel — CVE-2025-48976
7. Maven Central — commons-fileupload