GCC libstdc++ EUVD-2026-113746

Requires an application compiled against the affected libstdc++ that constructs a std::vector<bool> using an element count the attacker can control and make excessively large; that oversized count causes an integer wrap in the container's internal memory calculation, and the out-of-bounds access manifests during a subsequent operation on the inconsistent container. Exploitation is limited by: (1) the application must actually expose this sizing to untrusted input - the library is not independently network-reachable; (2) AC:H, reflecting that the attacker must drive the count to a value that triggers the wrap; (3) impact is confined to availability (process crash/DoS) with no confidentiality or integrity effect. Authentication requirements beyond the library are application-dependent; the input vector's PR:N applies to the library interface, not necessarily to the hosting application.

This is a moderate-severity availability-only issue, not an emergency. The input CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, base 5.9) scores impact as Availability-only (C:N/I:N) - consistent with a Denial-of-Service outcome, not code execution or data compromise. The AC:H signal indicates the attacker must supply an 'excessively large element count' to trigger the integer wrap, so successful exploitation is not trivially repeatable against arbitrary inputs. Crucially, AV:N reflects the library's theoretical reachability but is contingent on an application actually exposing the std::vector<bool> constructor to attacker-controlled sizing - libstdc++ itself is not a network listener, so real-world reachability varies entirely by the consuming application. The decision signals reinforce low urgency: no CISA KEV listing, no EPSS probability provided in the input, no PoC or exploit reference present, and the vuln.today priority label is 'this_month' (not act_now/emergency). No signals conflict - all point to a real-but-non-urgent defect. The main uncertainty is exploitability scope: whether any given deployment feeds attacker-controlled counts into this path is application-specific and cannot be determined from the provided data.

An application linked against libstdc++ constructs a std::vector<bool> whose element count is derived from attacker-supplied input (e.g. a size field in a parsed message or file). The attacker provides an excessively large count that wraps during internal memory calculation, leaving the container inconsistent; a later operation performs an out-of-bounds access and crashes the process, causing denial of service. No public PoC or exploit reference is present in the provided data.