X.Org X Server CVE-2026-93517

Requires an authenticated X client connection to the vulnerable X.Org server or Xwayland (prior to xorg-server-21.1.25 / xwayland-24.1.14) with the GLX extension available - i.e. the attacker must already be able to open the display, which on default distributions means local access over the Unix socket since TCP listening is typically disabled. Exploitation is triggered by issuing a GLX RenderLarge request whose dataBytes field exceeds cmdlen; no special non-default server configuration is otherwise needed on systems providing GLX. LIMITING FACTORS: the display-authorization requirement (not remote-unauthenticated), the local-socket default that blocks network reach, and the need for GLX to be present/enabled. No end-user interaction is required once the attacker has a client connection.

No CVSS vector, EPSS, KEV, or POC data is provided in the input, so risk must be inferred from the advisory text alone. CVE-2026-93517 is a GLX RenderLarge heap buffer overflow in the X.Org X server (and Xwayland) where the buffer is allocated to cmdlen but memcpy copies attacker-controlled dataBytes with no check that dataBytes <= cmdlen, allowing a write past the allocation. The advisory explicitly requires an 'authenticated X client,' meaning the attacker already needs an authorized connection to the X display - this is characteristically a local privilege-escalation / sandbox-escape primitive rather than a remote unauthenticated flaw, because modern distributions bind the X server to a local Unix socket and disable TCP listening by default. Impact is high (heap corruption leading to arbitrary code execution in the X server process, which frequently runs with elevated or root privileges), but the authentication/local-access prerequisite meaningfully caps real-world exploitability. This is a genuine priority for multi-user hosts, kiosk/thin-client deployments, and any system where untrusted code can reach the display, but it is NOT a mass-exploitable internet-facing bug. CONFLICT TO VERIFY: no CVSS is supplied, so attack vector (local vs. network) and privilege level are my inference from 'authenticated X client' and default X11 socket configuration - confirm against the vendor/distro CVSS once published. EPSS/KEV are absent (not errors), consistent with a freshly disclosed ZDI-reported issue with no observed exploitation.

A local or otherwise authorized low-privilege user (or untrusted code that can open the X display) sends a crafted GLX RenderLarge request in which dataBytes exceeds cmdlen, causing the server's memcpy to write past the heap buffer. By grooming the heap, the attacker corrupts adjacent allocations to achieve code execution in the X server context - typically a privilege escalation to the user or root the server runs as, or at minimum a server crash (DoS) killing the graphical session. No public exploit code is identified at time of analysis, though the flaw was found via Trend ZDI (ZDI-CAN-31833).