When the WAF Needs a WAF: Securing Open-Source WAF Admin Interfaces After BunkerWeb CVE-2026-61718
When the WAF Needs a WAF: Securing Open-Source WAF Admin Interfaces
Web Application Firewalls exist to protect web applications from attacks. But what protects the WAF itself? A recent vulnerability in BunkerWeb, an open-source next-generation WAF, demonstrates that security tools can carry their own security blind spots — and that broken access control in a WAF's admin interface can temporarily weaken the very protection it provides.
The Vulnerability: CVE-2026-61718
Tracked as CVE-2026-61718 (CVSS 3.1: 5.4, Medium), this vulnerability affects BunkerWeb versions 1.6.2 through 1.6.12. It is a broken access control issue in the BunkerWeb web UI that allows read-only users to perform destructive write operations they should not have permission to execute.
Here is how it works: BunkerWeb's web UI controls access through a Biscuit-token middleware called BiscuitMiddleware, which runs as a Flask before_request hook. It maps HTTP methods to required permissions — GET needs read, POST needs write. Since version 1.6.2, the /cache/ URL prefix was placed in the middleware's bypass list, right next to genuinely static assets like /css/, /img/, and /js/. Because of that, every request under /cache/ skipped authorization entirely.
The problem: those /cache/ routes are not static assets. They carry real privileges:
GET /cacheandGET /cache/<service>/<plugin>/<job>/<file>return job cache file contents (a read operation).POST /cache/deletepermanently deletes job cache files (a write operation).
With these routes excluded from the authorization policy, any logged-in UI user could reach POST /cache/delete, including a low-privilege read-only (reader) account whose role only grants the read permission. A read-only user could purge cached job data they had no right to touch.
Why This Matters More Than It Sounds
Job cache files in BunkerWeb store security-relevant data that the WAF downloads or generates:
- Blacklist, greylist, and DNSBL IP feeds
- CrowdSec data and GeoIP databases
- ModSecurity CRS rules
- Let's Encrypt and ACME certificate material
- Custom configurations
Deleting these files triggers a configuration change and reload, then forces a re-download. During that window, the WAF's protection in front of backend services is temporarily weakened. In a security tool whose entire purpose is to maintain a defensive posture, even a brief degradation can be exploited by an attacker who times the cache deletion with an attack attempt.
The Scope Limitation
It is worth noting the scope of this vulnerability. Multi-user role management — the feature that lets you create read-only reader accounts — is a BunkerWeb PRO feature. A default open-source install ships a single full-privilege admin account, so this vulnerability is only exploitable on deployments that have actually provisioned non-admin UI users.
That said, the principle applies broadly. Any security tool with a web admin interface that supports multiple users needs rigorous access control testing — not just on the obvious CRUD endpoints, but on every route that touches state, including those that look like infrastructure plumbing.
The Fix and What To Do
The vulnerability was fixed in BunkerWeb 1.6.12 (first available in the 1.6.12-rc2 release candidate). The /cache/ prefix was removed from the authorization bypass list, so cache routes now go through the normal operation policy — GET maps to read, POST maps to write — and read-only users are properly denied the delete operation.
If you are running BunkerWeb and cannot upgrade immediately:
- Avoid creating non-admin (read-only) UI accounts until you have upgraded
- Restrict network access to the web UI — put it behind a VPN or IP allowlist
- Audit any existing read-only accounts and assume they can delete cache files
- Monitor for unexpected configuration reloads that could indicate cache deletion
Upgrade to 1.6.12 or later as soon as possible.
Broader Lessons for Open-Source WAF Deployments
This vulnerability highlights several principles that apply beyond BunkerWeb:
Security tools are not automatically secure. A WAF protects your web application, but the WAF itself is software with its own attack surface — web UIs, APIs, configuration endpoints, and admin interfaces. Each one needs the same scrutiny you would apply to any other web application.
Access control bypass lists are dangerous. The root cause here was a URL prefix being added to an authorization bypass list alongside static assets. This is a common pattern in web frameworks — exempting certain paths from middleware for performance or convenience — and it is a frequent source of access control vulnerabilities. Audit your bypass lists regularly.
The principle of least privilege applies to admin tools too. If your WAF supports multi-user access, ensure that role-based access control is enforced consistently across all routes, including internal plumbing routes that do not look like user-facing features.
Cache integrity is a security property. Deleting cache files in a WAF can degrade protection, even temporarily. Treat cache integrity as a security concern, not just a performance or operational one.
