- CVE-2026-102555: decode base64 data: URI content with g_base64_decode_step() over the real buffer length in soup_request_data_send(), so a percent-encoded NUL no longer truncates the payload, leaks the decode buffer and raises a GLib-CRITICAL - CVE-2026-102556: emit the WebSocket ::pong signal with a GBytes, as the signal and the public header have always declared, instead of a GByteArray, removing the type confusion a crafted Pong frame could turn into heap corruption in any handler that honours the documented API - CVE-2026-102557: cap a reassembled WebSocket message at what a GByteArray can hold before each fragment is appended in process_contents(), so a run of fragments can no longer truncate the guint size passed to g_byte_array_sized_new()/g_byte_array_append() while the full length is used - CVE-2026-102558: reject an incoming frame whose declared payload exceeds what the receive buffer can represent as soon as the header is parsed, so the incoming GByteArray can no longer grow until g_byte_array_set_size() wraps and the read writes past the allocation - CVE-2026-102559: reject an outgoing payload above MAX_OUTGOING_PAYLOAD_SIZE in send_message(), both before and after extensions have processed it, so a masked client frame can no longer be built in a truncated GByteArray while xor_with_mask() writes the full payload length past the allocation - CVE-2026-102560: refuse an outgoing permessage-deflate payload whose deflateBound() exceeds G_MAXUINT and bound every incremental buffer growth, so a truncated bound can no longer let zlib write past the allocated GByteArray