This vulnerability in the Grav CMS JwtAuthenticator plugin is being discussed as a logging problem, but that's the wrong frame. The real issue is architectural: the plugin accepts JWTs from query parameters on all /api/v1 routes, including PUT, POST, and DELETE operations. When a user makes a state-changing request with ?token=xxx and then navigates to any external site, that token leaks into the third-party site's Referer header, their analytics, their access logs, and potentially CDN logs that retain query strings indefinitely. You cannot fix this with server-side log sanitization. The token is now in infrastructure you don't control.
Before applying any patch, understand what's at stake: a single leaked token provides full headless access to your entire content graph—published content, drafts, unpublished pages, and any user data the API exposes. This isn't a narrow privilege escalation; it's complete content compromise.
On the patch in 1.0.0-rc.16: verify whether it eliminates query parameter token acceptance entirely or merely restricts it to certain endpoints. If state-changing requests (DELETE, PUT, POST) still accept URL-bound tokens, the Referer leak remains exploitable. Assume the worst about any tokens generated while the plugin was vulnerable—they are effectively compromised. Rotate all active JWTs immediately after patching. Do not rely on the patch alone to protect you: tokens that leaked before the fix remain valid until expiry, and the plugin does not implement token revocation.
The RC designation of this plugin complicates the risk calculus. The vendor may treat rc.16 as a pre-production release, but you're running it in production. That mismatch means your deployment likely received less security scrutiny than a stable release would have. Treat this as a full security incident, not a routine patch.
Operational actions: patch to 1.0.0-rc.16 or later, rotate all API tokens, review third-party analytics and CDN logs for token leakage (you likely cannot purge them but should treat any observed exposure as confirmed compromise), and evaluate whether your threat model permits query-parameter token acceptance at all—even for read-only endpoints, the Referer leak persists whenever users navigate externally after API calls.