CVE-2026-25541
Tokio-Rs Bytes 1.2.1 – 1.11.1
Raw vector
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-25541 is a medium-severity Integer Overflow to Buffer Overflow (CWE-680) vulnerability in Tokio-Rs Bytes. Its CVSS base score is 5.5 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 43th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-25541 is an integer overflow vulnerability in the Bytes utility library for working with bytes, maintained by tokio-rs. It affects versions from 1.2.1 up to but not including 1.11.1, specifically in the BytesMut::reserve function within the unique reclaim path. The condition "v_capacity >= new_cap + offset" performs an unchecked addition that can overflow usize in release builds, causing the check to incorrectly pass and self.cap to be set beyond the actual allocated capacity. Subsequent APIs, such as spare_capacity_mut(), then rely on this corrupted capacity value, potentially producing out-of-bounds slices and leading to undefined behavior (UB). This differs from debug builds, which panic on overflow due to checks, while release builds exhibit wrapping behavior.
Remote attackers can exploit this vulnerability over the network (AV:N) with low attack complexity (AC:L), no privileges (PR:N), and no user interaction (UI:N), as indicated by its CVSS v3.1 base score of 7.5 (High) under CWE-680. The impact is confined to high availability disruption (A:H) with no effects on confidentiality or integrity (C:N/I:N) and unchanged scope (S:U). Triggering the overflow results in UB, which in release builds of affected Rust applications could cause crashes, memory corruption, or other denial-of-service conditions.
The vulnerability has been patched in Bytes version 1.11.1. Mitigation involves updating to this version or later. Official resources include the GitHub security advisory at https://github.com/tokio-rs/bytes/security/advisories/GHSA-434x-w66g-qw3r, RustSec advisory RUSTSEC-2026-0007 at https://rustsec.org/advisories/RUSTSEC-2026-0007.html, the fixing commit at https://github.com/tokio-rs/bytes/commit/d0293b0e35838123c51ca5dfdf468ecafee4398f, and release notes at https://github.com/tokio-rs/bytes/releases/tag/v1.11.1.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-5321
Vulnerability Data
Bytes is a utility library for working with bytes. From version 1.2.1 to before 1.11.1, Bytes is vulnerable to integer overflow in BytesMut::reserve. In the unique reclaim path of BytesMut::reserve, if the condition "v_capacity >= new_cap + offset" uses an…
more
unchecked addition. When new_cap + offset overflows usize in release builds, this condition may incorrectly pass, causing self.cap to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as spare_capacity_mut() then trust this corrupted cap value and may create out-of-bounds slices, leading to UB. This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks. This issue has been patched in version 1.11.1.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and analysis (static, dynamic, fuzzing) finds integer-overflow-to-allocation defects before deployment.
Mandates documented development standards and tools that enforce secure coding rules against unsafe integer arithmetic.
Requires engineering principles such as safe arithmetic and bounds-checked allocation that directly stop integer overflow during memory-size computation.
Validates untrusted size/offset inputs before they reach allocation calculations, structurally blocking the integer overflow path.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent integer-overflow flaws during development, but eliminating only this CWE covers only part of the broad control intent.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect integer-overflow-to-buffer-overflow conditions during development.
Secure development life cycle mandates practices that can catch integer overflows before deployment.
Application security requirements can specify safe integer handling and bounds checking.
Secure architecture principles encourage use of safe arithmetic libraries and overflow detection.
Secure coding standards directly require prevention of integer overflows that lead to buffer overflows.