REDHAT-BUG-2543949: Medium severity Gnome libsoup vulnerability

Published Sep 30, 2026

Updated

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

1 affected component

Gnome libsoup=3.7.1

Event History

Sep 30, 2026

Data Sourced

via Red Hat·02:45 PM

DescriptionSeverityAffected Software

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.

REDHAT-BUG-2543949: Medium severity Gnome libsoup vulnerability

Affected Software

Event History

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to exploit it?

How can I determine whether my application is affected?

Is a fixed release available?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to exploit it?

How can I determine whether my application is affected?

Is a fixed release available?