This CVE exposes an authorization gap in Grav's Flex Objects that hinges on how two layers handle undefined permissions differently. The Admin Next API's requireFlexPermission() method returns a permissive result when a directory blueprint omits config.admin.permissions, effectively treating absence as a signal to allow access. The core admin.flex-object fallback, by contrast, denies by default. This mismatch means a user granted only api.access — typically a limited interface permission for integrations and service accounts — can perform full CRUD, export, and media operations on Flex directories that lack explicit blueprint permissions. They gain precisely the access the core fallback would have blocked.
The 1.4.3 fix addresses this by making requireFlexPermission() deny by default on undefined permissions. However, this introduces a practical concern: existing deployments that relied on the permissive-by-omission behavior now face a breaking change. Admins should audit their Flex directory blueprints for any omissions in the config.admin.permissions block — those that were intentionally permissive via omission will now deny, while those left undefined by oversight will now correctly deny. The distinction matters because one is a configuration change, the other is a security correction.
The CVSS 6.3 rating warrants adjustment in your threat model. api.access is commonly granted to external systems — webhooks, CI pipelines, third-party integrations — making it the permission you give when you want to stop thinking about permissions. The blast radius of this bypass isn't limited to one Flex directory; it extends to every Flex object defined in the installation that lacks explicit blueprint permissions. If api.access is granted to accounts with front-end access, this also creates a pivot point for chained exploitation: stored XSS on a page those accounts visit could trigger the API calls through their authenticated session, weaponizing the permission without direct credential compromise.
Audit your deployed Flex Objects directories now. Check every blueprint for config.admin.permissions — any omission is now exploitable. Prioritize directories accessible to service accounts or integrations with api.access, as those represent the most likely exploitation path.