CVE-2026-40396
Vinyl-Cache Vinyl Cache 9.0.0
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:LSummary
CVE-2026-40396 is a medium-severity Always-Incorrect Control Flow Implementation (CWE-670) vulnerability in Vinyl-Cache Vinyl Cache. Its CVSS base score is 4.0 (Medium).
Operationally, ranked at the 28th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
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-40396 is a workspace overflow vulnerability in Varnish Cache versions 9 before 9.0.1, specifically affecting Varnish Cache 9.0.0. The issue enables a denial-of-service condition through a daemon panic triggered after the timeout_linger period. It stems from adaptations made while porting Varnish Enterprise's non-blocking architecture for HTTP/2 to the open-source Varnish Cache, including changes to a more recent workspace API that formalizes pipelining operations. Merge conflicts, such as partial support for trailers in Varnish Enterprise, led to a missed code path for complete workspace rollback during transitions between requests, allowing prefetched data to exceed workspace_client limits.
A network-accessible malicious client can exploit this vulnerability by sending an HTTP/1 request, waiting until the session releases its worker thread due to timeout_linger, and then resuming traffic before the session closes via timeout_idle. By sending more than one request at once, the attacker triggers a pipelining operation between requests, resulting in a workspace overflow that causes the Varnish server to panic and crash. The CVSS v3.1 base score of 4.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L) reflects network accessibility with no privileges required, high attack complexity, changed scope, and low availability impact, with no confidentiality or integrity effects.
The Varnish Cache GitHub release notes for version 9.0.1 address this vulnerability by fixing the missed code path in pipelining to ensure proper workspace rollback. Security practitioners should update to Varnish Cache 9.0.1 or later, as detailed in the release tag at https://github.com/varnish/varnish/releases/tag/varnish-9.0.1. Additional discussion is available in the related issue at https://github.com/varnish/varnish/issues/15.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-21742
Vulnerability Data
Varnish Cache 9 before 9.0.1 allows a "workspace overflow" denial of service (daemon panic) after timeout_linger. A malicious client could send an HTTP/1 request, wait long enough until the session releases its worker thread (timeout_linger) and resume traffic before the…
more
session is closed (timeout_idle) sending more than one request at once to trigger a pipelining operation between requests. This vulnerability affecting Varnish Cache 9.0.0 emerged from a port of the Varnish Enterprise non-blocking architecture for HTTP/2. New code was needed to adapt to a more recent workspace API that formalizes the pipelining operation. In addition to the workspace change on the Varnish Cache side, other differences created merge conflicts, like partial support for trailers in Varnish Enterprise. The conflict resolution missed one code path configuring pipelining to perform a complete workspace rollback, losing the guarantee that prefetched data would fit inside workspace_client during the transition from one request to the next. This can result in a workspace overflow, triggering a panic and crashing the Varnish server.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V9.2.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation at post-design stages directly exercises control-flow paths and reveals mismatches between implemented and intended behavior.
Requiring a documented development process and supporting tools reduces the chance that incorrect control-flow logic is introduced in the first place.
Flaw identification and remediation processes can locate and correct control-flow errors once they manifest as incorrect runtime behavior.
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 incorrect control-flow implementations via reviews, testing, and static analysis.
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 in development and acceptance can detect paths that deviate from intended logic.
Secure development lifecycle processes can catch incorrect control-flow logic during design and code review.
Secure coding standards and reviews directly target flawed control-flow implementations.
Change-management gates may prevent deployment of flawed logic but do not address the coding defect itself.