Grav API plugin CVE-2026-62386

Exploitation requires that a valid Grav API JWT actually be transmitted in the ?token= URL query parameter (the JwtAuthenticator::extractBearerToken fallback) and that the attacker can then read it from one of the leak channels named in the advisory: web server access logs, the Referer header, browser history, or upstream proxy/CDN logs. What limits exploitation is that the attacker cannot forge a token - they must capture a genuine, unexpired admin token, so the practical prerequisite is access to a logging surface (server logs, proxy/CDN telemetry, or a third-party site receiving the Referer). Deployments that only ever send tokens in the Authorization header, or that strip query strings from logs, are not exposed even on vulnerable plugin versions.

The official CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) rates this 8.2 High, and the key nuance is AT:P - attack requirements are present, meaning exploitation is not a single self-contained request but depends on a valid admin token first being emitted in a URL and then captured from a log, Referer chain, proxy, or CDN the attacker can read. That preconditioned nature is why this is a real but not wormable issue: EPSS and automatable signals are not provided in the input, there is no KEV listing and no public POC, so this reads as an opportunistic credential-leakage weakness rather than a mass-exploited RCE. Note a discrepancy worth flagging: the vendor vector scores only confidentiality (VC:H, VI:N/VA:N), yet the description states a leaked token permits creating admin accounts, modifying system settings, and deleting pages - those are integrity and availability impacts, so the confidentiality-only scoring understates downstream consequences once a token is abused. Priority should be driven by whether the deployment logs query strings or sits behind logging proxies/CDNs, which is common.

An admin or automation client calls a Grav API route as https://site/api/…?token=<JWT>; that full URL is recorded in the site's Nginx access log and forwarded in the Referer header and CDN logs. An attacker with read access to any of those log stores (or a shared upstream proxy) lifts the still-valid token and replays it against the API to create a new admin account or dump configuration. No public POC is identified, and success depends on the attacker being able to observe a leaked token, consistent with the AT:P attack-requirement flag.