Unauthorized Cache Purge

Understanding Cache Purging

Cache purging is a legitimate CDN and caching server feature that removes cached content on demand. It's designed for administrators to force cache refreshes when content updates, clear stale data, or manage cache policies. The PURGE HTTP method provides this functionality.

When properly configured, PURGE requests require authentication and authorization. When misconfigured, anyone can clear the cache.

Discovery

Testing for exposed HTTP methods is straightforward. A single curl request reveals whether PURGE is accessible:

terminal — purge test

$curl -X PURGE https://target.com

Successful PURGE response showing status ok — Response returned status "ok" with an operation ID — no authentication required.

The response came back with a status of "ok" and an operation ID. No authentication required. No authorization checks. The cache was cleared with a single unauthenticated request.

Impact

Attack Vectors Enabled

Performance degradation — all requests bypass cache and hit the origin server directly
Origin server overload — sudden traffic spike as cache provides no protection
Increased latency — users experience slow load times without cached content
Resource exhaustion — origin servers may crash under unexpected load
Cost implications — cloud-hosted services incur higher bandwidth and compute costs

Scope Analysis

The vulnerability wasn't limited to a single endpoint. Testing revealed that PURGE worked across multiple paths. The wildcard pattern /* meant entire sections of the site could be cleared with one request.

Python script showing PURGE working on multiple endpoints — Automated test across discovered endpoints — every path responded successfully to PURGE.

A Python script automating requests across discovered endpoints showed every path responding successfully to PURGE requests. This wasn't a single misconfiguration — it was a systematic security failure across the entire caching infrastructure.

Attack Scenarios

Continuously purge cache to maintain denial-of-service conditions
Target specific high-traffic pages during peak usage times
Combine with other attacks to amplify impact
Use automated scripts to persistently clear cache
Focus on resource-intensive endpoints to maximize origin server load

Business Impact

Revenue loss from degraded user experience and site slowdowns
Reputational damage as users encounter persistent performance issues
Increased operational costs from unexpected traffic patterns
Service disruption affecting availability SLAs

Proper Configuration

The PURGE method must be restricted to authorized administrative users. Hardening checklist:

Require authentication for all PURGE requests
Implement IP allowlisting for cache management
Use API keys or tokens for cache operations
Log all purge operations for audit trails
Rate limit cache purge requests
Disable PURGE entirely if not needed

Detection & Monitoring

Alert on PURGE method usage from unexpected source IPs
Track cache hit ratios — alert on sudden drops
Monitor origin server load for anomalous spikes
Log and review all cache management operations

Cache purging is a powerful administrative function. Like any privileged operation, it requires proper access controls. Without them, it becomes a denial-of-service vulnerability affecting every user of the service.