CVE-2024-47554

What it actually does

This is an uncontrolled resource consumption flaw in Apache Commons IO's org.apache.commons.io.input.XmlStreamReader class. When an application uses the vulnerable class to process attacker-controlled XML or XML-like input, a maliciously crafted stream can cause excessive CPU consumption during character set, BOM, XML prolog, or stream parsing logic. The impact is denial of service: affected application threads can become CPU-bound, request queues can back up, and service responsiveness can degrade. There is no indication from the provided data that this enables code execution, privilege escalation, or data disclosure.

Why it matters to the business

Applications that accept user-supplied XML, uploaded files, API payloads, feeds, documents, or other streams parsed through vulnerable Apache Commons IO versions may be susceptible to service slowdown or outage. The main business risk is operational disruption: increased latency, failed transactions, autoscaling cost spikes, reduced availability, and potential cascading failures in dependent services. The issue is not listed in CISA KEV, is not associated with ransomware use, and has a low EPSS score, so broad exploitation pressure appears limited; however, it has been public for a long time and should be remediated as part of routine dependency hygiene, especially for internet-facing Java services and products with many downstream consumers.

How an attack unfolds

An attacker first identifies an application feature that accepts XML or stream content, such as file upload, document import, feed ingestion, API submission, SAML/XML-related input, or a backend integration endpoint. The attacker then sends a specially crafted input that reaches Apache Commons IO's XmlStreamReader in a vulnerable version before 2.14.0. During parsing or encoding detection, the vulnerable code consumes disproportionate CPU compared with the size or apparent complexity of the submitted input. By repeating the request, sending concurrent submissions, or targeting multiple worker processes, the attacker can keep application threads busy, exhaust CPU capacity, increase response times, and eventually make the affected service unavailable. Successful exploitation generally requires that attacker-controlled content is parsed by the vulnerable class; systems that include the library but never invoke XmlStreamReader on untrusted input are less exposed.

How to fix it

Upgrade Apache Commons IO to version 2.14.0 or later wherever it is present, including direct and transitive dependencies. For Maven, Gradle, SBT, Bazel, shaded JARs, vendor bundles, and application server libraries, ensure the resolved commons-io artifact is not in the affected 2.0 through 2.13.x range. Where operating system packages are used, apply vendor fixes; the provided fixed package examples include webkitgtk on Ubuntu 14.04 LTS fixed in 2.4.10-0ubuntu0.14.04.1 and webkitgtk on Ubuntu 16.04 LTS fixed in 2.4.10-0ubuntu1. For source consumers, the provided upstream Git fix reference is 82250a879112e9b58c58d289e166d66942d77341, but packaged version upgrades are preferred. If immediate upgrade is not possible, reduce exposure by rejecting untrusted XML where not required, enforcing strict request size and time limits, applying upload and API rate limits, isolating XML processing workers, setting container CPU limits, and adding circuit breakers or timeouts around stream parsing.

How to confirm the fix worked

Confirm remediation by inspecting build manifests, dependency lockfiles, SBOMs, and runtime classpaths for Apache Commons IO and verifying that no resolved version is between 2.0 and 2.13.x. Use commands such as Maven dependency:tree, Gradle dependencies, SBOM scanners, container image scanners, and filesystem searches for commons-io-*.jar to identify embedded or shaded copies. For Linux packages, verify that the installed package version is at or above the vendor-fixed release. In running applications, confirm that the loaded commons-io JAR is the upgraded one and that old copies are not present in application server shared library directories. Functional validation should include normal XML ingestion tests plus defensive tests for request size limits, parsing timeouts, and rate limits; avoid running denial-of-service payloads against production systems. Monitor CPU and request latency after upgrade to ensure no regression remains in XML-processing paths.

Typical attack path

1. Find an application endpoint or workflow that accepts XML, uploaded documents, feeds, or arbitrary stream content.
2. Confirm that submitted content is processed by Java code or a component that may use Apache Commons IO XmlStreamReader.
3. Submit a crafted XML or XML-like stream designed to trigger excessive CPU use during parsing or encoding detection.
4. Observe slow responses, timeouts, or elevated server CPU as feedback that the payload is effective.
5. Repeat the request or send it concurrently to consume worker threads and CPU capacity.
6. Sustain the request volume until the application, container, or host experiences degraded performance or denial of service.

How to detect it

There are no widely established public indicators of compromise for this issue in the provided data, and exploitation may look like ordinary XML or file-submission traffic followed by resource exhaustion. To assess whether exploitation already occurred, correlate application, web server, API gateway, reverse proxy, container, host, and APM telemetry. Look for bursts of requests to XML-processing, upload, import, feed, document, or API endpoints immediately preceding high CPU, request timeouts, thread pool exhaustion, autoscaling events, container restarts, or elevated HTTP 408/429/500/502/503/504 responses. Review Java thread dumps and profiling data captured during incidents for many threads spending time in or below org.apache.commons.io.input.XmlStreamReader. Examine WAF and access logs for repeated large or malformed XML/XML-like submissions from the same source, unusual user agents, low request rates that nevertheless cause high CPU, and repeated retries after timeouts. On hosts and containers, review CPU metrics, JVM garbage collection logs, application error logs, orchestrator restart events, and load balancer health check failures. Because the primary effect is denial of service rather than persistence, do not expect durable malware artifacts solely from this vulnerability; focus on timing correlation between suspicious input processing and resource exhaustion.

What your security team should do

• Inventory all applications, containers, libraries, and vendor components that include Apache Commons IO, prioritizing internet-facing services and systems that parse user-supplied XML or uploaded files.
• Upgrade Apache Commons IO to 2.14.0 or later, and remove duplicate or shaded vulnerable JARs from application packages and runtime classpaths.
• Ask application owners to identify uses of org.apache.commons.io.input.XmlStreamReader and determine whether any process attacker-controlled input.
• Apply compensating controls for exposed XML-processing endpoints: request body limits, upload size limits, rate limits, authentication where appropriate, parsing timeouts, queue limits, and CPU isolation.
• Add monitoring for abnormal CPU saturation, increased XML/API request latency, worker thread exhaustion, HTTP 5xx spikes, and request timeout spikes on services that accept XML or file uploads.
• Review recent logs for repeated requests to XML ingestion, document upload, feed import, or API endpoints that correlate with CPU spikes or service timeouts.
• Track vendor advisories for bundled products, especially where Commons IO is embedded and cannot be upgraded independently.
• Because this is not KEV-listed, has no known ransomware association, and has low EPSS, treat it as a medium-priority dependency remediation unless the affected component is internet-facing or business-critical.