Skip to main content

libspeex CVE-2026-116741

| EUVDEUVD-2026-110489 HIGH
Out-of-bounds Write (CWE-787)
2026-10-26 VulnCheck GHSA-jmfj-jxhf-c4c3
8.3
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach application decoding a Speex stream
  2. Exploit
    Send crafted Speex data to non-owned SpeexBits buffer
  3. Execution
    Trigger OOB write in speex_bits_read_whole_bytes()
  4. Impact
    Corrupt heap/stack memory and crash application

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
MITRE ATT&CK

2 techniques across 2 tactics: Execution, Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

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.

Impact

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.

Exploit ScenarioDerived

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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 28, 2026

An out-of-bounds write in libspeex's speex_bits_read_whole_bytes() (libspeex/bits.c) affects Speex through 1.2.1 and triggers only when an application decodes into a caller-provided, non-owned SpeexBits buffer created with speex_bits_init_buffer() or speex_bits_set_bit_buffer(); crafted Speex data then overflows that buffer because length truncation is mishandled, corrupting heap or stack memory and crashing the process. Remote, unauthenticated attackers can reach it wherever such streams are processed, but exposure is conditional on the vulnerable buffer APIs being in use - reflected as AT:P in the CVSS 4.0 vector and as moderate real-world priority in the provided assessment, with EPSS at 0.41% (35th percentile), no CISA KEV listing, and a public PoC reference (a HackMD writeup) that is not verified as working exploit code. The overall rating is denial-of-service-weighted (A:H, I:L, no confidentiality impact), and a fix has been proposed upstream.

RemediationAI

The most specific status available is that the upstream fix exists as a merge request (https://gitlab.xiph.org/xiph/speex/-/merge_requests/32) referenced from the CVE record and issue https://github.com/xiph/speex/issues/42; a released patched version number is not confirmed in the supplied data, so verify with the Xiph repository or your distribution vendor which release or commit includes it before assuming a given tag is fixed, and track the NVD entry https://nvd.nist.gov/vuln/detail/CVE-2026-116741 for updates. Where patching cannot be applied immediately, the exposure can be removed by avoiding the affected usage pattern: applications that wrap caller-owned memory via speex_bits_init_buffer() or speex_bits_set_bit_buffer() and then pass network-supplied data through speex_bits_read_whole_bytes() should instead use the internally allocated speex_bits_init() path, or copy incoming data into a library-owned SpeexBits, at the cost of the extra allocation and copy that the zero-copy buffer API was designed to avoid; applications already using only speex_bits_init() may not be exposed. Independently, restrict or sanitize the untrusted Speex streams accepted by the service, since exploitation requires attacker-controlled data to reach the vulnerable function, and note that malformed input causing memory corruption can also terminate the process, so front-end input filtering and process isolation limit crash scope rather than removing the flaw.

Affected VersionsENISA

speex 0 ≤1.2.1

Affected Packages

euvd speex no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Speex is Xiph.Org's patent-free speech codec, and libspeex is its reference C implementation; the CPE cpe:2.3:a:xiph:speex:*:*:*:*:*:*:*:* with EUVD's range of speex 0 ≤1.2.1 identifies the affected codebase. The defect is CWE-787 (out-of-bounds write) in speex_bits_read_whole_bytes() at libspeex/bits.c (line 177 in the Speex-1.2.1 tag): the function mishandles length truncation when the SpeexBits structure does not own its storage, i.e. when it wraps a buffer supplied by the caller through speex_bits_init_buffer() or speex_bits_set_bit_buffer() rather than the internally allocated path used by speex_bits_init(). Under those non-owned setups, attacker-controlled Speex data can drive a write past the end of the caller's buffer, damaging heap or stack memory. The supplied evidence does not describe the precise arithmetic or size relationship that produces the overflow, only that length truncation is mishandled; consequently the CVSS 4.0 AT:P value should be read as the documented usage-pattern prerequisite (non-owned buffer APIs) rather than as a statement about race conditions or attacker-controlled timing. Applications using the default owned-buffer path may not be exposed at all.

Know when Speex gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 8.3 HIGH
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
vuln.today AI 6.5 MEDIUM

Requires the app to use non-owned SpeexBits buffers, so AC:H; unauthenticated remote trigger (AV:N/PR:N); impact is mainly a crash (A:H) with limited OOB write (I:L) and no confidentiality.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
Red Hat 6.5 MEDIUM

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
Low
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

Speex (libspeex) through 1.2.1 contains an out-of-bounds write vulnerability in speex_bits_read_whole_bytes() in libspeex/bits.c that mishandles length truncation for non-owned SpeexBits buffers. Attackers can stream crafted Speex data into buffers set up with speex_bits_init_buffer() or speex_bits_set_bit_buffer() to corrupt heap or stack memory and crash applications.

Executive ViewAI

Why It Matters

A high-severity memory corruption flaw in the widely used Speex audio codec library (versions through 1.2.1) could allow attackers to crash voice or audio processing services, causing disruption to real-time communications and potentially degrading service availability. The vulnerability only affects applications that use specific non-standard buffer APIs, limiting the scope but still posing a credible denial-of-service risk for organizations relying on affected software. Leadership should prioritize patching as a preventive measure, as no active exploitation has been observed yet.

Business Impact: Medium
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.4%
Top 65% exploitable
Prevalence
Medium
legacy audio codec library embedded in some media/VoIP apps, largely superseded by Opus
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
Medium

Priority Score

42
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +42
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.

Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.

Vendor StatusVendor

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy