Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend HTTP request with excessive headers
-
DeliveryVCL invokes headerplus.write_req0()
-
ExploitWorkspace overflow in req0 buffer
-
ExecutionDaemon panic and crash
-
ImpactService becomes unavailable
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Impact | The CVSS v3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L) indicates a network-accessible vulnerability requiring high attack complexity that affects availability across scope boundaries (causing daemon-wide impact from a request-level issue). The high attack complexity suggests an attacker must craft requests with a specific structure-excessive headers in the amended req-and this attack only succeeds when headerplus.write_req0() is actively used in the VCL configuration, limiting the practical attack surface. The low availability impact (A:L) reflects that this is a denial of service via crash, not data destruction. The lack of confirmed active exploitation (KEV status not indicated as active, no POC reported) and the requirement for VCL configuration that explicitly calls write_req0() reduce real-world priority for organizations not using Varnish Controller or headerplus module. However, for shared VCL deployments, this represents a straightforward, repeatable DoS vector that bypasses authentication (PR:N = no privileges required) and thus merits timely patching despite the moderate CVSS score. The SSVC decision framework would classify this as: Exploitation=Unkown (no POC/KEV), Automatable=Yes (header-based attack requires no user interaction), Technical Impact=Total (daemon crash), pushing toward at least coordinated patching rather than differed remediation. |
| Exploit ScenarioDerived | A malicious client sends a series of HTTP requests with a large number of header fields (e.g., hundreds of custom headers or duplicated standard headers) to a Varnish Enterprise instance running shared VCL with the Varnish Controller and vmod_headerplus module active. When the VCL processes the request via write_req0(), the function attempts to write the amended request object-now containing excessive headers-back to the read-only req0 workspace. The workspace allocation is insufficient to hold the expanded header set, triggering a buffer overflow and immediate daemon panic. The Varnish server crashes, causing a complete denial of service until manual restart. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 12, 2026
Varnish Enterprise before version 6.0.16r12 is vulnerable to a workspace overflow denial of service attack that crashes the daemon through the headerplus.write_req0() VCL function. Unauthenticated remote attackers can craft HTTP requests with excessive header fields to trigger a panic and terminate the Varnish server, particularly impacting deployments using shared VCL through Varnish Controller. CVSS base score of 4.0 reflects low availability impact with high attack complexity, and no public exploit code or confirmed active exploitation has been identified.
RemediationAI
Upgrade Varnish Enterprise to version 6.0.16r12 or later. This release includes fixes to the headerplus.write_req0() function to properly validate header field counts and workspace capacity before writing amended request headers back to req0, preventing the workspace overflow condition. As a temporary workaround for organizations unable to upgrade immediately, review and restrict VCL configurations that invoke headerplus.write_req0(), ensuring that incoming requests are validated or rate-limited to prevent excessive header field injection attacks. Consult the Varnish Software security advisory at https://docs.varnish-software.com/security/VEV00003/ for detailed patching procedures and configuration guidance specific to your deployment.
Affected VersionsENISA
Affected Packages
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
Varnish Enterprise is a reverse proxy and HTTP accelerator that uses VCL (Varnish Configuration Language) for request processing. The vmod_headerplus module provides the write_req0() function to update the underlying req0 object (the original read-only request from which the writable req object is derived in VCL). This capability is essential for shared VCL deployments orchestrated by Varnish Controller, where requests are refined in one VCL context before switching to another via vcl(<label>) return statements. The vulnerability stems from insufficient bounds checking when writing amended request headers back to req0's workspace allocation. When the amended req object contains more header fields than req0's workspace can accommodate, a buffer overflow occurs in the workspace memory region, triggering a daemon panic. The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling), indicating the function lacks proper validation of header field count or size before attempting the write operation.
Know when Varnish Enterprise 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
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
5DescriptionNVD
Varnish Enterprise before 6.0.16r12 allows a "workspace overflow" denial of service (daemon panic) for shared VCL. The headerplus.write_req0() function from vmod_headerplus updates the underlying req0, which is normally the original read-only request from which req is derived (readable and writable from VCL). This is useful in the active VCL, after amending req, to prepare a refined req0 before switching to a different VCL with the return (vcl(<label>)) action. This is for example how the Varnish Controller operates shared VCL deployments. If the amended req contained too many header fields for req0, this would have resulted in a workspace overflow that would in turn trigger a panic and crash the Varnish Enterprise server. This could be used as a Denial of Service attack vector by malicious clients.
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
More in Varnish Enterprise
View allVarnish Cache before 8.0.1 and Varnish Enterprise before 6.0.16r12 mishandle HTTP/1.1 URLs with a root path (/) in unche
libvmod-digest before 1.0.3, as used in Varnish Enterprise 6.0.x before 6.0.11r5, has an out-of-bounds memory access dur
Varnish Cache before 7.6.2 and Varnish Enterprise before 6.0.13r10 allow client-side desync via HTTP/1 requests. Rated m
Varnish Enterprise before 6.0.13r13 allows remote attackers to obtain sensitive information via an out-of-bounds read fo
EUVD-2026-21740
NVD
CVE.org
EPSS
Vulnrichment
GitHub PoC
Exploit-DB