CVE-2026-42843

The Grav API plugin before 1.0.18 does not enforce API-key scope caps in the injectSecurityTab() function of BlueprintController. A caller with a scoped API key may see and potentially edit page permission fields beyond the granted scope.

The Grav API plugin (getgrav/grav-plugin-api, bundled with Grav's admin-next/API stack) before 1.0.14 fails to enforce the authorize requirement in MenubarController::executeAction(). While the GET /menubar/items listing endpoint correctly filters menubar items via userPassesAuthorize(), the POST /api/v1/menubar/actions/{plugin}/{action} endpoint only checks the baseline api.access permission and never evaluates the authorize field a plugin registered for that action. Any authenticated caller with api.access can therefore invoke a privileged menubar action directly, bypassing the intended authorization. No plugin bundled with core Grav currently registers a privileged authorize handler, so on a stock install the impact is latent; the flaw affects any first- or third-party plugin relying on the documented authorize semantics.

Grav API plugin (getgrav/grav-plugin-api) before 1.0.14 contains a missing authorization vulnerability in userPassesAuthorize() (AbstractApiController.php). The function fails to consult the calling request's API key scopes, relying instead on the account's raw super-admin flag and ACL grants. As a result, an authenticated attacker holding a scoped API key minted on a privileged account can bypass their declared scope restrictions to access authorize-gated UI metadata and item definitions (sidebar/menubar/widget items and users-list columns/row-actions/filter-tabs) that their key scope should deny, resulting in information disclosure.

The Grav API plugin (getgrav/grav-plugin-api, bundled with Grav 2.0's admin-next/API stack) before version 1.0.14 contains an open redirect weakness in SsoController::sanitizeReturnTo(). The function rejects a literal '//' prefix but does not account for browsers normalizing backslashes to slashes in special (http/https) schemes, so a returnTo value such as '/\evil.com' passes the guard and is later resolved by the browser as the protocol-relative URL '//evil.com'. Following a legitimate OAuth login flow, an attacker-supplied returnTo parameter could redirect an authenticated victim to an attacker-controlled site for post-login phishing. Full browser-side exploitability depends on the admin-next SPA's client-side oauth-callback handler and was not independently verified by the reporter.

The Grav API plugin before version 1.0.3 fails to sanitize SVG files uploaded via the POST /api/v1/media endpoint. The processUploadedFile() method only validates the file extension and does not call Security::sanitizeSVG(), allowing an authenticated attacker with api.media.write permission to upload an SVG containing arbitrary JavaScript. The file is stored unmodified and served with Content-Type: image/svg+xml; when an administrator opens it in a browser, the embedded script executes in their session context, enabling cookie theft and session hijacking.

The Grav API plugin before v1.0.0-rc.16 accepts JWT tokens via the ?token= URL query parameter and responds with Access-Control-Allow-Origin: *, allowing unauthenticated attackers to make fully authenticated cross-origin API requests from any malicious website. Attackers who obtain a leaked JWT token from access logs, proxy logs, browser history, or Referrer headers can create persistent backdoor super-admin accounts and exfiltrate sensitive configuration and user data.

Vulnerability in Grav API Plugin (plugin for Grav CMS) before version 1.0.6. WebhookController.php accepts webhook URLs after only FILTER_VALIDATE_URL syntax validation, and WebhookDispatcher.php initializes cURL without CURLOPT_PROTOCOLS or CURLOPT_REDIR_PROTOCOLS restrictions. An account with api.webhooks.write can submit file, dict, gopher, private-network, or link-local targets, retrieve local files and delivery response bodies, and pivot requests to internal services or cloud metadata endpoints. Fixed in version 1.0.6.

The Grav api plugin (grav-plugin-api) before version 1.0.8 fails to properly authorize API key generation and revocation. It intercepts the apiKeyGenerate/apiKeyRevoke admin tasks before the account-management ACL runs and authorizes the caller on only the admin.login permission (the baseline permission held by every panel user). This allows any user with admin.login to mint a persistent API key bound to any account, and the forged key inherits the target account's API permissions. On installs where an API-enabled account holds broader permissions, this enables account impersonation and privilege escalation up to account takeover.

The Grav API plugin (grav-plugin-api) before version 1.0.4 does not validate the origin of the admin_base_url field in the POST /api/v1/auth/forgot-password endpoint. The sanitizeHttpUrl() function only checks the URL scheme (http/https) and never verifies the host against the server's own origin, allowing an attacker to supply an arbitrary host. An unauthenticated attacker can cause the password reset email sent to a victim to contain a reset link pointing at an attacker-controlled server; when the victim follows the link, the valid reset token is disclosed to the attacker, enabling full account takeover.

Grav API plugin before 1.0.16 contains a server-side request forgery vulnerability in webhook delivery that allows attackers to bypass hostname validation by DNS rebinding. Attackers controlling authoritative DNS for a configured webhook hostname can answer validation lookups with public addresses and delivery lookups with private addresses to reach internal network resources.