Nicl4Ssic

The Grav API plugin (getgrav/grav-plugin-api) before 1.0.6 contains an authorization bypass: API keys can be created with a restricted scopes array, but the ApiKeyAuthenticator class never reads or enforces these scopes. It loads and returns the owning user's full account object, so a key created with limited scopes (e.g. read-only) can perform any write, delete, or administrative operation the owning user is authorized for. Fixed in 1.0.6.

Grav before 2.0.4 contains a two-factor authentication bypass vulnerability in the login plugin where the regenerate2FASecret task checks only user existence, not authorization, during the pending TOTP challenge window. Attackers who know the victim's password can call this task without a CSRF nonce to overwrite the 2FA secret with an attacker-chosen value, compute a valid TOTP code, and complete authentication while reducing 2FA to password-only protection.

The Grav API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 accepts JWT access tokens through the ?token= URL query parameter on every API route (JwtAuthenticator::extractBearerToken fallback). Because tokens are embedded in URLs, they are logged verbatim in web server access logs, leaked via the Referer header, stored in browser history, and captured by upstream proxy and CDN logs, exposing valid admin access tokens. A leaked token grants unauthorized API access, including reading configuration and user data, creating admin accounts, modifying system settings, and deleting pages.

The Grav API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 shipped Access-Control-Allow-Origin: * as its default CORS configuration on all responses, including authenticated endpoints and preflight (OPTIONS) responses. Because the plugin accepts credentials via the Authorization and X-API-Token headers (set programmatically by JavaScript rather than via cookies), an attacker who obtains a valid access token (e.g., via log leakage, Referer headers, browser history, or network capture) can issue fully authenticated cross-origin requests from any malicious website to read sensitive data and perform write operations as the token's user. Fixed in 1.0.0-rc.16.

**Name of the Vulnerable Software and Affected Versions** Grav Admin2 plugin versions prior to 2.0.4 **Description** The plugin embeds a global JavaScript variable `window. GRAV CONFIG ` in the Admin2 SPA bootstrap page at the '/grav/admin' endpoint and its subroutes. This object is returned in every unauthenticated response and discloses the server URL, API prefix, admin base path, runtime environment type, and exact Grav and Admin2 version numbers. This allows an unauthenticated attacker to fingerprint the deployment and select version-specific exploits without reconnaissance. **Recommendations** Update the Grav Admin2 plugin to version 2.0.4 or later.

**Name of the Vulnerable Software and Affected Versions** Grav API plugin versions prior to 1.0.0-rc.16 **Description** The plugin accepts JSON Web Tokens (JWT) through the `token` URL query parameter and returns an Access-Control-Allow-Origin: * header. This configuration allows unauthenticated attackers to perform fully authenticated cross-origin API requests from malicious websites. If a JWT token is leaked via access logs, proxy logs, browser history, or Referrer headers, an attacker can exfiltrate sensitive user and configuration data or create persistent super-admin backdoor accounts. **Recommendations** Update Grav API plugin to version 1.0.0-rc.16 or later.

**Name of the Vulnerable Software and Affected Versions** Grav API plugin versions prior to 1.0.1 **Description** An unrestricted file upload issue exists in the avatar upload endpoint '/api/v1/users/user/avatar'. The system only validates the client-declared MIME type using `getClientMediaType` to check if it begins with 'image/', without inspecting actual file content or restricting extensions. This allows authenticated users to upload arbitrary content, such as PHP code, SVG files with embedded JavaScript, or polyglot payloads, to the 'user/accounts/avatars/' directory with predictable filenames. While .htaccess blocks direct HTTP access to these files, their persistence on disk could enable remote code execution or stored Cross-Site Scripting (XSS) if a path traversal flaw or server misconfiguration is present. **Recommendations** Update to version 1.0.1.