Hunting Unauthenticated Varnish Cache PURGE: A Bug Bounty Methodology

Introduction

While doing reconnaissance on a bug bounty target, I came across a simple but often-overlooked configuration flaw: a caching endpoint that accepted a non-standard HTTP method with zero authentication. This write-up walks through the technique I used to find it, how I validated its impact proportionally, and an important lesson about severity assessment that came out of the submission process.

Note: the target's name is intentionally withheld, as this was a private/policy-restricted program. The focus here is purely on technique and methodology, not a specific disclosure.

What is Varnish PURGE?

Varnish Cache is an HTTP reverse proxy widely used by large sites to speed up response times by storing cached copies of content. One of its operational features is the PURGE method — used internally by teams to invalidate specific cache entries, typically after content updates.

The catch: PURGE isn't a standard HTTP method (unlike GET, POST, PUT). Because of that, it's often missed by access control configurations, which usually only account for common methods. Developers frequently forget to restrict who is allowed to send it.

Step 1: Fingerprinting the Cache Layer

Before attempting anything, the first step is confirming whether the target actually runs Varnish:

These headers are often dismissed by developers as "just performance info," but they actually leak the caching architecture to anyone paying attention.

Step 2: Testing the Non-Standard Method

Once Varnish was confirmed, I tested whether the PURGE method was accepted without any credentials:

Why the cache-buster parameter (cb=$(date +%s))? It ensures each request has a unique query string, making it easier to correlate with the response ID returned by the server and avoiding overlap with previous test requests when reviewing logs.

A 200 OK with a JSON confirmation — instead of 403 Forbidden or 405 Method Not Allowed — is a clear sign that no access control exists on this method whatsoever.

Closing Thoughts

This vulnerability is technically simple — a single curl command is enough to prove it. But the real value of this experience wasn't the technical finding itself. It was the lesson in assessing impact accurately and accepting a triage outcome professionally.