Grav CMS EUVD-2026-60598

Exploitation requires an authenticated Grav user account with page-edit permissions who does not hold the security.xss_whitelist privilege - the bypass specifically targets the check applied to non-whitelisted editors. The attacker must have access to Grav's page editing interface and the ability to save arbitrary byte sequences in page content, which is the default capability of the editor role. Exploitation is further gated by the requirement that a victim must passively navigate to the affected page (CVSS UI:P); the attacker cannot force execution without a real user visiting the URL. Installations where all editor accounts are held by fully trusted internal staff with no shared credentials are at reduced practical risk. The vulnerability does not affect unauthenticated visitors or read-only user roles, and does not provide server-side code execution.

The CVSS 4.0 score of 5.1 (Medium) accurately reflects the access prerequisites - PR:L (authenticated editor) and UI:P (passive victim interaction) - with downstream impact limited to the subsequent system (SC:L/SI:L), meaning the server itself is not directly compromised. No EPSS data was supplied and there is no CISA KEV entry, indicating no confirmed active exploitation at time of analysis. However, the practical barrier to exploitation is low: the bypass requires inserting a single malformed byte, a technique any editor-level user can apply without specialized tooling, and the flat-file storage model means payloads persist until explicitly removed. Even a mid-sized municipal IT team in swidnica running a Grav-powered intranet with shared editor accounts should treat this as a priority patch rather than a deferred risk, because the editor role is often assigned broadly in small content teams. The moderate CVSS score is appropriate for the global risk tier but may understate urgency in environments where the editor role is loosely controlled.

An authenticated editor crafts a Grav page whose content begins with a single invalid UTF-8 byte (e.g., 0x80) followed by a standard script tag payload such as a cookie-exfiltration script. When saved, preg_match() returns false for every XSS pattern under /u mode, so checkSafety() passes the content without sanitization and the page is written to disk. Any visitor who browses to the page will have their session cookie or other browser-accessible data silently transmitted to an attacker-controlled endpoint.