CVE-2026-100673: Grav Data Manager before 1.4.5 Stored XSS via item-detail view
The Grav Data Manager plugin (getgrav/grav-plugin-datamanager) versions 1.0.1 through 1.4.4 render stored data entries in the item-detail view (admin/templates/partials/item.html.twig) without escaping, applying Twig's raw filter — in some cases after a striptags('<br>') call that PHP's striptags() bypasses by preserving allowed tags together with their attributes. An unauthenticated visitor who submits a front-end form whose submissions are saved to user/data can store an HTML payload that executes as JavaScript in the session and origin of an administrator who later opens that entry in the classic admin panel, running with that administrator's privileges and CSRF token. Execution occurs without further interaction for list values (such as checkbox or multi-select fields) and on hover for ordinary text fields. Sites using the Grav 2.0 Admin Next interface are not affected, because it renders the same data through a separate, correctly escaping code path. The issue is fixed in Data Manager 1.4.5.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
getgrav/grav-plugin-datamanagerto a version that resolves this vulnerability.Fixed in 1.4.5
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Grav Data Manager versions 1.0.1 through 1.4.4 and the classic admin panel are affected. Sites using the Grav 2.0 Admin Next interface are not affected because it uses a separate escaping code path.
What must an attacker do to exploit it?
An unauthenticated attacker must be able to submit a front-end form whose submissions are stored in user/data. The payload executes when an administrator later opens the stored entry in the classic admin panel; list values execute without further interaction, while ordinary text fields require the administrator to hover over the content.
What is the likely impact after successful exploitation?
The injected JavaScript runs in the administrator's session and origin, with that administrator's privileges and CSRF token. This can enable actions performed as the affected administrator.
How can I determine whether a site may already contain a malicious submission?
Review stored front-end form submissions in user/data, particularly entries that will be viewed through the classic admin item-detail page. Treat unexpected HTML or attributes in submitted field values as suspicious, including values in checkbox or multi-select fields.
What should be done if updating is not immediately possible?
Avoid opening untrusted stored submissions in the classic admin panel and restrict or disable unauthenticated front-end forms that save submissions to user/data where possible. Moving to the Grav 2.0 Admin Next interface avoids the affected rendering path; the available fix is Data Manager 1.4.5.