Grav CMS Flex Framework RCE via Unvalidated dynamicDataField

Vulnerability Overview Title: Arbitrary Invocation Execution in with No Validation Description: A missing validation check exists in Grav's Flex framework, allowing any user with create or update permissions for a single Flex directory to execute arbitrary shell commands. The vulnerability is exploited via the function within the method, which fails to adequately validate incoming parameters, leading to dangerous invocations. Scope of Impact Affected Versions: >= 1.7.0 Fixed Version: 2.0.9 Severity: Medium CVE ID: No known CVE Weakness: CWE-470 Remediation Suggested Fix: Use to check for calls already used in within . This is best achieved by reimplementing the callable dispatch logic rather than re-registering via . Proof of Concept (POC) Code Part 1: Code-Level Part 2: Full HTTP Chain Configuration Usage: Baseline Check: Same commit as above. bin/gpm install admin flex-objects -y: This pulls in form, login, email, shortcode-core, and api as dependencies. php -S localhost:8000 system/router.php: Step 1: Flex-objects provides a self-contained example directory with its own permission set. A field was added to its : Step 2: Register as an active directory via normal configuration override. The same file is written to on the Admin Plugin Configuration screen: Step 3: Confirm a fully super-admin account can trigger this as a baseline. Send (the standard "Create Contact" endpoint) using a super-admin JWT: Step 4: Create a second account with no granted permissions: No , no , and no permissions other than creating records in this specific directory. This aligns exactly with the permissions declared in 's own blueprint definition. maps to . The token response confirms the account has no other permissions: , with only and set to true. This account sends the same request, a standard "Create Contact" call indistinguishable from a legitimate user: This was reproduced on a fully independent clone checkout (independent composer install, independent bin/gpm install, new account) to exclude any dependency artifacts from the first run. Both runs yielded identical results. Impact Threat Model: An attacker requires an authenticated account with create or update permissions for a single Flex directory. The PoC account held only one permission, , scoped to a single directory, with and other access rights. Achieving arbitrary shell command execution as the web server user from a single permission constitutes full Remote Code Execution (RCE). This is a true boundary crossing: not within the action's scope, but outside of it. A permission that allows adding records to a single directory translates into unrestricted code execution. Any Grav 2.0 installation running the plugin, or any other plugin defining a Flex directory (Flex Users and Flex Pages are Grav-core Flex types), is affected through the same unprotected code path, provided the blueprint field contains a directive anywhere. Anyone can place that directive into an active blueprint if they have the access required to do so. I could not independently confirm that running Grav separately from this checkout would trigger a blueprint field containing a non-super-user-writable-level blueprint YAML with logic located outside of the Flex objects or Admin UI code. The fully proven trigger is: once such a field exists, for any reason, if an account can create records in that directory, it can run shell commands on the server. According to your own severity guidelines, this is High: a low-privilege account ultimately gains the ability to exceed its granted permissions.

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

Grav CMS Flex Framework RCE via Unvalidated dynamicDataField

More from this source