CVE-2024-49761

What it actually does

The vulnerable REXML parser can enter catastrophic regular-expression backtracking when processing an XML hex numeric character reference containing an unusually long run of digits after "&#x" and before the terminating semicolon. A remote, unauthenticated attacker can trigger excessive CPU consumption by submitting crafted XML to any Ruby application that parses attacker-controlled XML with REXML versions before 3.3.9. The impact is availability-only: it does not directly allow code execution, data theft, or data modification. Ruby 3.1 deployments using the vulnerable REXML gem are the primary maintained affected runtime; Ruby 3.2 and later are not affected by this parsing behavior.

Why it matters to the business

Applications, APIs, background workers, or integration services that accept XML input may become slow, unresponsive, or unavailable after receiving a small crafted request. This can disrupt customer-facing services, partner integrations, file-processing pipelines, and internal automation that depend on Ruby XML parsing. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so broad active exploitation is not indicated; however, the attack is network-reachable and low-complexity wherever untrusted XML is accepted.

How an attack unfolds

An attacker first identifies a Ruby application endpoint, message consumer, upload workflow, webhook, SOAP/XML API, or background job that parses XML using REXML on an affected Ruby 3.1-era dependency set. The attacker then submits XML containing a malformed or extreme hex numeric character reference, such as a sequence beginning with "&#x" followed by a very large number of hexadecimal digits and a semicolon. When the vulnerable parser attempts to interpret the character reference, the regular expression used by REXML consumes excessive CPU due to backtracking. Repeating the request or sending multiple payloads concurrently can tie up application workers, increase request latency, exhaust process capacity, and cause denial of service until the process recovers, is restarted, traffic is blocked, or the package is upgraded.

How to fix it

Upgrade the REXML gem to version 3.3.9 or later wherever it is used. If REXML is bundled through the Ruby runtime or a lockfile, update the Ruby package/dependency bundle so the resolved REXML version is patched. The upstream fixes are present in ruby/rexml commit 38eaa86ac7abe0d31cf49d8df57ad239fdeb80e9 and ruby/ruby commit f5c772fc7cbe9f5b58d962939fcb1c7e3fb1cfa6. Ruby 3.2 and later are not affected by the described behavior, so upgrading the runtime is also an effective mitigation where feasible. If immediate upgrade is not possible, reduce exposure by rejecting or size-limiting XML inputs, enforcing strict request body limits and parser timeouts, blocking character references with excessively long "&#x...;" sequences at the edge, rate-limiting XML-processing endpoints, and isolating XML parsing workers so parser stalls cannot exhaust the entire application.

How to confirm the fix worked

Confirm dependency resolution shows REXML 3.3.9 or later, for example by inspecting Gemfile.lock, gem dependency output, software composition analysis results, container image package manifests, and deployed artifact manifests. Confirm the Ruby runtime is not an affected Ruby 3.1 deployment with an older bundled REXML. Exercise XML-processing endpoints with benign XML regression tests to ensure normal parsing still works after the upgrade. In a controlled non-production environment, test that XML containing an extremely long "&#x...;" numeric character reference is rejected quickly or processed without sustained CPU spikes. Validate compensating controls by checking that request body limits, WAF/API gateway rules, and rate limits trigger before XML reaches the parser.

Typical attack path

1. Find an exposed application feature that accepts XML input, XML uploads, SOAP requests, webhook payloads, or XML-based integration messages.
2. Confirm or infer that the service is implemented in Ruby and uses REXML to parse the submitted XML.
3. Craft XML containing a hex numeric character reference with an abnormally long digit sequence between "&#x" and ";".
4. Submit the XML to the vulnerable endpoint or processing queue.
5. Cause the Ruby process parsing the XML to spend excessive CPU time in the parser.
6. Repeat or parallelize submissions to degrade service availability or exhaust application worker capacity.

How to detect it

Review HTTP access logs, API gateway logs, WAF logs, reverse proxy logs, application logs, background job logs, and message broker payload metadata for XML submissions containing unusually long hex numeric character references. Search request bodies where retained for "&#x" followed by hundreds or thousands of hexadecimal characters before a semicolon. Correlate suspicious requests with spikes in Ruby process CPU, application worker timeouts, increased request duration, 502/503/504 responses, queue backlog growth, container restarts, or process supervisor restarts. Application logs may show XML parser exceptions, request timeouts, or generic worker termination rather than a distinctive exploit message. If full payload logging is unavailable, look for repeated large XML requests to XML-processing endpoints from the same source around periods of CPU exhaustion. For forensics, preserve relevant reverse proxy logs, WAF event bodies, application traces, APM spans, process metrics, and any queued XML messages received during the outage window.

• &#x[0-9A-Fa-f]{100,};
• &#x[0-9A-Fa-f]{1000,};
• &#x00000000000000000000000000000000000000000000000000
• REXML::ParseException
• REXML::UndefinedNamespaceException
• REXML::Document.new
• application/xml
• text/xml
• Content-Type: application/xml
• Content-Type: text/xml
• ruby

What your security team should do

• Inventory Ruby applications, services, jobs, and containers that parse XML or include the REXML gem.
• Prioritize remediation for internet-facing XML endpoints, SOAP services, webhook receivers, file upload processors, and queue consumers that parse untrusted XML.
• Upgrade REXML to 3.3.9 or later, or move affected workloads to Ruby 3.2 or later where practical.
• Regenerate and redeploy lockfiles and container images so the patched gem is present in runtime artifacts, not only in source repositories.
• Add input validation or WAF/API gateway rules to reject XML containing extremely long hex numeric character references.
• Set request size limits, parser timeouts, worker timeouts, and rate limits for XML-processing routes.
• Monitor for repeated XML parse errors, long-running Ruby requests, high CPU saturation, worker timeouts, and payloads containing suspicious "&#x" sequences.
• Because there is no KEV listing, no known ransomware use, and low EPSS, handle as an availability-risk patching item, with faster action for externally reachable XML parsers.