Allocation of Resources Without Limits or Throttling The advisory has been revoked - it doesn't affect any version of package varnish:6/varnish-devel (opens in a new tab)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL8-VARNISH-16056069
- published15 Apr 2026
- disclosed12 Apr 2026
Introduced: 12 Apr 2026
CVE-2026-40395 (opens in a new tab)Amendment
The Red Hat security team deemed this advisory irrelevant for RHEL:8.
NVD Description
Note: Versions mentioned in the description apply only to the upstream varnish:6/varnish-devel package and not the varnish:6/varnish-devel package as distributed by RHEL.
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.