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.

Summary: Path traversal in theme installer Requirements to exploit: user installs malicious gnome-shell theme Component affected: ShellThemeInstallerTweak Version affected: All versions Patch available: Yes Version fixed (if any already): Not yet Upstream coordination: See issue report (below) CVSS (optional): Impact (optional): Embargo: No Acknowledgment: Zach Sylvester Steps to reproduce if available: see issue report Mitigation if available: do not use gnome-tweaks to install gnome-shell themes Original report: https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/542

Summary: Path traversal in theme installer Requirements to exploit: user installs malicious gnome-shell theme Component affected: ShellThemeInstallerTweak Version affected: All versions Patch available: Yes Version fixed (if any already): Not yet Upstream coordination: See issue report (below) CVSS (optional): Impact (optional): Embargo: No Acknowledgment: Zach Sylvester Steps to reproduce if available: see issue report Mitigation if available: do not use gnome-tweaks to install gnome-shell themes Original report: https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/542

A flaw was found in libxml2 with Python bindings enabled. A remote attacker could exploit this vulnerability by providing a specially crafted XML document containing a Document Type Definition (DTD) with enumerated attribute values. This triggers a double-free error in the SAX attributeDecl callback handler, where a string is freed twice. This flaw can lead to a denial of service (DoS) due to a reproducible crash in Python applications using the libxml2 SAX bindings.

SUMMARY A double-free / use-after-free exists in the SAX attributeDecl callback handler (pythonAttributeDecl in python/libxml.c). When parsing XML containing a DTD <!ATTLIST> declaration with enumerated attribute values, each value string is freed twice: PyListSetItem() steals the reference, and an explicit PyDECREF() then drops the refcount to zero and frees the object, leaving a dangling pointer in the list.

AFFECTED COMPONENT

libxml2 with Python bindings enabled (python3-libxml2 / libxml2-python)

The defect is long-standing; the affected code in pythonAttributeDecl has been unchanged for many years.

Reproduced on upstream commit 4b35628e97472eaf23d8a841d2f711f7c2f96255 (2026-02-24).

IMPACT

Denial of service: 100% reproducible crash (SIGSEGV) in any Python application that uses the libxml2 SAX bindings (libxml2.createPushParser), registers an attributeDecl handler, and parses untrusted XML with a DTD <!ATTLIST> containing enumerated values. Verified 10/10 in isolated processes.

The use-after-free is also potentially exploitable for code execution: I was able to demonstrate hijacking the freed object's tpdealloc function pointer in-process. Full remote code execution would require additional heap grooming and is not demonstrated. I'd defer to your team on final severity scoring; I'd characterize the reliably demonstrated impact as DoS, with code execution as a credible but conditional escalation.

ROOT CAUSE (python/libxml.c, pythonAttributeDecl)

for (node = tree; node != NULL; node = node->next) { newName = PYIMPORTSTRING((char ) node->name); PyListSetItem(nameList, count, newName); / steals reference / PyDECREF(newName); / double-free / count++; }

PyListSetItem() does not increment the refcount, so the subsequent PyDECREF() over-decrements. Because of CPython pymalloc free-list reuse, list entries can end up pointing at the same freed address; cleanup after the SAX callback then decrefs dangling pointers and corrupts allocator state.

PROOF OF CONCEPT (minimal DoS)

import libxml2 class Handler: def attributeDecl(self, args): pass def startElement(self, a): pass def endElement(self, a): pass def characters(self, a): pass xml = b'''<?xml version="1.0"?> <!DOCTYPE r [ <!ELEMENT r EMPTY> <!ATTLIST r a (xx|yy|zz|ww|qq) "xx"> ]> <r a="xx"/>''' h = Handler() c = libxml2.createPushParser(h, "", 0, "t") c.parseChunk(xml, len(xml), 1) # SIGSEGV

UPSTREAM FIX (already merged and closed)

Fix: remove the erroneous PyDECREF(newName) since PyListSetItem already takes ownership.

Merge request: https://gitlab.gnome.org/GNOME/libxml2/-/mergerequests/397 ("python: Do not decref string after adding to the list")

Fix commit: 046931e6

Issue report: https://gitlab.gnome.org/GNOME/libxml2/-/workitems/1076

Upstream maintainer Nick Wellnhofer confirmed it appears to be a security issue and asked that a CVE be requested; the maintainer who merged the fix indicated CVE assignment is not handled by the project itself.

SUGGESTED CLASSIFICATION

CWE-415 (Double Free), leading to CWE-416 (Use After Free)

ENVIRONMENT

OS: Ubuntu 22.04 x8664; Python 3.10.12; GCC 11.4.0; libxml2 built from source with -fsanitize=address.

I'm happy to provide the full ASan trace or the code-execution PoC on request. Please let me know if you need anything else to proceed.

Thank you, Adnan Jakati!https://mailtrack.io/trace/mail/773e02eeb348f92b41f2a5d93b4c46af0007ab1f.png?u=12519192!

Hi,

On Fri, Sep 04, 2026 at 06:35:56PM +0100, Sam James wrote: From libxml2-2.15.4:

+v2.15.4: Sep 01 2026 + +### Security + +- xmlregexp: Prevent out-of-bounds read in NXT macro +- fix: add missing overflow checks in dict.c, uri.c, and valid.c +- xmlregexp: Calc string length after null checking +- xpointer: Check overflow in xmlXPtrEvalXPtrPart +- xmlIO: Check for int overflow before calling writecallback +- fix(xinclude): propagate parseFlags in xmlXIncludeProcess and xmlXIncludeProcessTree + + [...]

I possess no further details. FTR, some CVEs got assigned for issues fixed in 2.15.4:

https://www.cve.org/CVERecord?id=CVE-2026-86137: | In libxml2 before 2.15.4, xmlFAParsePosCharGroup has an out-of-bounds | read, aka an out-of-bounds read in the NXT macro in xmlregexp.

https://www.cve.org/CVERecord?id=CVE-2026-86138 | In libxml2 before 2.15.4, xmlDictAddQString in dict.c has an integer | overflow and resultant heap-based buffer overflow.

https://www.cve.org/CVERecord?id=CVE-2026-86139 | In libxml2 before 2.15.4, xmlURIEscapeStr in uri.c has an integer | overflow.

https://www.cve.org/CVERecord?id=CVE-2026-86140 | In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat | stack-based buffer overflow.

https://www.cve.org/CVERecord?id=CVE-2026-86141 | xmlregexp in libxml2 before 2.15.4 has a NULL pointer dereference in | xmlRegNewParserCtxt after a strdup failure, i.e., it does not | calculate a string length after NULL checking.

https://www.cve.org/CVERecord?id=CVE-2026-86142 | In libxml2 before 2.15.4, there is a heap-based buffer overflow in | xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation.

https://www.cve.org/CVERecord?id=CVE-2026-86143 | In xmlIO in libxml2 before 2.15.4, an inconsistency in | xmlOutputWriteCallback and xmlBufUse causes negative lengths to reach | write callbacks, aka a lack of a check for integer overflow before | calling writecallback. This has security relevance for many types of | uses of that length value within a callback.

https://www.cve.org/CVERecord?id=CVE-2026-86144 | In xinclude in libxml2 before 2.15.4, xmlXIncludeProcess and | xmlXIncludeProcessTree do not propagate parseFlags. This has security | relevance for, for example, the XMLPARSENONET flag, if (without it) | a custom resource loader accesses the internet and triggers XML | external entity injection, SSRF, or a denial of service (e.g., for an | attacker-controlled internet resource that is intentionally slow).

Regards, Salvatore

xmlregexp in libxml2 before 2.15.4 has a NULL pointer dereference in xmlRegNewParserCtxt after a strdup failure, i.e., it does not calculate a string length after NULL checking.

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 the MTP backend in gvfs. When reading a file from a mounted MTP device, doread() in gvfsbackendmtp.c trusts the data length returned by the device without limiting it to the original size requested by the client. If a malicious MTP device responds with more bytes than requested, this unrestricted length is passed directly to memcpy(). This causes the operation to read memory outside the intended boundaries. This allows an attacker who plugs in a malicious MTP device to cause a segmentation fault when a file is read and crash the gvfsd-mtp process, resulting in a denial of service.

A flaw was found in the SFTP backend in gvfs. When mounting a share and reading a file, a malicious SFTP server can cause readreply() to process a length that exceeds the size requested by the client. The function does not verify the server-provided length against the allocated buffer size, causing the operation to write past the intended boundaries. This issue allows a malicious server to corrupt adjacent heap memory in the gvfsd-sftp process, resulting in a denial of service as the process aborts upon detecting the heap corruption or potentially allowing arbitrary code execution.

A flaw was found in the SFTP backend in gvfs. When mounting a share and reading a file, a malicious SFTP server can cause readreply() to process a length that exceeds the size requested by the client. The function does not verify the server-provided length against the allocated buffer size, causing the operation to write past the intended boundaries. This issue allows a malicious server to corrupt adjacent heap memory in the gvfsd-sftp process, resulting in a denial of service as the process aborts upon detecting the heap corruption or potentially allowing arbitrary code execution. This vulnerability affects all gvfs versions and is fixed in version 1.60.2.

A flaw was found in the SFTP backend in gvfs. When mounting a share, a malicious SFTP server can cause readstring() to allocate a buffer with a certain length but the function does not verify that the buffer is completely filled, leaving the remainder of the buffer containing uninitialized heap contents. If the server sends a short FXPHANDLE reply, these uninitialized bytes are taken as the file handle. The client will then echo these uninitialized bytes back to the server on all subsequent requests using that handle. With a length of 128 bytes, this issue allows the malicious server to deterministically read uninitialized heap memory from the gvfsd-sftp process, leaking its heap base and the load address of the libgio library, resulting in a deterministic defeat of Address Space Layout Randomization (ASLR).

A flaw was found in the SFTP backend in gvfs. When mounting a share, a malicious SFTP server can cause readstring() to allocate a buffer with a certain length but the function does not verify that the buffer is completely filled, leaving the remainder of the buffer containing uninitialized heap contents. If the server sends a short FXPHANDLE reply, these uninitialized bytes are taken as the file handle. The client will then echo these uninitialized bytes back to the server on all subsequent requests using that handle. With a length of 128 bytes, this issue allows the malicious server to deterministically read uninitialized heap memory from the gvfsd-sftp process, leaking its heap base and the load address of the libgio library, resulting in a deterministic defeat of Address Space Layout Randomization (ASLR). This vulnerability affects gvfs versions 1.10.0 and newer and is fixed in version 1.60.2.

A flaw was found in gdk-pixbuf. When loading a specially crafted JPEG image containing chunked ICC profile markers, an error during ICC profile parsing can leave stale size metadata after the profile buffer is freed. A subsequent allocation in the same decode can cause an out-of-bounds write, potentially crashing the application. To exploit this flaw, an application using gdk-pixbuf must process the malicious JPEG image.

Affected version >= 2.26.4

An algorithmic complexity flaw exists in libsoup's HTTP Range header processing that persists after the CVE-2025-32907 fix.

CVE-2025-32907 addressed memory amplification when a client repeated the same range many times in a single Range header. Commit 9bb92f7a corrected merge correctness in soupmessageheadersgetrangesinternal() in libsoup/soup-message-headers.c, but the coalescing loop still removes merged ranges using garrayremoveindex() for each coalesced element. Because GArray is contiguous, each mid-array removal performs an O(N) memmove. When many identical satisfiable ranges are supplied (for example bytes=0-0 repeated thousands of times), the loop performs O(N²) work coalescing them into a single range.

The vulnerable path is reachable server-side from handlepartialget() in libsoup/server/http1/soup-server-message-io-http1.c when a SoupServer handler returns HTTP 200 with a non-empty body. No authentication is required. The number of ranges is bounded only by the maximum request header size (~100 KiB), allowing roughly 25,000 ranges per request. Reporter measurements on libsoup HEAD containing the CVE-2025-32907 fix show ~90 ms single-core CPU per such request at the wire maximum, blocking the server's event loop for that duration.

This is a CPU exhaustion / availability issue only. No memory corruption or information disclosure occurs.

Affected: libsoup versions containing the CVE-2025-32907 fix but not merge request !550. Fixed upstream: MR !550 merged 2026-08-20, replacing per-element removal with O(N) in-place compaction and rejecting Range headers requesting more than 200 ranges. Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/issues/538 Related: CVE-2025-32907

A stack-based buffer overflow exists in file-roller's parseprogressline() functions in the 7z and RAR archive backends (src/fr-command-7z.c and src/fr-command-rar.c). When processing output from the 7z or rar subprocess, file paths from archive entries are copied with strcpy() into fixed-size stack buffers (4196 and 4096 bytes) without length validation. An archive containing a file entry with a path longer than these buffers causes a stack buffer overflow when the user opens or extracts the archive in file-roller, resulting in denial of service (process termination). Practical code execution is considered difficult on hardened builds with stack canaries, PIE, and ASLR.

Reported upstream as https://gitlab.gnome.org/GNOME/file-roller/-/issues/327 by Yukihiro Nakamura. Fixed upstream in commit ffb76dc866342cef6a4914873faaa880d14d5aa4 ("Check line length when parsing command output"), first released in file-roller 44.7.

GIMP TIF File Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GIMP. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of TIF files. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-29405.

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 libxml2. A local user or an attacker providing a specially crafted XML catalog can trigger a NULL pointer dereference during XML catalog parsing. This occurs when a nextCatalog element lacks its mandatory catalog attribute, leading to the application crashing and causing a Denial of Service (DoS).

Heap out-of-bounds read in =uncompress()= in =gdk-pixbuf/io-icns.c= (function spans lines 192-246 in the current upstream tree). The function decompresses RLE-encoded ICNS icon data but is never given a bound on the source buffer; it loops until it has produced =sizesize= decoded pixels, consuming however many source bytes the RLE stream claims it needs, with no check that any of the three per-iteration reads (the tag byte at =data[0]=, the repeat-value byte at =data[1]=, or the run bytes at =data[i + 1]=) stays inside the block that =loadresources()= computed for it. =loadicon()= holds the correct block size (=isize=, derived from =loadresources()='s =plen = blocklen - sizeof(IcnsBlockHeader)= calculation) but never forwards it to =uncompress()=. A crafted =.icns= file with a truncated RLE block (e.g. an =il32= block whose declared =blocklen= only covers the header, with zero payload bytes) causes =uncompress()= to read past the end of the mapped/allocated ICNS data, an out-of-bounds heap read that can crash the process or leak adjacent heap bytes into the decoded pixel data. All four RLE-compressed ICNS block types (=is32= 16x16, =il32= 32x32, =ih32= 48x48, =it32= 128x128) are affected; the =ic08=/=ic09= (256x256) blocks use JPEG 2000, not this decompressor, and are not affected.

A flaw was found in libsoup. After a CONNECT tunnel is established through an HTTP proxy, libsoup incorrectly attaches the Proxy-Authorization header to subsequent HTTPS requests sent through that tunnel to the destination server. This allows the destination server to capture proxy credentials, leading to information disclosure.

A flaw was found in libsoup. An unsigned integer underflow in the soupfilterinputstreamreaduntil() function causes a heap buffer over-read when parsing multipart HTTP responses. A malicious HTTP server can exploit this by sending a crafted multipart response, potentially causing the client application to crash or disclose sensitive heap memory.

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.