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. 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.

On Varnish 7.0+, ACL match events may not be 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:

  1. Does the VCL match req.method == "PURGE" or req.method == "BAN"? If not, invalidation is not handled by VCL at all.
  2. Is there an acl definition referenced by the PURGE/BAN handler? If not, invalidation is unauthenticated.
  3. 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

SignalWhy it mattersWarning sign
MAIN.bans_added rateCounts ban operations injected into the listSpike above 10x baseline
MAIN.n_purges rateCounts purge operations executedSpike above 10x baseline
MAIN.bans (gauge)Current outstanding ban countGrowing without shrinking
MAIN.cache_hit rateInvalidation causes miss spikesSudden drop correlating with bans_added or n_purges spike
MAIN.backend_req rateMisses generate backend fetchesSpike mirroring cache_miss spike
MAIN.bans_lurker_contentionLurker cannot keep up with ban floodSustained 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

To inspect bans that were issued via the management CLI rather than through VCL, 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.