+ "details": "### Summary\nGrav 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.\n\n### Details\n`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 `::`:\n```php\nif (is_string($function) && !str_contains($function, '::') && Utils::isDangerousFunction($function)) {\n return false;\n}\n```\nAny 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.\n\n`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.)\n\nThis 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 (`admin.pages_twig`) from plain page editing (`admin.pages`), so invoking arbitrary methods from an `admin.pages`-authored page is a genuine trust-boundary bypass, not editor capability by design.\n\n### PoC\nTested 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`.\n\n**A. Arbitrary file read (confidentiality)**\n\n1. Log in to `/admin` as the page-editor account (GET `/admin` for the login nonce, then POST `task=login`).\n2. Save a page via the standard admin endpoint, `POST /admin/pages/<route>` with the session cookie, the admin nonce, and `data[frontmatter]` containing a form field with a `download` gadget directive:\n ```yaml\n forms:\n x:\n fields:\n y:\n type: text\n data-opts@:\n - 'Grav\\Common\\Utils::download'\n - '/etc/passwd'\n - false\n - 0\n - 1024\n - mime: 'text/plain'\n ```\n The server returns `HTTP 200` and accepts the save — the `data-opts@` directive is not rejected.\n3. As an unauthenticated visitor (no cookies), request the saved page, e.g. `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.\n\n**B. Arbitrary file/directory write (integrity) — verified**\n\nUsing 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).\n\n### Impact\nA page editor (an `admin.pages`-only account, **not** super-admin) can, through a page they author:\n\n- **Read any server-readable file**, disclosed to any anonymous, unauthenticated visitor of the crafted page — including `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.\n- **Create or overwrite files and directories** under the web-server account (demonstrated via `Folder::copy`), with `Folder::move`/`Folder::delete` additionally reachable for destructive tampering.\n\nBecause 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.",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments