CVE-2026-112780 in Grav
Summary
by MITRE • 10/19/2026
Grav from 2.0.15 before 2.2.2 contains an allowlist bypass vulnerability that allows page editors to call arbitrary public static methods by renaming Flex form fields with replace-name@. Attackers with page-edit permission can smuggle data-*@ directives past the callable check to invoke Folder::delete, Folder::move, or Utils::download, deleting directories, overwriting files, or reading files.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Grav versions prior to 2.2.2 represents a critical security flaw rooted in improper validation of user-supplied input within the Flex Forms system. Specifically, this issue manifests as an allowlist bypass that permits authenticated users with page-editing privileges to execute arbitrary public static methods on backend classes. The core technical mechanism involves the manipulation of form field names using a specific syntax known as replace-name@. By appending this suffix to standard field identifiers, attackers can effectively trick the application's internal routing and method invocation logic into treating these fields not merely as data containers but as executable commands. This bypass circumvents the intended security controls that restrict which methods are callable through the Flex Forms interface, thereby elevating the scope of actions a page editor can perform beyond their authorized permissions.
From a technical perspective, this flaw allows for the indirect invocation of dangerous static methods such as Folder::delete, Folder::move, and Utils::download. The vulnerability leverages the application's dynamic method resolution process, where input strings are parsed to determine which backend function should handle the request. When an attacker renames a form field using the replace-name@ directive, they can smuggle data-* attributes or other malicious payloads past the initial callable check. This results in the execution of file system operations that were not intended for page editors. For instance, invoking Folder::delete enables the removal of entire directory structures, while Folder::move allows for the reorganization and potential overwriting of critical files within the site's root directory. Additionally, the ability to call Utils::download facilitates unauthorized access to sensitive files by forcing the server to serve them as downloadable attachments, leading to a severe compromise of data integrity and confidentiality.
The operational impact of this vulnerability is significant, particularly for websites that rely on Grav’s multi-user environment where different roles are assigned distinct levels of access. An attacker with page-edit permissions can exploit this flaw to achieve unauthorized file system manipulation. This capability extends beyond simple defacement or content modification; it allows for the complete destruction of site infrastructure by deleting essential directories or corrupting configuration files through overwriting operations. Furthermore, the ability to read arbitrary files poses a substantial risk to data privacy and security, as sensitive information such as database credentials, API keys, or user data could be exfiltrated from the server. This level of control effectively grants an attacker root-like access to the web application's file system, undermining the principle of least privilege that underpins secure role-based access controls.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-285 Improper Authorization, as it involves both the execution of unintended code paths and a failure to enforce proper access restrictions. In terms of the MITRE ATT&CK framework, this behavior corresponds to techniques involving Command and Scripting Interpreter abuse or File Manipulation for persistence and impact. To mitigate this risk, administrators must immediately upgrade Grav to version 2.2.2 or later, where these allowlist bypasses have been patched by strictly validating method names against a predefined safe list without allowing dynamic renaming tricks. Additionally, organizations should enforce strict role-based access controls, ensuring that only trusted administrative users with the highest level of privilege are granted permissions to manage Flex Forms and backend configurations. Regular security audits and input validation checks on all user-facing forms can further reduce the attack surface by detecting and blocking anomalous field naming patterns before they reach the execution layer.