REDHAT-BUG-2543949: Medium severity Gnome libsoup vulnerability
HTTP/1 request-smuggling desync in SoupServer: when a client sends Expect: 100-continue with a Content-Length body and SoupServer emits an early final (non-1xx) response before reading the body (e.g. 401 from SoupAuthDomain, or any handler that sets a final status at the headers stage), libsoup marks the read side DONE without draining the declared body bytes and without sending Connection: close. On a keep-alive connection those leftover body bytes are then parsed as the next HTTP request, so a complete second request placed in the body is smuggled and executed (CWE-444 / RFC 9112 framing violation).
Verified upstream on libsoup 3.7.1 / current HEAD: one crafted connection to an auth-protected path yields 401 then 200, and the smuggled handler runs. Defect location: libsoup/server/http1/soup-server-message-io-http1.c iowrite() STATEHEADERS Expect: 100-continue path (readstate -> DONE without drain/close).
Distinct from CVE-2026-1760 (chunked + keep-alive close) and CVE-2026-1801 (malformed chunk headers). Upstream: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/539. Reporter: Jianqiang (Stark) Li. Embargo: No. Patch discussed upstream; fixed release not yet shipped.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using SoupServer over HTTP/1 keep-alive connections are exposed when a request with Expect: 100-continue and a Content-Length body can receive an early final response before the body is read. Examples include an auth-protected path returning 401 through SoupAuthDomain or a handler that sets a final status while processing headers.
What does an attacker need to exploit it?
An attacker needs to send a crafted request on a single persistent connection with Expect: 100-continue, a declared Content-Length body, and a complete second HTTP request placed in the unread body bytes. The initial request must trigger an early non-1xx final response, after which the leftover bytes are parsed as the next request.
How can I determine whether my application is affected?
Test an HTTP/1 keep-alive connection to an endpoint that returns an early final response, such as a 401 for an auth-protected path. If a request with Expect: 100-continue and a Content-Length body containing a second complete request receives the early response and then causes the second handler to run, the application is affected.
Is a fixed release available?
No fixed release has been shipped. An upstream patch is under discussion.