CVE-2024-39908

What it actually does

REXML versions before the patched releases can consume excessive CPU and/or processing time when parsing specially crafted XML containing large numbers of particular characters such as '<', '0', and '%>'. The flaw is a denial-of-service condition in XML parsing logic: an attacker does not need authentication if an exposed application accepts attacker-controlled XML, but the vulnerable code path is only reached when the application parses that XML with REXML. The expected impact is reduced availability of the Ruby process, request worker, background job, or service handling the XML; confidentiality and integrity are not directly affected.

Why it matters to the business

Applications that accept XML from users, partners, APIs, file uploads, message queues, or webhooks may experience slowdowns, request timeouts, worker exhaustion, or temporary outages if malicious XML is processed. The risk is moderate because the CVSS score is 4.3, EPSS is low at approximately 1.5%, there is no CISA KEV listing, and no known public exploit maturity is reported; however, the issue has been public for a long time, so vulnerable dependencies should not remain in production. Legacy Ruby packages on unsupported platforms such as Ubuntu 14.04 are particularly concerning because they often lack broader security maintenance.

How an attack unfolds

An attacker first identifies an application feature that accepts XML input, such as an API endpoint, SAML or SOAP integration, import function, webhook receiver, uploaded file parser, or queued message processor. The attacker then submits XML crafted to trigger inefficient parsing behavior in vulnerable REXML versions, typically by including large or repetitive sequences of characters associated with the parser weakness. When the application parses the document, the Ruby process spends disproportionate resources handling the input. Repeated submissions can tie up request threads, application workers, or background jobs, causing latency, failed requests, queue backlog, health-check failures, or service degradation. The attacker does not gain code execution or data access from this flaw alone, but can use it to disrupt availability.

How to fix it

Upgrade REXML to version 3.3.2 or later wherever it is used to parse untrusted XML. If using the upstream ruby/rexml source, ensure the fix including commit 2b285ac0804f2918de642f7ed4646dc6d645a7fc is present. For Ubuntu 14.04 LTS packages, use ruby1.9.1 version 1.9.3.484-2ubuntu1.3 or later and ruby2.0 version 2.0.0.484-1ubuntu2.4 or later, though migrating off end-of-life operating systems and Ruby runtimes is strongly recommended. Rebuild and redeploy applications after dependency updates so the patched gem is actually loaded at runtime. Where immediate upgrade is not possible, avoid parsing untrusted XML, enforce strict request size limits, apply API rate limits, set parser and request timeouts, isolate XML processing workers, and reject unexpected XML content types at ingress.

How to confirm the fix worked

Confirm dependency resolution with package and build artifacts, such as Gemfile.lock, gem list, bundle info rexml, container SBOMs, and runtime dependency inventories, and verify REXML is 3.3.2 or later. For OS packages, verify installed package versions meet or exceed the fixed Ubuntu versions. Confirm deployed containers or hosts were rebuilt after the dependency change rather than only updating source manifests. Review application code paths for REXML::Document, REXML::Parsers, or libraries that indirectly parse XML with REXML. In a non-production environment, perform a controlled negative test using oversized or repetitive XML input and confirm the application rejects, times out safely, or handles the request without sustained CPU exhaustion. Validate compensating controls by checking request body limits, rate limits, XML content-type restrictions, and worker timeout settings.

Typical attack path

1. Find an externally or internally reachable feature that accepts XML or XML-like payloads.
2. Confirm the target application is Ruby-based or otherwise likely to use REXML for XML parsing.
3. Send a crafted XML document containing high-volume, parser-stressing character patterns.
4. Observe slow responses, timeouts, worker saturation, or increased CPU usage.
5. Repeat or parallelize requests to exhaust available application capacity and cause denial of service.

How to detect it

To determine whether exploitation was attempted or successful, correlate application access logs, reverse proxy logs, WAF logs, APM traces, Ruby exception logs, background job logs, host CPU metrics, container restart events, and load balancer health-check failures. Look for bursts of requests or queued messages with XML content types, unusually large XML bodies, repetitive special-character patterns, or requests to XML-processing endpoints immediately preceding high CPU, request timeouts, 502/503/504 responses, worker restarts, or queue backlog. In Ruby logs, review stack traces or timeout events involving REXML parsing classes. Because this vulnerability does not produce a unique compromise artifact and does not provide code execution, detection is behavioral rather than based on a definitive file, process, or network IOC. Treat isolated parser errors as low confidence; confidence increases when they align with abnormal resource consumption and repeated XML submissions from the same source or campaign.

• REXML::ParseException
• REXML::Document
• REXML::Parsers
• Content-Type: application/xml
• Content-Type: text/xml
• Content-Type: application/soap+xml
• ActionController::RequestTimeout
• Rack::Timeout::RequestTimeoutException
• Net::ReadTimeout
• HTTP 504
• HTTP 503
• worker timeout
• killed by SIGKILL
• out of memory

What your security team should do

• Inventory Ruby applications and services that parse XML, prioritizing internet-facing APIs, file upload handlers, webhook receivers, SOAP/SAML integrations, and background job consumers.
• Upgrade REXML to 3.3.2 or later and redeploy affected applications; verify the patched version is loaded at runtime.
• Prioritize remediation for any service that accepts unauthenticated or partner-supplied XML, even though this vulnerability is not in CISA KEV and has low EPSS.
• Add or verify request body size limits, XML-specific validation, rate limiting, application worker timeouts, and queue processing safeguards.
• Search logs and telemetry for historical XML-triggered timeouts, CPU spikes, worker restarts, and bursts of 4xx/5xx responses that may indicate attempted denial-of-service activity.
• Plan migration away from end-of-life Ruby and Ubuntu releases, especially Ubuntu 14.04-era ruby1.9.1 and ruby2.0 packages.
• Add dependency scanning or SBOM policy checks to prevent reintroduction of vulnerable REXML versions.