GHSA-7c2q-5qmr-v76q

What it actually does

The flaw allows a remote user who can reach an application file-upload endpoint using vulnerable OWASP ESAPI file-upload handling to trigger denial-of-service conditions through specially crafted or abusive multipart upload requests. The practical failure mode is resource exhaustion: excessive request parsing work, too many multipart elements, oversized or malformed upload streams, temporary-file/disk exhaustion, memory pressure, thread starvation, or repeated exceptions in the upload parser. The affected Maven package is org.owasp.esapi:esapi before 2.5.2.0. The supplied affected product data also lists Debian 10 xen packages fixed in 4.11.4+57-g41a822c392-1; validate separately whether this package is present because the vulnerability description is specific to ESAPI upload handling.

Why it matters to the business

Successful exploitation can make web applications or services that accept uploads slow, unstable, or unavailable, especially where upload endpoints are internet-facing or unauthenticated. The main business risk is service interruption: failed user uploads, degraded application performance, increased infrastructure costs from resource spikes, and possible cascading failures if shared application servers, storage, or queues are exhausted. There is no current KEV listing and no provided evidence of mature public exploitation, but the issue has been public for a long time, so lingering vulnerable dependencies should be treated as hygiene debt in production applications.

How an attack unfolds

An attacker first identifies an application endpoint that accepts file uploads and uses vulnerable ESAPI upload processing. They then send multipart/form-data requests designed to consume disproportionate server resources, such as requests with a very large number of parts, oversized files, malformed boundaries, slow or incomplete upload streams, or repeated upload attempts. The vulnerable parser or surrounding ESAPI upload logic spends excessive CPU, memory, disk, or thread resources handling the request and cleanup. By repeating the requests, the attacker can fill temporary storage, exhaust worker threads, trigger frequent upload parsing exceptions, or cause heap pressure, resulting in degraded service or complete denial of service for legitimate users.

How to fix it

Upgrade org.owasp.esapi:esapi to version 2.5.2.0 or later in all Maven builds, including transitive dependency paths. If Debian 10 xen packages are present in scope, update xen to 4.11.4+57-g41a822c392-1 or later from trusted Debian repositories. Rebuild and redeploy applications after dependency updates, then verify the runtime artifact actually contains the fixed ESAPI version. Apply defense-in-depth controls on all upload endpoints: enforce maximum request body size, maximum single-file size, maximum multipart part count, upload timeout limits, authenticated access where feasible, per-user/IP rate limits, reverse-proxy request limits, dedicated temporary storage with quotas, and monitoring/cleanup for upload temp directories. If immediate upgrade is not possible, restrict access to upload endpoints, lower request-size and timeout thresholds at the web server or load balancer, and isolate upload processing from critical application worker pools.

How to confirm the fix worked

Confirm exposure by inventorying Java applications and build manifests for org.owasp.esapi:esapi versions older than 2.5.2.0, using dependency tooling such as mvn dependency:tree, Gradle dependencyInsight, SCA results, SBOMs, and inspection of deployed JAR/WAR/EAR artifacts. Confirm remediation by verifying the packaged dependency version is 2.5.2.0 or later and that no older ESAPI JAR remains on the runtime classpath. For Debian systems, verify the installed xen package version is at least 4.11.4+57-g41a822c392-1 where applicable. Functionally test upload endpoints with legitimate files, oversized files, excessive multipart parts, malformed multipart boundaries, and slow uploads to ensure requests are rejected quickly with controlled 4xx responses rather than causing 5xx errors, thread exhaustion, heap growth, or temporary-disk growth.

Typical attack path

1. Reconnaissance: find web routes, API endpoints, or forms that accept multipart/form-data uploads.
2. Fingerprinting: test upload behavior, limits, error responses, and whether the application appears to use Java/ESAPI or Commons FileUpload-style handling.
3. Payload construction: prepare multipart upload requests with excessive part counts, large payloads, malformed boundaries, or slow/incomplete streams.
4. Delivery: send repeated or concurrent upload requests to maximize parser, thread, memory, and temporary-disk consumption.
5. Impact: application upload handlers become slow or fail; the broader application may return 5xx errors, time out, or exhaust storage/heap/thread pools.
6. Persistence of disruption: continue requests or distribute them across clients to keep the service degraded until rate limits, request limits, or patches are applied.

How to detect it

There is no single reliable exploit string for this issue; detection should focus on upload-endpoint behavior and resource-exhaustion artifacts. Review web access logs, WAF/CDN logs, load balancer logs, application logs, JVM logs, application-server logs, host telemetry, and temporary upload storage metrics. Look for bursts of POST requests using multipart/form-data, unusually large Content-Length values, many small multipart parts, malformed boundary errors, incomplete or timed-out uploads, repeated requests from the same source or distributed sources, and spikes in 408/413/429/499/500/502/503/504 responses. In Java logs, look for ESAPI and Apache Commons FileUpload exceptions, upload parsing failures, OutOfMemoryError, thread pool exhaustion, or disk-full errors around the same time as upload traffic spikes. On hosts, check temporary upload directories for rapid growth, many orphaned upload files, or filesystem exhaustion. Correlate these events with application latency, CPU, heap, garbage collection, disk usage, and request concurrency to distinguish exploitation from normal large-file usage.

• multipart/form-data
• org.owasp.esapi
• org.owasp.esapi.errors
• org.apache.commons.fileupload
• FileUploadException
• SizeLimitExceededException
• FileSizeLimitExceededException
• FileCountLimitExceededException
• MalformedStreamException
• Stream ended unexpectedly
• the request was rejected because its size exceeds the configured maximum
• Processing of multipart/form-data request failed
• No space left on device
• java.lang.OutOfMemoryError
• GC overhead limit exceeded
• java.util.concurrent.RejectedExecutionException
• HTTP 413
• HTTP 429
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Prioritize internet-facing and unauthenticated file-upload services using org.owasp.esapi:esapi below 2.5.2.0.
• Upgrade ESAPI to 2.5.2.0 or later and redeploy affected applications; verify the fixed version in the deployed artifact, not only in source control.
• Add or tighten upload controls at the reverse proxy, application server, and application layers: body size, file size, part count, timeout, concurrency, and rate limits.
• Hunt for historical denial-of-service attempts against upload endpoints, especially bursts of multipart/form-data requests followed by 5xx errors, upload parser exceptions, disk pressure, or JVM memory errors.
• Monitor temporary upload directories, application heap, request latency, 5xx rates, and worker-thread saturation for upload-heavy applications.
• Ensure upload handling runs with bounded temporary storage and cleanup jobs so failed or partial uploads cannot fill shared disks.
• If Debian 10 xen packages are present, update to 4.11.4+57-g41a822c392-1 or later and confirm the package source is trusted.
• Document accepted upload limits and add regression tests so future dependency or configuration changes do not reintroduce unbounded upload parsing behavior.