GHSA-7PGQ-CR25-XVC8

Vulnerability from github – Published: 2026-09-17 17:16 – Updated: 2026-09-17 17:16
VLAI
Summary
Grav: Incomplete callable validation in blueprint dynamic fields allows arbitrary static method invocation and file disclosure
Details

Summary

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.

Details

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 (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.

PoC

Tested 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)

  1. Log in to /admin as the page-editor account (GET /admin for the login nonce, then POST task=login).
  2. 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: yaml forms: x: fields: y: type: text data-opts@: - 'Grav\Common\Utils::download' - '/etc/passwd' - false - 0 - 1024 - mime: 'text/plain' The server returns HTTP 200 and accepts the save — the data-opts@ directive is not rejected.
  3. 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.

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).

Impact

A page editor (an admin.pages-only account, not super-admin) can, through a page they author:

  • 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.
  • 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.

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.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.10"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.7"
            },
            {
              "fixed": "2.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69088"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-470",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:16:39Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nGrav CMS\u0027s 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\u0027s 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\u0027s dynamic-field directives (`data-*@`). It only consults its dangerous-name denylist when the callable string does **not** contain `::`:\n```php\nif (is_string($function) \u0026\u0026 !str_contains($function, \u0027::\u0027) \u0026\u0026 Utils::isDangerousFunction($function)) {\n    return false;\n}\n```\nAny callable string containing `::` \u2014 i.e. every `Class::method` static call \u2014 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\u0027s *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 \u2014 so a qualified `Class::method` string would be rejected *if* it ever reached this function. The `!str_contains($function, \u0027::\u0027)` 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 \u2014 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\u0027s 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/\u003croute\u003e` 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              - \u0027Grav\\Common\\Utils::download\u0027\n              - \u0027/etc/passwd\u0027\n              - false\n              - 0\n              - 1024\n              - mime: \u0027text/plain\u0027\n    ```\n   The server returns `HTTP 200` and accepts the save \u2014 the `data-opts@` directive is not rejected.\n3. As an unauthenticated visitor (no cookies), request the saved page, e.g. `GET /\u003croute\u003e` (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 \u2014 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/\u003cname\u003e.yaml` instead returns that account file, including its `hashed_password:` bcrypt line \u2014 i.e. an anonymous visitor obtains a stored administrator\u0027s password hash.\n\n**B. Arbitrary file/directory write (integrity) \u2014 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 \u2014 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\u0027s demonstrated cases.",
  "id": "GHSA-7pgq-cr25-xvc8",
  "modified": "2026-09-17T17:16:39Z",
  "published": "2026-09-17T17:16:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-7pgq-cr25-xvc8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69088"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-cms-through-arbitrary-method-invocation-via-blueprint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav: Incomplete callable validation in blueprint dynamic fields allows arbitrary static method invocation and file disclosure"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.