Description

An algorithmic complexity flaw exists in libsoup's HTTP Range header processing that persists after the CVE-2025-32907 fix. CVE-2025-32907 addressed memory amplification when a client repeated the same range many times in a single Range header. Commit 9bb92f7a corrected merge correctness in soup_message_headers_get_ranges_internal() in libsoup/soup-message-headers.c, but the coalescing loop still removes merged ranges using g_array_remove_index() for each coalesced element. Because GArray is contiguous, each mid-array removal performs an O(N) memmove. When many identical satisfiable ranges are supplied (for example bytes=0-0 repeated thousands of times), the loop performs O(N²) work coalescing them into a single range. The vulnerable path is reachable server-side from handle_partial_get() in libsoup/server/http1/soup-server-message-io-http1.c when a SoupServer handler returns HTTP 200 with a non-empty body. No authentication is required. The number of ranges is bounded only by the maximum request header size (~100 KiB), allowing roughly 25,000 ranges per request. Reporter measurements on libsoup HEAD containing the CVE-2025-32907 fix show ~90 ms single-core CPU per such request at the wire maximum, blocking the server's event loop for that duration. This is a CPU exhaustion / availability issue only. No memory corruption or information disclosure occurs. Affected: libsoup versions containing the CVE-2025-32907 fix but not merge request !550. Fixed upstream: MR !550 merged 2026-08-20, replacing per-element removal with O(N) in-place compaction and rejecting Range headers requesting more than 200 ranges. Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/issues/538 Related: CVE-2025-32907

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-25T21:17:46.243Z",
  "pubdate": "2026-08-25T21:17:46.243Z",
  "executiveSummary": "A CPU exhaustion vulnerability exists in libsoup due to inefficient processing of HTTP Range headers, persisting as an algorithmic complexity flaw despite the previous CVE-2025-32907 patch. The vulnerability allows an unauthenticated remote attacker to trigger O(N²) computational complexity by submitting a specially crafted HTTP Range header containing thousands of redundant, identical ranges.\nThe vulnerability resides in the coalescing logic within libsoup/soup-message-headers.c. When the library processes a Range header containing a large volume of ranges, the underlying GArray implementation performs O(N) memmove operations for every individual range coalesced. With up to 25,000 ranges permissible within the standard 100 KiB request header limit, a single request can block the server's event loop for approximately 90ms on a single core.\nThis represents a significant Denial of Service (DoS) risk, as an attacker can monopolize server threads or the main event loop by sending a series of these requests, effectively rendering the service unavailable to legitimate traffic. No memory corruption, privilege escalation, or information disclosure is associated with this flaw; it is strictly an availability issue affecting server-side request handling.",
  "technicalDetails": "The root cause of this vulnerability is the inefficient removal of elements from a GArray during the coalescing phase of HTTP Range header processing in soup_message_headers_get_ranges_internal() within libsoup/soup-message-headers.c. While CVE-2025-32907 addressed memory amplification, it introduced a logic flow where the coalescing loop calls g_array_remove_index() repeatedly to handle merged ranges. Because GArray is a contiguous memory structure, g_array_remove_index() forces the library to perform a memmove operation of all subsequent elements for every removal.\nWhen a malicious payload includes thousands of identical, satisfiable ranges (e.g., 'bytes=0-0' repeated iteratively), the algorithm performs an O(N²) series of operations. Given that the HTTP specification and libsoup configuration allow for header sizes up to 100 KiB, an attacker can pack approximately 25,000 distinct ranges into a single request. The resulting processing latency blocks the libsoup server's event loop.\nThe attack flow begins when an attacker sends a malicious HTTP request to a libsoup-based server. The request is processed by handle_partial_get() in libsoup/server/http1/soup-server-message-io-http1.c. If the handler returns an HTTP 200 status code with a non-empty body, the internal range parsing logic is triggered. Because no authentication is required to initiate this request, the attack surface is fully exposed to the public network. The payload behavior is strictly CPU-bound; it does not involve heap overflow or memory corruption, focusing entirely on resource exhaustion.\nIn versions of libsoup containing the CVE-2025-32907 fix but lacking the modifications introduced in MR !550, the lack of a limit on the number of processed ranges combined with the suboptimal array management creates a trivial vector for resource depletion. Successful exploitation forces the server to spend excessive CPU cycles on redundant data structures, preventing the processing of concurrent legitimate requests. The fix implemented in MR !550 addresses this by replacing the per-element deletion strategy with an O(N) in-place compaction algorithm and implementing a strict upper limit (200) on the number of allowed ranges per request, effectively neutralizing the complexity attack."
}