Hi,

The following vulnerability was published for libsoup3.

CVE-2025-32049[0]:
| A flaw was found in libsoup. The SoupWebsocketConnection may accept
| a large WebSocket message, which may cause libsoup to allocate
| memory and lead to a denial of service (DoS).


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2025-32049
https://www.cve.org/CVERecord?id=CVE-2025-32049
[1] https://gitlab.gnome.org/GNOME/libsoup/-/issues/390
[2] https://gitlab.gnome.org/GNOME/libsoup/-/commit/5a83501544a7ff180a5f3490192a280252cd7d04

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Control: retitle -1 libsoup3: CVE-2025-32049: denial of service via memory exhaustion with large fragmented WebSocket messages
Control: found -1 3.0.4-1

I suspect that all versions are vulnerable to this, so I'm marking this
as found in the oldest upload of libsoup3 to Debian.

A mitigation has been proposed upstream but it takes the form of an
arbitrary limit, and the default is "no limit" due to compatibility
concerns: upstream wrote "We're not sure about the compatibility
implications of having a default size limit for clients". As a result,
applications that use libsoup will still be vulnerable to this (if they
use WebSockets) even after the proposed mitigation is merged, unless
they explicitly set a limit.

The merge request is also not suitable for merge because it contains
conflicts vs. subsequent upstream changes.

I suspect that upstream is not intending to fix this in 3.6.x at all,
only in 3.7.x via the addition of new API. I don't think we should rush
to address this in trixie, and definitely not in bookworm. The LTS team
seem to have come to a similar conclusion: they tried to backport the
proposed mitigation, but then reverted that change.

     smcv
     (a GNOME team member but not a libsoup expert)

Yes, the fix has recently landed in upstream's master branch intended
for the 3.7/3.8 series. It added new API so it isn't ideal for
cherry-picking.

This means that this won't be fixed in libsoup2.4 either since
libsoup2.4 isn't getting new development (and libsoup2.4 was already
removed from Debian Unstable).

Thank you,
Jeremy Bícha