CVE-2026-114659 in grav-plugin-flex-objects
Summary
by MITRE • 10/22/2026
Grav Flex Objects plugin 1.4.0 before 1.4.17 contains an authorization bypass because its generic /api/v1/flex-objects/pages API routes check only directory-level admin.pages permissions, without enforcing the Pages API's api.pages.read/write permissions or page-level permissions rules. Authenticated non-super users with api.access and admin.pages or admin.configuration.pages permissions can read page source and frontmatter, modify content, or delete pages they are denied.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The Grav Flex Objects plugin version 1.4.0 through 1.4.16 suffers from a critical authorization bypass vulnerability that undermines the granular access control mechanisms intended for administrative users. This flaw resides within the generic API endpoint located at /api/v1/flex-objects/pages, which is designed to facilitate programmatic interaction with page data in Grav-based websites. The core technical deficiency lies in how permission checks are executed during request processing. Instead of validating specific permissions required for individual operations or respecting hierarchical access rules, the system performs a broad check against directory-level admin.pages permissions. This coarse-grained approach fails to enforce the more restrictive api.pages.read and api.pages.write permissions that should govern API-specific actions, nor does it apply page-level permission policies that dictate who can view, edit, or delete specific content items within those directories.
This architectural oversight allows authenticated non-super users with basic administrative privileges to escalate their effective access rights significantly. Specifically, any user possessing the api.access capability along with either admin.pages or admin.configuration.pages permissions can bypass intended restrictions. Consequently, these users are able to read sensitive page source code and frontmatter metadata that should be restricted based on finer-grained role definitions. Furthermore, they possess the ability to modify content fields and delete pages entirely, even when explicit deny rules exist for those specific resources at the individual page level. This represents a classic case of insufficient authorization checks where the system relies on broad group memberships rather than verifying actual entitlements against the target resource.
The operational impact of this vulnerability is severe, particularly in environments where multiple administrators or content managers share access to the same Grav instance with varying levels of trust and responsibility. An attacker exploiting this flaw can compromise data integrity by altering critical website content, steal sensitive information contained within page frontmatter such as internal notes or configuration details, and disrupt service availability through unauthorized deletion of pages. This undermines the principle of least privilege, allowing users to perform actions far beyond their assigned roles. The vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically highlighting failures in enforcing access control policies at the resource level rather than just the application or directory level.
From a threat modeling perspective using the MITRE ATT&CK framework, this behavior corresponds to techniques associated with lateral movement and privilege escalation within web applications. The ability to read arbitrary page data facilitates reconnaissance (T1087), while modifying content aligns with impact tactics such as Data Manipulation (T1499). Attackers can leverage these capabilities to deface websites or inject malicious code into legitimate pages, thereby compromising the trustworthiness of the entire application. The lack of proper validation means that standard authentication mechanisms provide a false sense of security, as valid credentials alone are insufficient to guarantee safe access boundaries.
To mitigate this vulnerability, administrators must immediately upgrade the Grav Flex Objects plugin to version 1.4.17 or later, where these authorization checks have been corrected to properly enforce api.pages.read and api.pages.write permissions alongside page-level rules. Until an update is applied, it is advisable to restrict API access to only those users who absolutely require it and to ensure that no non-super users are granted broad admin.pages privileges unless strictly necessary for their specific operational needs. Additionally, implementing a Web Application Firewall with strict rate limiting and input validation can provide a layer of defense-in-depth by monitoring for anomalous patterns in API requests, although this is not a substitute for fixing the underlying authorization logic within the application code itself.