libspeex EUVD-2026-110489

The target application must use a SpeexBits structure set up with speex_bits_init_buffer() or speex_bits_set_bit_buffer() - i.e. a non-owned (caller-provided) buffer - and then feed attacker-controlled Speex data into speex_bits_read_whole_bytes(); the flaw is the mishandling of length truncation for those non-owned buffers. The limiting factor (reflected as AT:P in the CVSS 4.0 vector) is precisely this usage pattern: applications that use the default owned-buffer path (speex_bits_init) may not be exposed. No authentication is required (PR:N) and no user interaction (UI:N); exploitation is network-reachable wherever the application processes remote/attacker-supplied Speex streams, limited only by whether the vulnerable buffer APIs are in use and whether the deployed library is ≤1.2.1.

Signals point to a moderate, not critical, real-world priority despite the 8.3 CVSS 4.0 base score. The score is driven by VA:H (availability), consistent with the description's stated outcome of crashing applications; VC:N and VI:L confirm this is primarily a denial-of-service / memory-corruption crash rather than a confidentiality breach or reliable code-execution path, and the OOB write's exploitability beyond a crash is not established in the available sources. The CVSS 4.0 vector carries AT:P (attack requirement present), which aligns with the description's precondition that the target application use non-owned SpeexBits buffers set up via speex_bits_init_buffer() or speex_bits_set_bit_buffer() - so exploitability is conditional on how the consuming application is built, not universal across all libspeex users. EPSS is low at 0.41% (35th percentile) and the vulnerability is NOT on CISA KEV, indicating no evidence of widespread or active exploitation; the vuln.today decision label is 'this_week', i.e. patch on a near-term schedule rather than emergency. Net: this is a legitimate issue to remediate this week where affected buffer APIs are used, but the combination of low EPSS, no KEV, availability-dominant impact, and a usage-pattern precondition argues against treating it as a widespread emergency.

An application links libspeex and decodes attacker-supplied Speex data through a SpeexBits structure initialized with speex_bits_init_buffer() or speex_bits_set_bit_buffer() (non-owned buffer). The attacker streams crafted Speex data that mishandles length truncation in speex_bits_read_whole_bytes(), writing out of bounds and corrupting heap or stack memory to crash the application. The trigger is reachable remotely without authentication where such a stream is processed; a public PoC/analysis reference exists but is not verified as working exploit code.