Grav CMS EUVD-2026-104586

Requires an authenticated Grav account holding page-edit permission (per the description), so it is NOT exploitable by fully anonymous users despite the vendor vector's PR:N. The attacker must be able to edit a Flex form and rename a field using the 'replace-name@' syntax, which smuggles a 'data-*@' directive past the callable allowlist check to reach Folder::delete, Folder::move, or Utils::download. Limiting factors: affected only in Grav versions 2.0.15 up to (not including) 2.2.2; exploitation is gated by the editor privilege, so single-administrator or fully-trusted-editor deployments face little added risk, while multi-tenant or delegated-editing installations are materially exposed.

This is a genuinely high-severity issue but with an important caveat that tempers the raw 9.3 score. The input CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N) models the attack as network-reachable, low-complexity, and requiring NO privileges - yet the description explicitly states exploitation requires an attacker 'with page-edit permission.' These two signals directly conflict: PR:N implies anonymous exploitation, while the description describes an authenticated page editor abusing their existing access. The realistic reading is a privilege-escalation / allowlist-bypass flaw (CWE-749, exposed dangerous method) in which a semi-trusted editor escalates to arbitrary file deletion, overwrite, and read via Folder::delete, Folder::move, and Utils::download - not a pre-auth remote compromise. No EPSS score was supplied, the CVE is NOT on CISA KEV, and no public POC is referenced, so there is no evidence of active or at-scale exploitation. Net priority: treat as high for any Grav instance that grants page-edit rights to untrusted or multi-tenant users, but it is materially lower risk than the 9.3 suggests for single-admin deployments, because the attacker must already hold editor privileges. The PR:N in the vendor vector should be verified with the vendor/NVD before using it to drive automated prioritization.

An attacker who holds (or phishes/obtains) a Grav account with page-edit permission opens a Flex form, renames a form field using the 'replace-name@' syntax, and smuggles a 'data-*@' directive past the callable allowlist check. This causes Grav to invoke a dangerous public static method such as Folder::delete, letting the editor delete site directories, overwrite arbitrary files, or read sensitive files via Utils::download. No public exploit code is identified at time of analysis, so exploitation currently requires independent development of the payload.