REDHAT-BUG-2543274: Buffer Overflow

Published Sep 29, 2026
·
Updated

A heap buffer overflow was found in libsoup's WebSocket incoming receive buffer handling.

Incoming frames are accumulated in a GByteArray. With max-incoming-payload-size set to 0 (unlimited), a peer could declare a multi-GiB payload and stream it until the buffer length wrapped in gbytearraysetsize() while the read still targeted the original offset, writing past the allocation.

Fixed by rejecting payload lengths above what the receive buffer can represent as soon as the frame header is parsed, before buffering the payload (commit 381a474f, libsoup 3.7.3). Such frames are closed as SOUPWEBSOCKETCLOSETOOBIG.

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 6) https://gitlab.gnome.org/GNOME/libsoup/-/commit/381a474f

Affected Software

1 affected component
Gnome libsoup<3.7.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade libsoup to a version that resolves this vulnerability.

    Fixed in 3.7.3

Event History

Sep 29, 2026
Data Sourced
via Red Hat·04:08 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Which deployments are exposed to this issue?

Deployments using libsoup WebSocket handling with max-incoming-payload-size set to 0, meaning unlimited incoming payload size, are exposed. A peer must be able to send WebSocket frames to the affected endpoint.

2

What does an attacker need to send to trigger the overflow?

The attacker needs to declare a multi-GiB WebSocket payload and continue streaming data until the receive buffer length wraps during resizing. The vulnerable path occurs while incoming frames are accumulated in a GByteArray.

3

What behavior changes after the fix?

The fix rejects payload lengths larger than the receive buffer can represent when the frame header is parsed, before payload buffering begins. These frames are closed with SOUP_WEBSOCKET_CLOSE_TOO_BIG.

4

What can be done if the fixed version cannot be deployed immediately?

Avoid configuring max-incoming-payload-size as 0 (unlimited) and enforce a finite incoming WebSocket payload limit. This prevents the unlimited-payload condition described for the vulnerable path.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203