CVE-2024-41946

What it actually does

REXML 3.3.2, a Ruby XML parsing library, is vulnerable to denial of service when XML containing many entity expansions is processed through the SAX2 parser or pull parser APIs. A remote, unauthenticated attacker can submit a specially crafted XML document to an application endpoint that parses attacker-controlled XML with the vulnerable REXML version, causing excessive CPU and/or memory consumption during entity expansion. The vulnerability does not provide confidentiality or integrity impact by itself, but it can degrade or interrupt availability of the Ruby process or service handling XML input.

Why it matters to the business

Applications that accept XML input and rely on the vulnerable REXML parser may become slow, unstable, or unavailable after receiving crafted XML payloads. This can disrupt APIs, background processors, mail-processing workflows, integrations, or user-facing services that parse XML. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or known ransomware use, but exposure is still operationally relevant because exploitation is network-accessible, unauthenticated, and low complexity wherever untrusted XML is parsed.

How an attack unfolds

An attacker first identifies an application endpoint, API, upload workflow, mail-processing path, or integration that accepts XML and is implemented in Ruby using REXML 3.3.2. The attacker then crafts an XML document containing a large number of entity expansions intended to force the SAX2 or pull parser into expensive expansion work. When the vulnerable application parses the XML, REXML consumes disproportionate CPU and/or memory resources. Repeated requests can amplify the impact, tying up worker processes, increasing latency, triggering application restarts, exhausting queues, or causing service-level denial of service. This issue is availability-focused; it is not expected to directly execute code or disclose data.

How to fix it

Upgrade the REXML gem to version 3.3.3 or later. For source-based consumers, ensure the fix corresponding to ruby/rexml commit e4a067e11235a2ec7a00616d41350485e384ec05 is present. For Ubuntu 16.04 LTS ruby-mail packaging, update to 2.6.3+dfsg1-1 or the latest vendor-provided patched package. Regenerate dependency lockfiles and rebuild/redeploy application containers or packages so the patched gem is actually loaded at runtime. As defense in depth, restrict XML request size, enforce parsing timeouts, limit entity expansion, reject XML documents with DTD/entity declarations when not required, apply rate limits to XML-ingesting endpoints, and isolate resource-heavy parsing into constrained worker processes.

How to confirm the fix worked

Confirm that dependency manifests and runtime package inventories no longer show REXML 3.3.2. For Ruby applications, check Gemfile.lock, gemspecs, container images, and runtime output such as `bundle exec ruby -r rexml -e 'puts REXML::VERSION'` and verify version 3.3.3 or later. For Ubuntu packages, verify the installed ruby-mail package is 2.6.3+dfsg1-1 or later using the system package manager. Test XML ingestion paths with benign XML after upgrade to confirm application functionality, and use safe negative tests to verify that oversized XML or XML with DTD/entity declarations is rejected or bounded. Confirm deployed images, build artifacts, and hosts were refreshed rather than only updating source repositories.

Typical attack path

1. Identify a Ruby application, API, upload feature, webhook, mail parser, or integration that accepts XML input.
2. Confirm or infer that the application uses REXML 3.3.2 and parses XML with SAX2Parser or PullParser APIs.
3. Create XML containing many entity definitions or entity expansion references.
4. Submit the crafted XML to the exposed parsing path over the network or through an accepted file/message workflow.
5. Cause the target process to consume excessive CPU or memory while parsing the payload.
6. Repeat submissions or send concurrent payloads to sustain latency, worker exhaustion, crashes, or service unavailability.

How to detect it

Look for evidence of attempted resource-exhaustion attacks against XML parsing paths. Useful sources include web server access logs, application logs, API gateway logs, WAF logs, load balancer logs, container or process metrics, application performance monitoring traces, background job logs, mail-processing logs, and host telemetry. Search for bursts of POST/PUT/upload requests with XML content, request bodies containing DOCTYPE or ENTITY declarations, long request durations, elevated 4xx/5xx responses, Ruby worker restarts, memory pressure, CPU saturation, queue backlogs, and REXML parser exceptions. Because denial-of-service attempts may not leave a persistent host artifact, correlate suspicious XML payloads with service degradation windows. If request-body logging is unavailable, use metadata such as content type, payload size, repeated requests to XML endpoints, source concentration, and latency spikes to identify likely exploitation attempts.

• REXML::ParseException
• REXML::Parsers::SAX2Parser
• REXML::Parsers::PullParser
• <!DOCTYPE
• <!ENTITY
• &xxe;
• &lol;
• application/xml
• text/xml
• Content-Type: application/xml
• Content-Type: text/xml
• Gemfile.lock: rexml (3.3.2)
• rexml (3.3.2)

What your security team should do

• Inventory Ruby applications, containers, and packages that include REXML, especially services that accept XML from users, partners, APIs, webhooks, email, or file uploads.
• Prioritize patching internet-facing or unauthenticated XML ingestion paths by upgrading REXML to 3.3.3 or later and rebuilding deployed artifacts.
• Where patching is delayed, block or reject XML containing DTD/entity declarations unless business-required, and enforce request-size, timeout, memory, and rate limits.
• Add monitoring for spikes in CPU, memory, request duration, worker restarts, HTTP 5xx responses, and XML parser exceptions around XML-processing endpoints.
• Review WAF, reverse proxy, application, and message-processing logs for repeated XML submissions containing DOCTYPE or ENTITY declarations, especially from a small set of source IPs.
• Document compensating controls and remove temporary mitigations only after verifying the patched library is loaded in production runtimes.