glibc tdelete EUVD-2026-77685

Exploitation requires that a reachable application on the target system calls glibc's tdelete function with attacker-influenced input - specifically, the tree contents, deletion keys, or operation ordering must be partially or fully controlled by the attacker. The vulnerability is in a library function, not a standalone service, so it is only reachable through an intermediary application. Applications that do not expose tdelete to external input are not exploitable attack surfaces. Stack mitigations (stack canaries, ASLR, SafeStack) present on modern Linux distributions will raise practical exploitation difficulty. Authentication requirements cannot be determined from available data - they depend entirely on the access model of the calling application.

Available signals are sparse: no CVSS vector, no EPSS score, no KEV listing, and no POC availability data were provided, making precise risk quantification impossible. The vulnerability is a stack out-of-bounds access in a low-level C library function, which in the worst case enables stack corruption leading to arbitrary code execution in the context of the calling process - a serious impact class. However, exploitability is constrained by the need for an application to expose tdelete to attacker-controlled tree contents, which is an application-specific condition rather than a universally triggerable path. Real-world priority depends heavily on what applications in a given environment call tdelete with untrusted input; the set of such applications is likely narrow. No exploitability signals (KEV, EPSS, POC) are present to elevate urgency beyond a standard patch-cycle response. SSVC exploitation status is 'none' based on available data. The absence of a CVSS vector means attack complexity and privilege requirements are unconfirmed - do not assign high urgency solely from description text.

An attacker supplies crafted input to a networked application (such as a database, directory service, or custom daemon) that internally uses glibc's tsearch/tdelete API to manage in-memory data structures. By controlling the contents or ordering of tree operations, the attacker triggers the out-of-bounds stack access in tdelete, potentially corrupting stack memory. In a worst-case scenario this could redirect execution flow to attacker-controlled code, though exploitation complexity is likely elevated by stack protections and ASLR on modern Linux systems.