Grav API Plugin CVE-2026-63407

The attacker must separately possess a valid, non-expired JWT for the target Grav API Plugin instance - for example, by harvesting it from server access logs or HTTP Referer headers where it was leaked via the ?token= URL query parameter accepted on all API routes prior to the patch. The victim must visit an attacker-controlled webpage (UI:R per CVSS) during the window in which the stolen JWT remains valid. No special server-side configuration is required beyond default installation: the wildcard CORS response was the out-of-box default for all pre-1.0.0-rc.16 deployments. Exploitation is entirely browser-mediated - direct non-browser API clients such as curl or server-side code are unaffected by CORS policies. The write impact (I:L) is bounded by the privileges of the stolen token's associated account; full administrative account takeover requires having obtained an admin-level JWT.

The CVSS 8.2 score is driven by C:H (full read of authenticated API data), S:C (browser SOP bypass changes scope beyond the vulnerable component), and AV:N/AC:L, all of which are well-justified by the vulnerability class. The UI:R metric reflects that a victim must visit an attacker-controlled page; this is a meaningful real-world constraint that limits opportunistic mass exploitation. CVSS PR:N correctly reflects that the attacking party needs no account on the Grav instance, though the attacker must separately possess a valid victim JWT - a precondition the base score does not capture. EPSS score was not included in the intelligence feed and cannot be quantified. No CISA KEV listing is present and no public exploit code has been identified. Critically, the secondary URL token leakage vector fixed in the same patch (tokens accepted via ?token= on all API routes and therefore appearing in server access logs and Referer headers) provided a realistic, low-effort JWT theft mechanism chained with this CORS bypass - making the combined attack considerably more accessible than each vulnerability in isolation. Risk is highest in publicly accessible deployments with long-lived JWTs and server logs accessible to attackers.

An attacker harvests a victim's JWT from server access logs or an HTTP Referer header, where it was leaked because the pre-patch plugin accepted tokens via the ?token= URL query parameter on all API routes. The attacker embeds the stolen token in JavaScript hosted on an attacker-controlled domain and lures the victim to visit that page; the JavaScript then submits a fetch() request to the Grav API with the JWT in the Authorization header, and because the API responds with Access-Control-Allow-Origin: *, the browser permits the cross-origin script to read the full authenticated JSON response. No proof-of-concept exploit has been publicly disclosed; the technique requires only standard browser fetch APIs and is straightforward for any web attacker who can obtain a valid JWT.