Grav Flex-Objects Privilege Escalation: api.access User Bypass via Fail-Open Authorization in REST API

Fail-open authorization in grav-plugin-flex-objects admin-next API: api.access user gets full CRUD on permission-less directories (requireFlexPermission missing else-deny) Vulnerability Overview The Flex-Objects admin-next REST API ( + , routes under ) derives the required permission for each directory from the directory blueprint's map. The method enforces this map; however, if a blueprint omits the block, the method falls through and returns void (allowing access) after only performing the baseline check. There is no default deny condition ( clause). Every CRUD handler ( ) routes through this method, and these routes do not carry any route-level permission checks. Consequently, a user holding only the privilege—with no directory-specific permissions and no admin role—gains full create/read/update/delete/export capabilities over the objects within any permission-less directory. This is a fail-open bug, not an open-by-design feature. Grav core defines an explicit default-deny fallback for permission-less flex directories via . A permission-less directory should authorize against , a permission set that a low-privilege user lacks, resulting in a deny. Two paths correctly honor this core logic. Additionally, the plugin's own listing ( ) hides the directory from this user by using . However, the API CRUD path ignores this fallback, making it more permissive than both the core's authorization contract and the plugin's own directory listing for the same directory and user. This inconsistency can only be attributed to a fail-open oversight. Impact Scope Affected Versions: <= 1.4.2 Fixed Version: 1.4.3 Severity: Moderate (6.3 / 10) CVSS v3 Base Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: Low - User Interaction: None - Scope: Unchanged - Confidentiality: Low - Integrity: Low - Availability: Low Remediation Add the missing clause to deny access to directories lacking permissions, aligning with the core authorization logic. Preconditions (In Scope) The (admin-next) plugin is installed and enabled. This is a very new 1.0.x version, released recently, with low actual adoption rates; therefore, exploitation is unconditional. A Flex directory whose blueprint omits . In practice: Only the sample declares an inline block; inherits from . The plugin's custom directory tutorial ( ) defines a directory that omits the block entry; thus, following the documentation validation results in a vulnerable directory. The attacker is an authenticated user with a key (PR1), possessing no directory-specific permissions. They cannot access , which requires a separate account. Relation to Existing Advisories Unlike recent admin-next API authorization advisories (CVE-2026-42844 blueprint-upload privilege escalation; CVE-2026-42843 api.access – self-elevation, patched in HEAD; GHSAs-62x API media upload; GHSAs-62x flex SSTI), this vulnerability is additive: it allows CRUD operations and exports on directories that are typically inaccessible to accounts.

Goal Reached Thanks to every supporter — we hit 100%!

Grav Flex-Objects Privilege Escalation: api.access User Bypass via Fail-Open Authorization in REST API

More from this source