GCC libstdc++ EUVD-2026-88443

Exploitation requires an application compiled against a vulnerable GCC libstdc++ that (1) uses a binary-heap priority queue container and (2) calls the erase_if operation on it with attacker-influenced contents such that a storage reallocation is triggered. The vulnerability is not self-contained in a network service - it is a library primitive, so reachability depends entirely on whether the consuming application exposes this code path to external input. Limiting factors: AC:H (attacker must force the reallocation timing/heap condition that leaves the internal entry pointer stale), the operation must actually be invoked by the application (many programs never call erase_if on a priority queue), and the demonstrated outcome is a crash - memory corruption beyond DoS is described only as 'potential.'

This is a genuine but conditional memory-safety flaw whose real-world priority is moderate, not urgent. The vendor CVSS3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H, base 7.0) reflects worst-case scoring for a library primitive: it assumes a network-facing application forwards attacker-influenced data into libstdc++'s priority_queue erase_if operation. The AC:H rightly captures that exploitation is not straightforward - it depends on the consuming application exposing this specific operation and on triggering the reallocation-vs-stale-pointer window. No EPSS score is available, there is no CISA KEV listing, and no public exploit code was identified; per precision rules the status is 'no public exploit identified at time of analysis.' The dominant realistic impact is A:H (denial of service via crash); the C:L/I:L reflect the description's 'potential memory corruption,' which is speculative rather than demonstrated. Treat this as a library-hygiene patch to roll out via normal GCC/distribution updates rather than an emergency: the affected component is ubiquitous, but the exploitable trigger path is narrow and application-dependent. Note conflict/uncertainty: the AV:N is a library abstraction - the true attack vector is inherited from whatever application calls erase_if, so for many consumers this is effectively local or not reachable at all; verify exposure per application. Also, upstream CWE is N/A and the input tag 'Buffer Overflow' contradicts the description, which explicitly describes a use-after-free (CWE-416).

An application built with a vulnerable libstdc++ processes attacker-supplied data through a binary-heap priority queue and invokes erase_if; the container reallocates its backing storage but leaves an internal entry pointer dangling. The attacker crafts input that forces this reallocation, causing a use-after-free dereference that crashes the process (DoS) or, in the worst case, corrupts heap memory. No public proof-of-concept exists, and reliable exploitation for anything beyond a crash would require overcoming AC:H conditions and application-specific heap layout.