$ guides / varnish / varnish-unauthorized-purge-ban ▌

Operations Guides

Varnish unauthorized PURGE/BAN: cache invalidation as an attack surface

Varnish treats PURGE and BAN as ordinary HTTP methods. It has no built-in VCL that handles, gates, or rejects them. If your custom VCL handles these methods but does not check an ACL first, anyone who can reach your Varnish listener can invalidate cached objects. Unauthenticated Varnish PURGE has been reported as a valid security finding against major platforms through bug bounty programs.

The consequences fall into two categories. Mass invalidation forces a cache stampede: concurrent requests miss simultaneously and hit backends sized for cached traffic. Selective invalidation creates a cache poisoning window: an attacker purges a specific URL, then races to have a malicious response cached before legitimate traffic refills it.

What makes PURGE and BAN an attack surface

Varnish does not ship with default VCL for PURGE or BAN. What happens when either request arrives depends entirely on your custom VCL.

If your VCL does not mention PURGE or BAN, the request follows normal caching logic. On Varnish 7.x, unknown methods are piped to the backend; Varnish 8.0 changed the built-in VCL to return a synthetic 501 and close the connection instead of piping. In neither case does Varnish’s own cache get invalidated.

The exposed state happens when your VCL handles PURGE or BAN but does not check client.ip against an ACL. The invalidation succeeds for anyone who sends the request. This typically occurs when a developer copies a purge snippet from documentation or a blog post, integrates it into VCL, and deploys without adding the ACL gate. The VCL compiles, the purge works in testing because testing comes from localhost, and the missing gate goes unnoticed.

flowchart TD
    A["Attacker sends PURGE/BAN"] --> B{"VCL checks client.ip?"}
    B -- "No ACL" --> C["Objects invalidated"]
    B -- "ACL gates it" --> D["405 or 403 rejected"]
    C --> E["Cache miss spike"]
    E --> F["Backend request spike"]
    F --> G["Backend overload"]
    C --> H["Cache slot emptied"]
    H --> I["Attacker refills"]
    I --> J["Poisoned response cached"]

Why BAN is more dangerous than PURGE

PURGE evicts a single cached object by its exact hash (URL plus Host plus any Vary dimensions). It cannot use wildcards. To purge multiple objects, the caller must issue one PURGE per URL. An attacker using PURGE must enumerate URLs, which limits the blast radius per request.

BAN is fundamentally different. A ban is a regex-based invalidation rule evaluated against cached objects. A single ban expression can invalidate every object in cache with one request.

Even with an ACL, broad BAN expressions carry operational risk. A misconfigured CI/CD pipeline or a buggy application can achieve the same mass invalidation as an intentional attack. Downstream effects (ban list growth and lurker contention) are covered in the related guides on ban list growing and ban lurker not keeping up.

One additional BAN-specific concern: bans that reference req.* variables cannot be processed by the ban lurker background thread. They persist in the ban list until every cached object is checked at lookup time, contributing to O(n) lookup overhead until fully processed. Bans referencing obj.* variables are lurker-friendly and get cleaned up proactively.

The X-Forwarded-For trap

Even when VCL checks an ACL, the most common mistake is checking the wrong IP. The ACL must compare against client.ip, the TCP peer address Varnish sees. It must never compare against X-Forwarded-For, X-Real-IP, or any other client-supplied header. These are trivially spoofed: any HTTP client can set X-Forwarded-For: 127.0.0.1 and bypass an ACL that trusts it.

The harder problem arises when a reverse proxy (HAProxy, NGINX, an AWS ALB) sits in front of Varnish. In that topology, client.ip is the proxy’s IP, not the original client’s. If the proxy’s IP is in your purge ACL, every client behind the proxy appears authorized and the ACL provides no protection.

Three solutions:

PROXY protocol on the listener. Configure Varnish to accept PROXY protocol (-a :6081,PROXY) and configure the upstream proxy to send it. Varnish then sees the original client IP in client.ip. Requires both sides to support PROXY protocol.

Trusted header with std.ip(). If the proxy reliably sets a header like X-Real-IP and strips client-supplied values, match with std.ip(req.http.x-real-ip, "0.0.0.0") ~ purge. This shifts trust to the proxy configuration.

Separate purge-only listener. Bind a second Varnish listener on a port reachable only from authorized networks via firewall rules, and handle PURGE/BAN only on that listener. Network-level isolation is the gate, not VCL logic.

VCL patterns: exposed vs hardened

The exposed pattern, missing the ACL gate entirely:

sub vcl_recv {
    if (req.method == "PURGE") {
        return(purge);
    }
}

The hardened PURGE pattern, following the structure in the official Varnish documentation:

acl purge {
    "localhost";
    "192.168.0.0"/24;
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return(synth(405, "Not allowed."));
        }
        return(purge);
    }
}

The hardened BAN pattern:

sub vcl_recv {
    if (req.method == "BAN") {
        if (!client.ip ~ purge) {
            return(synth(403, "Not allowed."));
        }
        ban("req.url ~ " + req.url);
        return(synth(200, "Ban added"));
    }
}

Note: the BAN example uses req.url in the ban expression, which makes it lurker-unfriendly (see the req.* vs obj.* distinction above). For production, prefer banning on obj.http.x-url (set it in vcl_backend_response) so the lurker can process bans asynchronously.

The +log ACL flag was introduced in Varnish 7.0, and from that release VCL_acl records are no longer emitted by default. On Varnish 7.0+, ACL match events are not logged by default. To see ACL rejections in varnishlog, declare the ACL with the +log flag:

acl purge +log {
    "localhost";
    "192.168.0.0"/24;
}

Without +log, unauthorized PURGE or BAN attempts that hit the ACL and receive a 405 or 403 are invisible in the shared memory log.

Auditing your VCL for coverage gaps

Check what VCL is currently active:

varnishadm vcl.list

Retrieve the active VCL source and search for PURGE and BAN handling:

# Replace <configname> with the active config from vcl.list
varnishadm vcl.show <configname>

Look for three things:

Does the VCL match req.method == "PURGE" or req.method == "BAN"? If not, invalidation is not handled by VCL at all.
Is there an acl definition referenced by the PURGE/BAN handler? If not, invalidation is unauthenticated.
Does the handler check client.ip ~ <acl_name> before return(purge) or ban()? If not, invalidation is unauthenticated.

Also check the management CLI bind address, which is a separate but related exposure:

# Check management interface bind address (-T flag, requires GNU grep for -P)
ps aux | grep varnishd | grep -oP '\-T\s+\S+'

# Check what is listening
ss -tlnp | grep varnishd

The management CLI (default port 6082, set with -T) has full administrative control: loading VCL, banning cache, changing runtime parameters, stopping the service. If it is bound to 0.0.0.0 or a public IP, the PURGE/BAN ACL is irrelevant because anyone with CLI access can issue ban commands directly, bypassing VCL entirely.

Detection: signals to watch

Signal	Why it matters	Warning sign
`MAIN.bans_added` rate	Counts ban operations injected into the list	Spike above 10x baseline
`MAIN.n_purges` rate	Counts purge operations executed	Spike above 10x baseline
`MAIN.bans` (gauge)	Current outstanding ban count	Growing without shrinking
`MAIN.cache_hit` rate	Invalidation causes miss spikes	Sudden drop correlating with bans_added or n_purges spike
`MAIN.backend_req` rate	Misses generate backend fetches	Spike mirroring cache_miss spike
`MAIN.bans_lurker_contention`	Lurker cannot keep up with ban flood	Sustained nonzero rate

varnishstat -1 -f MAIN.bans_added -f MAIN.n_purges

Find PURGE or BAN requests in the shared memory log:

varnishlog -q 'ReqMethod eq "PURGE"' -g request
varnishlog -q 'ReqMethod eq "BAN"' -g request

# Find ACL rejections (requires +log on the ACL)
varnishlog -q 'VCL_acl ~ "NO_MATCH"' -g request

Ban issuance produces no VSL record — the only ban-related VSL tag is ExpBan, which logs evicted objects — so CLI-issued bans are invisible in the shared memory log. To inspect them, list current bans with timestamps:

varnishadm ban.list

A spike in bans_added or n_purges above 10x baseline can indicate one of three things: an application bug issuing excessive invalidations, a CI/CD pipeline sending purges to the wrong environment, or an active attack. These are indistinguishable from the counter alone. You need the source IP from varnishlog to determine which.

Hardening checklist

ACL on every invalidation method. Without a client.ip check before return(purge) or ban(), anyone who reaches Varnish can invalidate cached objects.
Gate on client.ip, never headers. X-Forwarded-For and X-Real-IP are client-supplied and trivially spoofed.
Resolve the proxy problem. When a proxy sits in front of Varnish, client.ip is the proxy IP. Use PROXY protocol, trusted-header matching, or a separate port.
Add +log to ACLs on Varnish 7.0+. Without it, ACL rejections are invisible in the shared memory log.
Restrict management CLI access. The management interface (-T, default port 6082) bypasses VCL entirely and allows direct ban commands.
Prefer obj.* over req.* bans. Object-level bans are cleaned up by the ban lurker; request-level bans persist and add O(n) lookup overhead on every cache hit.
Consider xkey VMOD for invalidation. Surrogate-key-based purging is more efficient than regex bans and limits blast radius per invalidation.
Monitor bans_added and n_purges rates. Spikes above 10x baseline indicate an application bug, a misdirected pipeline, or an attack.
Patch for VCL bypass vulnerabilities. HTTP/2 request smuggling (VSV00007, CVE-2021-36740) can skip VCL processing entirely, including ACL checks on invalidation methods.

How Netdata helps

Per-second collection of MAIN.bans_added, MAIN.n_purges, and MAIN.bans makes invalidation spikes visible without polling delay. Correlating these counters with MAIN.cache_hit drops and MAIN.backend_req spikes on a single timeline shows the stampede cascade as one connected event: the invalidation, the miss burst, and the backend load. MAIN.bans_lurker_contention monitoring reveals when a ban flood overwhelms the lurker and transitions a security event into a sustained performance problem. ML-based anomaly detection on these counters catches deviations without manual threshold tuning, which matters because baseline invalidation rates vary widely across deployments and a static threshold is difficult to set correctly.