Description

The Grav API plugin (getgrav/grav-plugin-api, bundled with Grav 2.0) before version 1.0.14 (fixed in 1.0.15) contains a missing authorization vulnerability in BlueprintPathResolver::resolveUserScope(). The method gates the users/<name> scope on the account's raw super-admin ACL flag (access.api.super) instead of validating the presented API key's actual scope. An attacker holding an API key scoped only to api.media.write minted on a super-admin account can bypass the authorization check and, via POST /blueprint-upload or GET /blueprint-files, write a file into another user's scope (in the shared user/accounts/ directory, constrained to image extensions by assertSafeExtension()) and browse that scope's file listing, despite the key not being granted api.users.write.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-18T12:19:33.230Z",
  "pubdate": "2026-08-18T12:19:33.230Z",
  "executiveSummary": "A missing authorization vulnerability exists in the Grav API plugin (getgrav/grav-plugin-api), bundled with Grav 2.0, specifically within the BlueprintPathResolver::resolveUserScope() method prior to version 1.0.14 (fixed in version 1.0.15).\nThe flaw allows an attacker possessing a restricted API key—such as one scoped solely to api.media.write and originally minted on a super-admin account—to bypass intended privilege boundaries.\nBy exploiting this authorization bypass via POST /blueprint-upload or GET /blueprint-files, an unauthorized actor can read and write files into arbitrary user scopes within the shared user/accounts/ directory.\nAlthough file writes are constrained to image extensions by assertSafeExtension(), this condition still enables unauthorized file placement and traversal across restricted user accounts.\nThe risk implication is significant as it compromises user scope isolation and data integrity. Successful exploitation requires an active API key with specific constrained scopes generated from a privileged account, but it entirely circumvents the enforcement of fine-grained API permissions during blueprint path resolution.",
  "technicalDetails": "The vulnerability resides in the BlueprintPathResolver::resolveUserScope() method within the Grav API plugin. The root cause is an improper authorization check where the method gates the users/<name> scope based solely on the account's raw super-admin access control list flag (access.api.super) rather than dynamically validating the specific operational scopes granted to the presented API key.\nThe vulnerable components include the BlueprintPathResolver class, specifically the resolveUserScope() method, alongside the endpoint handlers for POST /blueprint-upload and GET /blueprint-files.\nAffected software versions include the Grav API plugin (getgrav/grav-plugin-api) before version 1.0.14, with the issue patched in version 1.0.15. The product is bundled with Grav 2.0.\nPrerequisites for exploitation include network exposure to the Grav API endpoints and possession of a valid, active API key. However, the key does not need the api.users.write or broad administrative privileges; it can be restricted to lower-privilege scopes like api.media.write as long as it was minted on a super-admin account.\nThe step-by-step attack flow proceeds as follows: First, the attacker authenticates requests to the Grav API using an API key minted on a super-admin account but explicitly scoped only for media operations (api.media.write). Second, the attacker issues a GET /blueprint-files request or a POST /blueprint-upload request targeting a specific user scope. Third, when BlueprintPathResolver::resolveUserScope() evaluates the request, it checks the raw super-admin ACL flag of the underlying account rather than verifying if the presented token possesses permissions for the users scope. Fourth, the validation check incorrectly permits access, allowing the attacker to browse directory listings or upload files directly into another user's scope located within the shared user/accounts/ directory. Finally, while payloads are constrained to image extensions due to enforcement by assertSafeExtension(), the resulting unauthorized file write and directory traversal within user namespaces achieve unauthorized data exposure and storage manipulation."
}