Grav Flex Objects CVE-2026-114659

Exploitation requires an authenticated, non-super Grav user account that has been granted the api.access permission together with either admin.pages or admin.configuration.pages, and the installation must run Flex Objects plugin versions 1.4.0 through 1.4.16. The bypass is triggered specifically through the generic /api/v1/flex-objects/pages API routes, which enforce only directory-level admin.pages checks and skip the api.pages.read/write and page-level permission rules. The key limiting factor is that the attacker must already possess a valid restricted admin/editor account - there is no anonymous or unauthenticated path - so the flaw primarily enables privilege escalation past intended per-page restrictions rather than external compromise. Super-user accounts and sites not exposing the Flex Objects Pages API are unaffected.

This is a moderate-priority authorization-bypass flaw, not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation but requires an already-authenticated low-privileged account (PR:L) that holds api.access plus admin.pages or admin.configuration.pages - so the attacker must already be a provisioned, non-super back-end user, which sharply narrows the realistic threat to insiders or compromised editor accounts rather than anonymous internet attackers. There is no EPSS score, no CISA KEV listing, and no public POC referenced in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. A notable conflict exists in the impact metrics: the supplied CVSS 4.0 vector rates only VC:H (confidentiality) with VI:N/VA:N, yet the description explicitly states attackers can 'modify content or delete pages,' which is an integrity (and arguably availability) impact - the vendor's own vector appears to understate integrity impact; verify with the GHSA advisory. Overall this is a legitimate privilege-boundary bug worth patching on a normal cycle, but the authentication prerequisite keeps real-world risk below what the 7.1 score alone might suggest.

A content editor or other non-super user who has been granted api.access and admin.pages (but intentionally restricted from certain pages) sends requests to the generic /api/v1/flex-objects/pages endpoint. Because those routes only check directory-level admin.pages permissions and ignore the Pages API's api.pages.read/write and page-level rules, the user reads frontmatter/source, edits, or deletes pages they were explicitly denied. No public exploit code is referenced, but the attack requires only ordinary authenticated API calls with low complexity.