CVE-2024-41123

What it actually does

This vulnerability affects Ruby applications and packaged software that parse untrusted XML using vulnerable versions of the REXML XML parser. Specially crafted XML containing large quantities of certain characters, including whitespace and sequences such as `>]` and `]>`, can trigger inefficient parsing behavior and excessive CPU consumption. The impact is denial of service: confidentiality and integrity are not directly affected, but the parsing process, application worker, or service handling XML input can become slow, unresponsive, or unavailable.

Why it matters to the business

An unauthenticated remote attacker may be able to degrade or interrupt services that accept XML input, especially APIs, integrations, messaging workflows, file upload processors, or background jobs that parse XML with REXML. The CVSS score is moderate and EPSS is low, and it is not listed in CISA KEV, but the flaw is simple to trigger where exposed XML parsing exists and has been public for a long time, so internet-facing or automation-critical XML endpoints should still be patched. Operational impact may include service outages, increased latency, worker exhaustion, failed transactions, monitoring alerts, and support escalations.

How an attack unfolds

An attacker first identifies an application or service that accepts XML documents and processes them with a vulnerable REXML version. They then submit XML containing large volumes of parser-stressing character patterns, such as excessive whitespace or repeated delimiter-like sequences. The vulnerable parser spends disproportionate CPU time processing the input, tying up the request thread, application worker, or background processor. Repeated submissions can exhaust available workers or CPU capacity, causing slow responses, timeouts, queue backlogs, or temporary service unavailability. There is no indication from the provided data of active KEV exploitation, ransomware use, or named threat actor activity for this issue.

How to fix it

Upgrade the REXML gem to version 3.3.3 or later. If consuming REXML directly from source, ensure the fix containing commit `e4a067e11235a2ec7a00616d41350485e384ec05` or later is present. For Ubuntu-packaged Pidgin systems, update to the vendor-fixed packages: Ubuntu 14.04 LTS package `1:2.10.9-0ubuntu3.3` or later, and Ubuntu 16.04 LTS package `1:2.10.12-0ubuntu5.1` or later. Where immediate patching is not possible, reduce exposure by rejecting untrusted XML where feasible, enforcing request body size limits, adding XML parsing timeouts, limiting parser recursion and entity-like constructs, applying per-client rate limits, isolating XML parsing workers, and monitoring CPU saturation and request timeout rates.

How to confirm the fix worked

Confirm installed Ruby dependencies with `bundle info rexml`, `bundle list`, `gem list rexml`, or software composition analysis tooling and verify REXML is 3.3.3 or later. Review lockfiles such as `Gemfile.lock` for `rexml` versions below the fixed release. For source-based deployments, verify the fixed commit `e4a067e11235a2ec7a00616d41350485e384ec05` or an equivalent later revision is present. For Ubuntu Pidgin packages, validate installed package versions with package management tooling and confirm they meet or exceed the vendor-fixed versions. In test environments, exercise XML parsing paths with benign large XML inputs and confirm requests fail fast or complete within expected timeout/resource limits without sustained CPU spikes.

Typical attack path

1. Identify an externally reachable API, upload feature, webhook, integration endpoint, chat/client component, or background processor that accepts XML input.
2. Confirm or infer that the target stack uses Ruby REXML or a bundled package that depends on a vulnerable REXML parser.
3. Send a malformed or oversized XML payload containing many whitespace characters or repeated `>]` / `]>`-style sequences.
4. Cause the XML parsing routine to consume excessive CPU or run for an abnormal duration.
5. Repeat requests or submit multiple payloads in parallel to exhaust application workers, increase latency, or make the service unavailable.

How to detect it

Look for evidence of denial-of-service attempts against XML-processing paths rather than data theft. Relevant sources include web access logs, API gateway logs, reverse proxy logs, WAF logs, application logs, Ruby exception logs, APM traces, job queue telemetry, host CPU metrics, container restart events, and process-level resource monitoring. Hunt for bursts of POST/PUT requests with XML content types, unusually large XML bodies, high request duration, HTTP 408/429/499/500/502/503/504 responses, application worker timeouts, and CPU saturation correlated with XML parsing. Inspect captured payload samples, if available, for excessive whitespace and repeated `>]` or `]>` sequences. In Ruby logs, review timeout exceptions, request watchdog terminations, worker restarts, and stack traces involving REXML parsing. Absence of a crash or file artifact does not rule out exploitation, because successful exploitation may only appear as resource exhaustion and latency.

• Content-Type: application/xml
• Content-Type: text/xml
• REXML::ParseException
• REXML::Document.new
• REXML::Parsers::BaseParser
• REXML::Parsers::TreeParser
• REXML::Parsers::PullParser
• execution expired
• Rack::Timeout::RequestTimeoutException
• Net::ReadTimeout
• HTTP 408
• HTTP 429
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504
• >]
• ]>
• Gemfile.lock: rexml (3.3.1)
• Gemfile.lock: rexml (3.3.0)
• Gemfile.lock: rexml (3.2.9)
• Gemfile.lock: rexml (3.2.8)
• Gemfile.lock: rexml (3.2.7)
• Gemfile.lock: rexml (3.2.6)
• Gemfile.lock: rexml (3.2.5)

What your security team should do

• Inventory applications, services, jobs, and packaged software that parse XML using Ruby REXML, prioritizing internet-facing endpoints and high-volume integration services.
• Upgrade REXML to 3.3.3 or later and apply the relevant Ubuntu Pidgin vendor updates where applicable.
• Add or verify compensating controls for XML inputs: body size limits, parser timeouts, worker isolation, rate limiting, and load-shedding behavior.
• Search logs and telemetry for historical spikes in XML parsing latency, request timeouts, high CPU usage, and repeated submissions containing unusual concentrations of whitespace or `>]` / `]>` sequences.
• Add regression tests for XML parsing resource limits so future dependency changes do not reintroduce unbounded parsing behavior.
• Because this is not KEV-listed and has low EPSS, prioritize based on exposure and business criticality rather than emergency response, but do not leave externally reachable XML parsers unpatched.