CVE-2025-58767

What it actually does

REXML versions 3.3.3 through 3.4.1 contain a denial-of-service flaw in XML parsing logic when handling documents that contain multiple XML declarations. When an application parses attacker-controlled XML using an affected REXML version, a specially crafted XML document can trigger excessive processing, parser failure behavior, or resource exhaustion. The impact is availability-focused: it does not directly provide code execution, data disclosure, or privilege escalation, but it can degrade or interrupt services that parse untrusted XML. Downstream packages and distributions that bundle or depend on affected XML parsing paths, including listed Debian ImageMagick and GraphicsMagick packages, should be treated as potentially exposed where they process XML-derived or XML-containing inputs.

Why it matters to the business

Applications, background jobs, APIs, import pipelines, document-processing services, or image-processing workflows that accept untrusted XML may be made slow or unavailable by a small number of malicious inputs. Operational consequences can include failed uploads, queue backlogs, increased CPU or memory consumption, service restarts, timeouts, and degraded user-facing availability. The current exploitation signal is low: EPSS is 0.231%, it is not listed in CISA KEV, no ransomware use is indicated, and exploit maturity is reported as none. However, because XML parsing libraries are often embedded in many applications and dependencies, organizations should still remediate during normal patch cycles and prioritize internet-facing or high-volume XML ingestion points.

How an attack unfolds

An attacker first identifies an endpoint, job, or file-processing path that accepts XML or XML-like content and parses it with an affected REXML version, either directly through a Ruby application or indirectly through a packaged component. The attacker then submits a crafted XML payload containing multiple XML declarations. When the vulnerable parser processes the document, it mishandles the repeated declarations and consumes disproportionate processing resources or causes parsing failures that can tie up worker threads, application processes, or batch pipelines. Repeated submissions can amplify the effect, producing request timeouts, failed jobs, service degradation, or temporary denial of service. There is no evidence from the provided data that this vulnerability is being exploited by named threat actors, ransomware campaigns, or broad public exploit activity.

How to fix it

Upgrade REXML to version 3.4.2 or later wherever XML from untrusted sources may be parsed. For source builds using the upstream repository, include commit f36916fe1c66b8cdc1fe482263115625e084d8fe or a later fixed revision. For listed Debian packages, update to the fixed package versions where applicable: ImageMagick fixed in 7:6.2.4.5.dfsg1-0.10 for Debian 11, 12, 13, and 14; GraphicsMagick fixed in 1.1.7-8 for Debian 11, 12, 13, and 14. In Ruby applications, review Gemfile.lock, gemspecs, vendored gems, containers, and base images for REXML versions 3.3.3 through 3.4.1. If immediate upgrade is not possible, mitigate by rejecting XML with multiple XML declarations before parsing, limiting request and file sizes, enforcing parser timeouts, constraining worker CPU and memory, rate-limiting XML ingestion endpoints, and isolating document-processing workloads from critical application services.

How to confirm the fix worked

Confirm that runtime dependency resolution no longer includes REXML versions 3.3.3 through 3.4.1. For Ruby applications, run dependency inventory commands such as bundle list, bundle info rexml, gem list rexml, and software composition analysis against lockfiles and container images. For Debian systems, verify installed package versions with dpkg-query or equivalent package inventory tooling and confirm ImageMagick and GraphicsMagick are at or above the fixed versions listed. Test representative XML ingestion paths using benign XML and malformed XML containing multiple declarations in a controlled environment; the fixed behavior should reject the malformed input quickly without sustained CPU, memory, thread, or worker exhaustion. Validate that request-size limits, timeout controls, rate limits, and monitoring alerts are active for XML-processing endpoints and background workers.

Typical attack path

1. Identify an application, API, upload feature, integration endpoint, or processing pipeline that accepts XML or XML-containing files.
2. Confirm that the target uses an affected REXML version, affected Ruby dependency chain, or a downstream package that may invoke vulnerable XML parsing.
3. Create a malformed XML document containing more than one XML declaration.
4. Submit the payload through the exposed XML ingestion path, such as an API request, file upload, import job, message queue, or document conversion workflow.
5. Trigger excessive parser work, parser exceptions, blocked workers, or service timeouts.
6. Repeat submissions or send them concurrently to increase resource consumption and cause user-visible denial of service.

How to detect it

Look for evidence of attempted or successful denial-of-service against XML-processing paths. Useful log sources include web server access logs, API gateway logs, reverse proxy logs, application logs from Ruby services, background job and queue logs, container and orchestration events, package-level exception telemetry, endpoint resource metrics, and file upload or document-processing audit logs. Search request bodies, captured samples, quarantined uploads, message payloads, or application debug logs for XML content containing more than one XML declaration. Correlate those findings with bursts of HTTP 400/422/500/502/503/504 responses, request timeouts, worker restarts, high CPU usage, memory pressure, queue latency, and parser exceptions involving REXML or XML declaration handling. Since the vulnerability is denial-of-service focused, absence of a persistent file, process, account, or registry artifact does not rule out exploitation; the strongest evidence is temporal correlation between malformed XML submissions and service degradation. No named threat actor or KEV-driven exploitation is indicated in the provided data, so detection should focus on malformed-input abuse rather than actor-specific infrastructure.

• <\?xml[^>]*\?>.*<\?xml
• <\?xml version=.*\?>.*<\?xml version=
• REXML::ParseException
• multiple XML declarations
• XML declaration
• processing instruction target matching "[xX][mM][lL]" is not allowed
• xml declaration is not at the start of entity
• <?xml version="1.0"?><\?xml

What your security team should do

• Inventory Ruby applications, containers, CI artifacts, and packaged services for REXML versions 3.3.3 through 3.4.1, prioritizing internet-facing XML ingestion and high-volume processing services.
• Upgrade REXML to 3.4.2 or later and apply the fixed Debian ImageMagick and GraphicsMagick packages where those components are present.
• Add or verify pre-parse validation that rejects XML documents containing multiple XML declarations, especially on unauthenticated or externally reachable endpoints.
• Apply compensating controls where patching is delayed: request-size limits, parser timeouts, worker isolation, memory and CPU quotas, upload rate limits, and queue backpressure.
• Review application, web server, API gateway, job worker, and container metrics for historical spikes in XML parsing errors, 5xx responses, CPU saturation, memory pressure, and worker timeouts.
• Create detection rules for repeated requests or files containing more than one XML declaration and correlate with application errors or resource exhaustion.
• Because this is not KEV-listed, has low EPSS, and has no known exploit maturity in the provided data, handle as a normal-priority availability patch unless the organization exposes untrusted XML parsing on critical or internet-facing services.