A flaw was found in evolution-data-server. Calendar events containing a file:// URI in their ATTACH property automatically read the targeted local file, base64-encode its contents and upload it back to the server when the event is saved. There are no file path restrictions or checks to verify whether the attachment originally came from the server or was added locally. This allows an attacker with access to a shared CalDAV calendar to exfiltrate arbitrary files the user has access to when interacting with malicious calendar events.

A flaw was found in evolution-data-server. Calendar events containing a file:// URI in their ATTACH property automatically read the targeted local file, base64-encode its contents and upload it back to the server when the event is saved. There are no file path restrictions or checks to verify whether the attachment originally came from the server or was added locally. This allows an attacker with access to a shared CalDAV calendar to exfiltrate arbitrary files the user has access to when interacting with malicious calendar events. This vulnerability affects evolution-data-server versions 3.26 through 3.62.0 and is fixed in version 3.62.1.

A use-after-free flaw was found in mutter in the Wayland color-management ICC image-description path. A local attacker who can run a malicious Wayland client can destroy a wpimagedescriptionv1 resource while an asynchronous ICC file read is still in progress. When the read completes, the compositor uses the freed wlresource, writes into freed memory, and frees a pointer derived from that memory. This can crash the GNOME session and may allow arbitrary code execution within the compositor process.

Summary: client-triggered use-after-free of a wpimagedescriptionv1 wlresource in the async ICC path

Requirements to exploit: A local unprivileged Wayland client that can connect to the compositor's Wayland socket ($XDGRUNTIMEDIR/wayland-N), including Flatpak/Snap apps with Wayland access. The client binds wpcolormanagerv1, creates an ICC image description (createicccreator → seticcfile → create), then destroys the wpimagedescriptionv1 resource while the asynchronous ICC file read is still in flight (create+destroy can be batched in one sendmsg). No elevated privileges beyond normal session client access are required.

Component affected: mutter (src/wayland/meta-wayland-color-management.c — creatoricccreate / onicccreatebytesread)

Version affected (maintainer): >= 47.0, < 51.0 Version fixed (maintainer): 51.0

Code-path note: The vulnerable pattern (unowned creatoricc->imagedescresource used after destroy in onicccreatebytesread) is present from mutter 49.rc through 50.4. It is not present in 47.x/48.x. Fixed code (refcounted MetaWaylandImageDescription; resource cleared on destroy) is in 50.5 and 51.0.

Patch available: Yes Upstream fix: https://gitlab.gnome.org/GNOME/mutter/-/mergerequests/5313 Key commit: 86141ab75b23 ("wayland/color-management: Fix lifetime of ICC image description"), merged 2026-09-11 Upstream report: https://gitlab.gnome.org/GNOME/mutter/-/issues/5025 Embargo: No Acknowledgment: Calif.io, in collaboration with Anthropic

A flaw was found in Eye of GNOME (eog). A heap-based buffer overflow exists in the PNG metadata reader due to improper state handling when parsing split metadata chunks. A remote attacker could exploit this flaw by enticing a user into opening a specially crafted PNG file, potentially leading to arbitrary code execution or a Denial of Service (DoS) via application crash.

A heap buffer overflow vulnerability was found in Eye of GNOME (eog) in the PNG metadata reader component (eog-metadata-reader-png). The flaw exists in the handling of cHRM and gAMA chunk resume state during PNG file parsing. An attacker could exploit this by crafting a malicious PNG file that, when opened by a victim, triggers the overflow, potentially leading to arbitrary code execution or a denial of service.

Upstream issue: https://gitlab.gnome.org/GNOME/eog/-/issues/342

Reporter: Jim Alves-Foss 1. Upstream: https://gitlab.gnome.org/GNOME/gimp/-/workitems/16801 (Finding 1). plug-ins/common/file-xmc.c, loadthumbnail() (~1032–1046): pixel buffer sized with 32-bit width height can wrap; GEGL then reads past the allocation. ASan-confirmed heap-buffer-overflow read. Vector: open/preview crafted X cursor (XMC) file (thumbnail path). Verified on GIMP 3.2.6; unpatched at report. CVSS 3.1 tentative: AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H (5.5).

A flaw was found in SoupServer (libsoup). When an HTTP/1.x client sends a request with Expect: 100-continue and a request body, and SoupServer returns an early final (non-1xx) response before the body is read, the server neither drains the declared body bytes nor closes the connection. On a keep-alive connection, those leftover bytes are interpreted as a subsequent HTTP request. A remote, unauthenticated attacker can place a complete HTTP request in the body and cause SoupServer to process that smuggled request, leading to unintended request handling.

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.

A flaw was found in libsoup. When the permessage-deflate WebSocket extension compresses a very large outgoing message, truncated size calculations used for GByteArray growth could wrap, causing zlib to write past the allocated buffer and resulting in a heap buffer overflow.

A heap buffer overflow was found in libsoup's WebSocket permessage-deflate outgoing path.

soupwebsocketextensiondeflateprocessoutgoingmessage() stored deflateBound()'s uLong result in a guint and grew a GByteArray by that amount. For payloads approaching 4 GiB, the bound exceeds GMAXUINT; truncation allowed buffer->len + maxlength to wrap on later growth, and zlib wrote through nextout past the allocation.

Fixed by refusing payloads whose compressed bound cannot fit in a GByteArray and by checking each incremental growth (commit dbd0417e, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 8) https://gitlab.gnome.org/GNOME/libsoup/-/commit/dbd0417e

A flaw was found in libsoup. When constructing a masked WebSocket client frame for a very large outgoing payload, size values passed to GByteArray allocation APIs could be truncated while the masking routine still used the full length, causing a heap buffer overflow.

A heap buffer overflow was found in libsoup's client-side WebSocket frame construction / masking path.

Outgoing frames are built in a GByteArray. For a send payload larger than the array can represent (at/above ~2^31), gbytearraysizednew() / append truncated the length while xorwithmask() still iterated the full attacker-/caller-controlled length, writing past the small allocation during masking.

Fixed by rejecting outgoing payloads above MAXOUTGOINGPAYLOADSIZE both before and after extensions process the payload (commit d7f074f8, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 7) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d7f074f8

A flaw was found in libsoup. When max-incoming-payload-size is unlimited (0), SoupWebsocketConnection could grow its incoming GByteArray based on an attacker-controlled frame length until the length wrapped, causing a heap buffer overflow while reading frame data.

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

A flaw was found in libsoup. When reassembling fragmented WebSocket messages into a GByteArray, libsoup did not adequately cap total message size against the limits of the underlying buffer type. A remote peer could send fragments that caused size truncation while the implementation still used the full length, leading to heap corruption or a crash.

A heap buffer overflow was found in libsoup WebSocket fragmented-message reassembly.

Reassembled messages are stored in a GByteArray (length typed as guint). A sequence of fragments (or extension expansion) that grew the message past GMAXINT caused gbytearraysetsize() / related growth APIs to truncate the size while surrounding code continued to use the full length, corrupting the heap. Upstream notes interaction with older GLib (e.g. 2.70) growth behavior.

Fixed by rejecting reassembly that would exceed what a GByteArray can safely hold, independently of max-total-message-size (commit d7f074f8, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 5) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d7f074f8

A flaw was found in libsoup. When handling an incoming WebSocket Pong frame, SoupWebsocketConnection emitted the ::pong signal with a GByteArray pointer even though the signal is declared to pass a GBytes. Applications connecting a handler that follows the documented GBytes API can trigger heap corruption or a crash upon receiving a crafted Pong.

A type-confusion heap overflow was found in libsoup's WebSocket Pong handling.

SoupWebsocketConnection::pong is declared to deliver a GBytes payload, but receivepong() emitted a GByteArray pointer via gsignalemit() and then unreffed the GByteArray. Handlers that treated the argument as GBytes (as documented) operated on the wrong object layout, resulting in heap memory corruption / overflow conditions under ASan.

Fixed upstream by converting the buffer with gbytearrayfreetobytes() before emission (commit d2cbaf25, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 2) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d2cbaf25

A flaw was found in libsoup. The soupuridecodedatauri() function incorrectly treated base64 data-URI payloads as NUL-terminated strings when calling gbase64decodeinplace(). If the percent-decoded payload contained embedded NUL bytes, the decoded length could remain uninitialized and be used as the size of the returned GBytes. This can lead to an out-of-bounds read or application crash when processing a crafted data URI.

A heap buffer overflow condition was found in libsoup's soupuridecodedatauri().

After percent-decoding a data URI payload marked ;base64, the code called gbase64decodeinplace(), which measures input with strlen(). Percent-decoded content can contain embedded NUL bytes (for example data:;base64,A%00B), so the measured length was too short. gbase64decodeinplace() returned without writing a valid output length; the uninitialized length was then stored as the size of the returned GBytes, allowing callers to read past the allocation.

Fixed upstream by decoding with gbase64decodestep() using the real buffer length (commit e4f03226, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 1) https://gitlab.gnome.org/GNOME/libsoup/-/commit/e4f03226

A heap use-after-free flaw was found in Gnumeric. When a user opens a crafted Gnumeric workbook containing a malformed SheetObjectComponent element, the XML parser can dereference a freed sheet-object component, causing Gnumeric to crash.

NetworkManager-l2tp through 1.52.4, fixed in 1.52.6, contains a privilege escalation vulnerability that allows local users with permission to create VPN connections to execute arbitrary code as root by injecting pppd options through a crafted VPN username. Attackers can embed a double-quote character or whitespace in the username to break out of the pppd options file quoting context and include the pppd plugin directive, causing the privileged pppd process to load an attacker-controlled shared object.

A denial-of-service flaw was found in gnome-remote-desktop. An unauthenticated remote attacker can open RDP connections without completing the handshake and retain the connection-throttling slots indefinitely because no pre-authentication handshake deadline is enforced. By exhausting the global connection limit, an attacker can prevent new RDP clients from connecting until a holding socket is closed.

A denial-of-service flaw was found in gnome-remote-desktop's RDP connection throttling. GrdThrottler charges an accepted TCP connection against the per-source and global connection limits before authentication, but no absolute deadline requires the peer to complete the RDP handshake. An unauthenticated remote attacker can therefore keep admitted sockets open indefinitely and retain all available slots. With the default limits, an attacker able to connect from two source IP addresses can hold five connections from each address, exhaust the ten global slots, and prevent new RDP handshakes until a holding connection closes. This is an incomplete resource-exhaustion fix for CVE-2025-5024. The issue begins with the introduction of GrdThrottler in commit 959cd39a and affects releases from 50.beta onward, including 50.0 through 50.2 and the reviewed 51 prereleases and main branch. Existing authenticated sessions were not shown to terminate, and no confidentiality, integrity, or code-execution impact is claimed. The upstream report includes a reproducer and reports no released fix at the time of filing. Reported to Red Hat through PSIRTSUPT-24484.

A flaw was found in librsvg. When processing an SVG document containing nested XML inclusions (Xincludes) with duplicate entity declarations, a use-after-free error can occur. This vulnerability arises because the library incorrectly frees an XML entity that is still in use by the parser. An attacker could potentially exploit this to cause a denial of service or execute arbitrary code.

Librsvg uses libxml2, a C library, to parse XML. When librsvg parses an SVG document which has a nested Xinclude, an XML entity declaration with a duplicate name as an existing one can cause a use-after-free error.

While libxml2 is expanding an internal entity, a recursive XInclude can parse another document that declares an entity with the same name. Both parses use the same XmlState entity map on the librsvg side. entityinsert() replaces the first entry, whose Drop implementation calls xmlFreeNode(). The outer xmlCtxtParseEntity() then keeps using the freed 144-byte xmlEntity.

The included parse should not free an entity that the outer parser is still using.

The fix is in commit 8a1b0cd319e9af2d1e9cf878081dd77f227a0504, where librsvg will no longer free xmlEntity pointers that libxml2 is still using.

A flaw was found in GNOME Shell. When processing icons from a remote search provider via D-Bus, the system fails to validate the icon's declared dimensions against the actual data buffer size. A malicious or compromised remote search provider could exploit this by providing oversized icon dimensions, leading to an out-of-bounds read. This can cause the GNOME Shell process to crash, disrupting the user's session, and potentially disclose sensitive information from adjacent memory.

A flaw was found in GNOME Shell's remote search integration. When rendering an icon supplied by a remote search provider over D-Bus, the icon's declared width, height, and row stride are passed to Shell.utilcreatepixbuffromdata() without validating that this geometry is consistent with the actual size of the supplied data buffer. A malicious or compromised search provider can advertise icon dimensions larger than its actual buffer, causing GNOME Shell to read past the end of the buffer when constructing the pixbuf for display. This out-of-bounds read can crash the GNOME Shell process, disrupting the user's session, and could potentially expose adjacent heap memory contents through the rendered icon.

A flaw was found in the admin backend of gvfs. The privileged gvfsd-admin daemon changes the ownership of newly created private D-Bus sockets by calling the link-following chown() function on a pathname inside a user-controlled directory. A local attacker can exploit this via a Time-of-Check Time-of-Use (TOCTOU) race condition and exchange the socket pathname with a symbolic link pointing to an arbitrary root-owned file (such as /etc/pam.d/su). The daemon subsequently follows the symlink and changes the ownership of the targeted root-owned file to the attacker's user ID. This allows an authenticated local attacker to modify critical system files, leading to a full local privilege escalation to root.