Grav CMS EUVD-2026-107902

Requires an authenticated Grav account with page-edit rights (PR:L) to author a page containing malicious flex-*@ frontmatter directives, plus a second user who also holds page-edit rights opening that page (UI:P, passive interaction) so the directives execute in their session via FlexDirectory::dynamicFlexField(). Applies to Grav 2.0.0 before 2.2.5, where the flex directive handling is reachable by default. Limiting factors: this is a confused-deputy attack that cannot be triggered without a victim viewing the crafted page, both parties must already have edit access, and the payoff is specifically unauthorized deletion of protected pages rather than code execution or data theft.

The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:H/VA:L) yields a 7.0 'High' score, but the real-world urgency is tempered by two attacker-unfavorable metrics: PR:L means the attacker must already hold an authenticated Grav account with page-edit rights, and UI:P means a second user with edit rights must actively open the crafted page before the directives fire. This is a classic confused-deputy / access-control bypass (CWE-470 unsafe reflection) rather than a remotely automatable server takeover. No EPSS score was provided in the input, there is no CISA KEV listing, and no public exploit was referenced, so there is no evidence of active or at-scale exploitation - consistent with a vulnerability that requires an insider-like foothold plus victim interaction. One data conflict to note: the input Tags label this 'Information Disclosure,' but the CVSS vector sets VC:N (no confidentiality impact) and the impact is unauthorized page deletion (integrity/availability), so the tag is misleading and should not drive triage. Net: a genuine privilege-boundary flaw worth patching, but a targeted/insider-dependent issue rather than a mass-exploitation emergency.

A low-privileged page author embeds flex-*@ directives in a page's frontmatter that invoke setStorageKey() and delete() on arbitrary Flex objects. When a different user with page-edit rights (e.g. an editor or admin) opens that page, the directives execute within the victim's session and privileges, deleting protected pages that neither the author nor the victim was authorized to remove. No public exploit code was identified at time of analysis, and the attack depends on the victim opening the malicious page.