Summary
A stored cross-site scripting vulnerability in the Grav Data Manager plugin allows HTML submitted through a front-end form to execute as JavaScript when an administrator later views the saved entry in the classic admin panel. The script may run with the administrator's session privileges, including access to the administrator's origin and CSRF token.
Affected context
The issue occurs in Data Manager deployments that save front-end form submissions under user/data and later render those entries in the classic Grav admin item-detail view without output escaping. It can affect list values and ordinary text fields through different rendering behaviors. Deployments using the Grav 2.0 Admin Next interface may not be affected when they use its separate, correctly escaping rendering path.
Exploit preconditions
- Attack surface: Public front-end forms that persist submitted values - Required access: Ability to submit data through an affected form; no
administrator authentication is generally required
- Trigger point: An administrator opens or interacts with the stored entry
in the classic admin panel
- Why exploitation is possible: Stored values reach a Twig template using
the raw filter, and filtering that preserves permitted tags may leave
attributes or executable markup available to the browser
Why this happens
The vulnerable rendering path treats stored form data as trusted markup instead of contextually escaping it before inserting it into an HTML document. Applying Twig's raw filter, including after incomplete tag stripping, allows attacker-controlled content to be interpreted by the administrator's browser. This behavior maps to CWE-79, Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting.
Potential impact
- An attacker may execute JavaScript in an administrator's authenticated session.
- The script could access administrative functions available to that user.
- It could potentially read or misuse CSRF tokens exposed to the session.
- Administrative content, configuration, or stored data could be modified.
- The vulnerability could support account compromise or further site impact.
General mitigation guidance
Mitigation typically focuses on treating all submitted and persisted values as untrusted and applying context-appropriate output encoding at every rendering sink. Avoid raw rendering for user-controlled content, use allowlists and structured schemas for fields that genuinely support limited formatting, and ensure sanitization is compatible with the target HTML context. Prefer secure-by-default escaping in templates, reduce the privileges of administrative accounts and service identities, and isolate public submission workflows from sensitive administrative operations. Maintained plugin and interface components should be used according to vendor security guidance without relying on client-side controls alone.
How teams detect issues like this
Detection can include static analysis for raw template filters, unescaped output helpers, unsafe HTML insertion, and sanitization followed by reintroduction of markup. Code review should trace front-end input through persistence into administrator-facing templates and verify contextual encoding at the final sink. Dynamic testing can submit harmless marker content to each supported field type and inspect both list and detail views. Policy enforcement may require template escaping, approved sanitizers, and security tests for stored input before deployment.
