| Package | Affected versions | Patched versions |
|---|---|---|
| getgrav/grav | ≥ 2.0.7, < 2.0.11 | 2.0.11 |
Grav CMS's blueprint dynamic-field callable guard can be bypassed with a fully-qualified Class::method string, letting an account with only page-editing rights (admin.pages, not super-admin) plant a directive in a page's form-field frontmatter that invokes an arbitrary public static PHP method with attacker-controlled arguments. Using built-in gadget methods this yields, at minimum, arbitrary reading of any server-readable file (disclosed to anonymous visitors of the crafted page) and arbitrary creation/copying of files and directories under the web-server account.
Blueprint::isSafeDynamicCall() (system/src/Grav/Common/Data/Blueprint.php, method around line 488) is meant to block dangerous callables named in a blueprint's dynamic-field directives (data-*@). It only consults its dangerous-name denylist when the callable string does not contain :::
if (is_string($function) && !str_contains($function, '::') && Utils::isDangerousFunction($function)) {
return false;
}
Any callable string containing :: — i.e. every Class::method static call — skips the check entirely and is passed to call_user_func_array() at Blueprint::dynamicData() (Blueprint.php, around line 461) and FlexDirectory::dynamicDataField() (system/src/Grav/Framework/Flex/FlexDirectory.php, around line 937). There is no allowlist restricting which classes or methods may be invoked this way; only the call's arguments are (separately) scanned for smuggled dangerous callables, never the target itself.
Utils::isDangerousFunction() (system/src/Grav/Common/Utils.php) classifies any string containing a colon (str_contains($name, ":")) or a namespace backslash as dangerous — so a qualified Class::method string would be rejected if it ever reached this function. The !str_contains($function, '::') condition in isSafeDynamicCall() ensures it never does, which is what leaves qualified static calls entirely unscreened. (Whether the exemption was intended to admit legitimate Class::method option-providers is a plausible reading of the surrounding code, but the intent is not established here.)
This is an incomplete fix of two recently published advisories — one addressing page editors executing hidden callables via form-field settings, the other extending the same guard to Flex directories. The guard those fixes introduced never covered qualified static calls. Grav's own permission model separates page-content code execution into a distinct, higher privilege () from plain page editing (), so invoking arbitrary methods from an -authored page is a genuine trust-boundary bypass, not editor capability by design.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeadmin.pages_twigadmin.pagesadmin.pagesTested on Grav develop at commit db8c1fc (which self-reports version 2.0.11) with the admin and form plugins, using an account granted only admin.login + admin.pages (page editor, not super-admin). The same guard is present in every current release from 2.0.7 through 2.0.10. Base URL shown as https://grav.example.
A. Arbitrary file read (confidentiality)
/admin as the page-editor account (GET /admin for the login nonce, then POST task=login).POST /admin/pages/<route> with the session cookie, the admin nonce, and data[frontmatter] containing a form field with a download gadget directive:
forms:
x:
fields:
y:
type: text
data-opts@:
- 'Grav\Common\Utils::download'
- '/etc/passwd'
- false
- 0
- 1024
- mime: 'text/plain'
HTTP 200 and accepts the save — the data-opts@ directive is not rejected.GET /<route> (use a fresh query string to avoid a cached copy; immediately after saving, a first request may 404 while the flat-file page index catches up — retry moments later). The response is HTTP 200 with the raw contents of /etc/passwd in the body (root:x:0:0:...). Pointing the path at user/accounts/<name>.yaml instead returns that account file, including its hashed_password: bcrypt line — i.e. an anonymous visitor obtains a stored administrator's password hash.B. Arbitrary file/directory write (integrity) — verified
Using the same mechanism with Grav\Common\Filesystem\Folder::copy (a public static method taking source and destination paths), a page editor caused the server to copy an existing page directory to an attacker-chosen new path under user/pages/; the newly created page then rendered its (attacker-controlled) content at the new route over plain HTTP. This demonstrates attacker-controlled creation of files/directories anywhere the web-server account can write. Folder::move and Folder::delete are equally reachable (their destructive nature was not exercised).
A page editor (an admin.pages-only account, not super-admin) can, through a page they author:
user/accounts/*.yaml, which stores account metadata and bcrypt password hashes. An attacker may attempt offline cracking of a disclosed hash; recovery of a weak or reused administrator password could lead to full admin-panel compromise. Other secrets on disk (site/plugin config, environment files) are equally exposed.Folder::copy), with Folder::move/Folder::delete additionally reachable for destructive tampering.Because the guard permits any public static method, the reachable impact is bounded only by the gadget surface of the loaded codebase, not by this report's demonstrated cases.