A flaw was found in libsoup. A malicious HTTP/2 server or a Man-in-the-Middle (MITM) attacker can exploit a heap use-after-free vulnerability in the HTTP/2 client implementation. This occurs when a GNOME application uploads a file using HTTP/2, and the server sends a GOAWAY frame while the file body is being read asynchronously. This can lead to memory corruption, potentially resulting in information disclosure or arbitrary code execution.

A heap use-after-free vulnerability exists in libsoup's HTTP/2 client implementation. When a GNOME application sends an HTTP/2 POST request with a file body (using a non-pollable GInputStream such as GFileInputStream), the body data is read asynchronously via ginputstreamreadasync(). If the remote HTTP/2 server sends a GOAWAY frame while this async read is pending, the SoupHTTP2MessageDatastructure is freed through the shutdown path, but the async read callback ondataread() still fires afterward, accessing the freed heap memory.

This is a remotely-triggerable heap use-after-free — a malicious HTTP/2 server (or MITM attacker) can deterministically trigger it when any GNOME application uploads a file over HTTPS with HTTP/2. Affected applications include GNOME Web (Epiphany), GNOME Software, Flatpak, and any GLib-based application using SoupSession for HTTP/2 file uploads.

Impact type: Heap use-after-free (CWE-416) — the freed 168-byte SoupHTTP2MessageData struct is read after free, and the freed datasourcebuffer may also be written to by the still-pending async I/O operation. This constitutes memory corruption with potential for information disclosure or code execution.

A flaw was found in libsoup. The HTTP/2 client request-body path for non-pollable GInputStream sources buffers an asynchronous read sized to the current flow-control window, then later copies that entire buffer into nghttp2's DATA callback buffer without clamping to the callback length. A malicious HTTP/2 server can send a SETTINGS frame that reduces SETTINGSINITIALWINDOWSIZE while that read is in flight, making the next DATA callback length smaller than the already-buffered byte count. The only check is a gassert(), which aborts the client in typical builds. If assertions are compiled out, nghttp2 rejects a return value larger than the allowed length and fails the session.

A flaw was found in libsoup's SoupServer HTTP Range header processing. The sortranges() comparator function in soup-message-headers.c returns the difference of two goffset (64-bit) values as an int (32-bit). When two range start positions in a multi-range request differ by more than INTMAX (~2.1 billion), the truncation flips the comparison result sign, violating qsort's ordering contract. The mis-sorted ranges are then incorrectly merged, causing the server to silently omit requested byte ranges from the HTTP 206 Partial Content response. A remote unauthenticated attacker can trigger this by sending a multi-range Range request for a resource larger than approximately 2 GB, with range start offsets more than INTMAX apart. The client receives fewer ranges than requested with no error indication, compromising data integrity for resumable downloads, delta updates, mirror synchronization, and chunked verification of large objects.

A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests.

A flaw was identified in the NTLM authentication handling of the libsoup HTTP library, used by GNOME and other applications for network communication. When processing extremely long passwords, an internal size calculation can overflow due to improper use of signed integers. This results in incorrect memory allocation on the stack, followed by unsafe memory copying. As a result, applications using libsoup may crash unexpectedly, creating a denial-of-service risk.

A stack-based buffer overflow vulnerability exists in the md4sum() function of libsoup’s NTLM authentication module (SoupAuthNTLM). When NTLM authentication is enabled, insufficient bounds checking on stack-allocated buffers can allow a local attacker to overwrite adjacent memory. This may result in arbitrary code execution with the privileges of the affected application. Multiple widely deployed components, including WebKit, Evolution, GVfs, and gnome-online-accounts, enable NTLM by default, increasing exposure.

A flaw was found in libsoup. This stack-based buffer overflow vulnerability occurs during the parsing of multipart HTTP responses due to an incorrect length calculation. A remote attacker can exploit this by sending a specially crafted multipart HTTP response, which can lead to memory corruption. This issue may result in application crashes or arbitrary code execution in applications that process untrusted server responses, and it does not require authentication or user interaction.

Stack-based buffer overflow vulnerability in libsoup’s multipart/form-data response parsing logic. The flaw exists in the soupfilterinputstreamreaduntil() function, where an incorrect length calculation may cause more data to be copied than the size of the caller-provided buffer. When a specially crafted multipart HTTP response is processed, libsoup can write past the end of a stack buffer, resulting in memory corruption. This issue can be triggered remotely without authentication or user interaction, potentially leading to application crashes or arbitrary code execution in applications that parse untrusted server responses.

Vulnerability Reference:

An out-of-bounds (OOB) read flaw was discovered in libsoup's multipart input streaming parser, allowing a remote attacker to trigger a crash or potentially expose sensitive memory contents.

Component / Vulnerable Part:

libsoup -> Multipart handling engine (libsoup/soup-multipart-input-stream.c -> soupmultipartinputstreamreadheaders())

Technical Analysis & Root Cause:

When an application utilizing a SoupSession parses a multipart MIME message response, it invokes soupmultipartinputstreamreadheaders() to extract contextual block structures. A validation vulnerability exists where the logic fails to enforce strict length limits on the incoming boundary string delimiter. If a malicious remote endpoint supplies an exceptionally large multipart boundary string, the internal memory pointer indexing calculations drift past the expected buffer boundaries, triggering an out-of-bounds read operation on the heap or stack layout.

Impact:

A remote, unauthenticated attacker serving a malformed multipart HTTP payload can cause the application process to terminate unexpectedly (Denial of Service) via a segmentation fault or glean layout information from adjacent memory locations.

A memory management flaw was discovered in libsoup’s HTTP/2 connection pooling engine that can be weaponized to cause a remote denial of service (DoS).

Component / Vulnerable Part:

libsoup -> HTTP/2 connection state machine (soup-client-message-io-http2.c / stream cleanup logic)

Technical Analysis & Root Cause:

When executing multi-stream HTTP/2 requests, libsoup establishes memory tracking for active data stream windows. A flaw exists in the handling of stream tear-downs or window exhaustion events (such as tracking partial frames or receiving distinct reset signals like RSTSTREAM under specific timing conditions). The internal structure fails to properly free the memory allocated for the stream context or metadata structures upon premature closure. By opening and causing abrupt failures across many concurrent streams, the allocated buffer descriptors remain unfreed in the heap pool.

Impact:

A remote attacker operating a malicious HTTP/2 server can induce a creeping memory leak on the client process. Over multiple continuous requests, this systematic leakage exhausts the application's available memory space, eventually causing a fatal crash due to an Out-of-Memory (OOM) event.

Vulnerability Reference:

A flaw in libsoup's WebSocket implementation allows a remote attacker to trigger a denial of service (DoS) by exploiting a protocol validation failure.

Component / Vulnerable Part:

libsoup -> libsoup/websocket/soup-websocket-connection.c (Control frame parser)

Technical Analysis & Root Cause:

Per RFC 6455 §5.5, WebSocket control frames (PING, PONG, CLOSE) must not exceed a payload length of 125 bytes and cannot be fragmented. libsoup's frame parsing logic fails to immediately reject non-compliant control frames exceeding this limit. When an oversized control frame is received, the unexpected state disrupts the state machine or triggers an unhandled execution error, forcing the library to abruptly crash.

Impact:

A remote, unauthenticated attacker (client or server) can send a single malformed, oversized control frame to instantly terminate the connection wrapper, resulting in a remote denial of service for any application using libsoup WebSockets.

A flaw in libsoup’s permessage-deflate WebSocket extension allows a remote attacker to cause a Denial of Service via memory exhaustion. The internal inflate() loop resizes its buffer dynamically without enforcing an upper limit during decompression. Because size checks are either performed only on the compressed wire-payload or executed too late (after inflation completes), a small decompression bomb can trigger an immediate Out-of-Memory (OOM) crash on both client and server applications.

A flaw was found in libsoup's HTTP/2 protocol parsing logic where processing malformed network frames can trigger a heap buffer over-read condition.

Component / Vulnerable Part:

libsoup -> HTTP/2 connection processing backend (soup-client-message-io-http2.c or similar HTTP/2 state engine components handling GOAWAY frames).

Technical Analysis & Root Cause:

When an HTTP/2 session receives a GOAWAY frame, the frame can contain an optional "Additional Debug Data" payload field. The libsoup library erroneously treats this debug data block as a standard, safely NUL-terminated C-string without explicitly verifying the payload length boundaries provided by the framing layer. If a remote peer constructs a malicious GOAWAY frame containing a debug string that lacks a terminating \0 byte within the bounds of the frame allocation, internal string functions will read past the allocated heap space looking for the delimiter.

Impact:

A remote attacker acting as a malicious HTTP/2 endpoint can transmit a specially crafted GOAWAY frame to read out-of-bounds heap memory. This results in an immediate application crash (Denial of Service) or potential information disclosure of adjacent memory metadata.

A flaw was identified in libsoup, a widely used HTTP library in GNOME-based systems. When processing specially crafted HTTP Range headers, the library may improperly validate requested byte ranges. In certain build configurations, this could allow a remote attacker to access portions of server memory beyond the intended response. Exploitation requires a vulnerable configuration and access to a server using the embedded SoupServer component.

A flaw was found in libsoup, an HTTP client/server library. This HTTP Request Smuggling vulnerability arises from non-RFC-compliant parsing in the soupfilterinputstreamreadline() logic, where libsoup accepts malformed chunk headers, such as lone line feed (LF) characters instead of the required carriage return and line feed (CRLF). A remote attacker can exploit this without authentication or user interaction by sending specially crafted chunked requests. This allows libsoup to parse and process multiple HTTP requests from a single network message, potentially leading to information disclosure.

A flaw was found in libsoup. An attacker who can control the input for the Content-Disposition header can inject CRLF (Carriage Return Line Feed) sequences into the header value. These sequences are then interpreted verbatim when the HTTP request or response is constructed, allowing arbitrary HTTP headers to be injected. This vulnerability can lead to HTTP header injection or HTTP response splitting without requiring authentication or user interaction.

Out-of-bounds read vulnerability in the handlepartialget() function of libsoup when processing HTTP Range headers. The issue occurs because the end value of the byte range is not properly validated against the total response size. If GLib is compiled with GDISABLECHECKS, the call to gbytesnewfrombytes() may create a slice that exceeds the bounds of the original buffer. A specially crafted HTTP request with a large range value can cause heap memory beyond the intended response body to be returned to the attacker. This vulnerability can be triggered remotely without authentication or user interaction, potentially exposing portions of server heap memory.

libsoup accepts duplicate Host: headers and implements a last-value-wins policy when soupmessageheadersgetone[common] is used to construct the request URI, while many proxies and routers use the first Host: header for routing. The provided PoC reliably demonstrates that a proxy honoring the first Host: can route to backend A but the libsoup server will interpret the request as for host B (last header), enabling virtual-host confusion and potential bypasses of host-based ACLs or cache poisoning.

CRLF injection vulnerability in the soupmessageheaderssetcontentdisposition() function of the libsoup HTTP library. The issue occurs because this function internally uses soupmessageheadersappendcommon(), which does not enforce character restrictions on header values. As a result, an attacker who can control the input used for the Content-Disposition header can inject CRLF sequences into the header value. When the HTTP request or response is later constructed, these sequences are interpreted verbatim, allowing arbitrary HTTP headers to be injected. This can lead to header injection or HTTP response splitting without authentication or user interaction.

libsoup prior to version 3.6.5 is vulnerable to a heap buffer over-read in the content sniffer's skipinsignificantwhitespace() function. libsoup clients may read one byte out of bounds in response to a crafted HTTP response sent by an HTTP server.

libsoup's SoupWebsocketConnection limits the size of incoming packets but not the size of WebSocket messages. A malicious peer may cause libsoup to allocate large amounts of memory by sending large messages consisting of many smaller packets.

libsoup prior to 3.6.2 is vulnerable to a null pointer dereference in soupmessageheadersgetcontentdisposition() . A malicious HTTP peer may crash a libsoup client or server that uses this function.

libsoup prior to 3.6.5 is vulnerable to out of bounds reads in soupheadersparserequest(). A maliciously-crafted HTTP request may crash the HTTP server.

libsoup is vulnerable to an out of bounds read in soupmultipartnewfrommessage(). A malicious HTTP client may induce the libsoup server to read out of bounds.

libsoup prior to version 3.6.3 is vulnerable to a free of memory not on the heap in soupmessageheadersgetcontentdisposition(). A malicious HTTP client may induce memory corruption in the libsoup server.

Integer Underflow (Wraparound) vulnerability in the multipart message parser of the libsoup HTTP library. The flaw is caused by an unsafe arithmetic operation in the soupmultipartnewfrommessage() function. When a specially crafted multipart message is processed, the length calculation (end - 2 - split) can underflow, leading to invalid memory access and application crash. This can be exploited remotely without any authentication or user interaction, allowing attackers to disrupt the availability of applications or services using libsoup.

When encountering an HTTP redirect, libsoup clients prior to version 3.6.5 send the HTTP Authorization header to the host that is the target of the redirection, allowing this host to impersonate the user to the host that performed the redirect.

GNOME libsoup before 3.6.0 allows HTTP request smuggling in some configurations because '\0' characters at the end of header names are ignored, i.e., a "Transfer-Encoding\0: chunked" header is treated the same as a "Transfer-Encoding: chunked" header.

GNOME libsoup before 3.6.1 has an infinite loop, and memory consumption. during the reading of certain patterns of WebSocket data from clients.