Grav CMS CVE-2026-116019

Requires an authenticated account holding page-edit permission (api.pages.write, or admin.pages in the classic admin) and the ability to supply Flex form override fields in page frontmatter, which is the reachable FlexForm / FlexDirectoryForm path. The malicious directive executes only when the page's Flex form is built (for example when the page is opened in admin). Exploitation is further bounded to Grav 2.0.15 through 2.2.12 (1.7 is not affected; 2.0.15 introduced the trusted-blueprint behavior), and is fixed in 2.2.13. It is NOT reachable by fully unauthenticated users, and installations that only applied the 2.2.2 partial fix remain exploitable via the unset-name@ and integer-key routes.

This is a genuine but conditionally-gated issue rather than a drop-everything emergency. The CVSS 4.0 base score is 8.7 (High) with AV:N/AC:L/PR:L/UI:N and full VC:H/VI:H/VA:H impact, reflecting network-reachable, low-complexity abuse with substantial confidentiality, integrity and availability consequences. The decisive limiting signal is PR:L: exploitation requires an authenticated account that already holds page-edit permission (api.pages.write, or admin.pages in classic admin), so this is privilege escalation / authorization bypass for a semi-trusted editor, not unauthenticated RCE. Not listed in CISA KEV and no public exploit identified at time of analysis - the only exploitation signals are the vendor/VulnCheck advisory and the published fix with regression tests. EPSS is NOT provided in the input, so exploitation probability cannot be quantified here - state that gap rather than assume. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a high-impact flaw whose exploitation is gated behind existing editor privileges. One nuance worth flagging: this is the second incomplete-fix iteration (GHSA-9rq7-4cch-f22j fixed in 2.2.2 closed only the replace-name@ spelling), so environments that applied 2.2.2 believing themselves safe remain exposed through unset-name@ and integer-key routes until 2.2.13.

An account with page-edit permission creates or edits a page and embeds a crafted Flex form override in the frontmatter, smuggling a data-*@ directive past Grav's Class::method allowlist by relocating it with unset-name@ (or @unset-name@ / unset-name@2) or by giving the override field an integer key that array_merge renumbers. When the page's Flex form is built, the directive invokes a privileged static method such as Folder::delete or Utils::download, deleting directories, overwriting files, or reading files outside the page tree. No public exploit is identified at time of analysis, though the technique and proof-style regression tests are published in the GHSA advisory and patch commit.