Advisory · CVE-2026-116019
Grav page editors can still call arbitrary static methods through a Flex form override
Grav 2.0.15 through 2.2.12 still lets page editors smuggle a data directive past the callable allowlist, using unset-name@ or an integer field key, to invoke arbitrary public static methods such as Folder::delete. The vendor says the 2.2.2 fix was incomplete and 2.2.13 fixes this route. CVSS 3.1 8.8.
- Vendor
- Grav
- Product
- Grav
- Identifier / CWE
- CVE-2026-116019
CWE-749 - Action timing
- Immediate
Explain it like I’m five
Grav checks editor-supplied form instructions against an allowlist, but moving the field to a new key during the merge makes Grav think the instruction came from a trusted blueprint file, so the check is skipped.
- 01Page editor signs in
An account with page-edit permission (api.pages.write, or admin.pages in the classic admin) authors a Flex form override in page frontmatter.
- 02Field is relocated
The editor renames the field with unset-name@, or gives it an integer key, carrying a data directive naming a public static method.
- 03Trust is misassigned
The merge puts the directive at a path that was never marked untrusted, so it inherits the file blueprint trust and skips the allowlist.
- 04Method is invoked
When the form is built, for example when an administrator opens the page, methods such as Folder::delete, Folder::move or Utils::download can run.
What happened
Grav disclosed CVE-2026-116019 (CWE-749) in its GitHub security advisory, stating plainly that the fix for the earlier Grav allowlist flaw in 2.2.2 was incomplete. Since 2.0.15, directives from file blueprints are trusted while page-authored form directives face a Class::method allowlist. The advisory says a page editor can still get a directive past that check either by renaming the field with unset-name@ instead of replace-name@, or by giving the field an integer key, because the merge relocates the field and the relocated directive is never marked untrusted.
The vendor advisory scopes the affected range to Grav 2.0.15 through 2.2.12 and states the 1.7 line is not affected. It says 2.2.13 fixes the issue by removing unset-name@ from untrusted input as well, and by treating any directive that is new or changed after a merge of untrusted input as untrusted, wherever the merge put it. Per the advisory, an account with page-edit permission can use this to call server-side methods its role does not grant, giving arbitrary directory deletion, file move or overwrite, and file read outside the page tree.
What to do
- Inventory Grav sites and confirm which run the 2.x line.
- Upgrade affected sites to 2.2.13 or later using the project release guidance.
- Restrict page-edit permissions to named, trusted editors while remediation is underway.
- Hunt for Flex form overrides in page frontmatter using unset-name@, replace-name@ or integer field keys, and for unexpected directory deletions, file moves or downloads attributable to the web user.
- Verify the deployed version after updating, not just that an update ran.
Management note
This is the second route around the same boundary in a week: content editors are not server operators, and a form rename should never promote their input to trusted blueprint status. Upgrade, then audit editor accounts and recent form changes, because the flaw needs an editor account and those accounts are the exposure.