CVE-2026-85601 in Grav
Summary
by MITRE • 09/04/2026
Grav Admin before 2.0.20 fails to sanitize output from marked.parse() before injecting it into the DOM via Svelte's {@html} directive in MarkdownEditor and MarkdownModal components. Attackers can inject javascript: URI schemes in plugin or theme changelogs to execute arbitrary code in authenticated admin sessions without requiring site access.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified as a Cross-Site Scripting (XSS) flaw within Grav Admin versions prior to 2.0.20 stems from an insufficient sanitization of user-supplied input during the rendering process of Markdown content. Specifically, the application utilizes the marked.parse() function to convert Markdown syntax into HTML fragments. While this library is effective for formatting text, it does not inherently strip dangerous scripting elements or URI schemes that could be embedded within the source material. The critical failure occurs when these parsed HTML strings are subsequently injected directly into the Document Object Model (DOM) using Svelte's {@html} directive within the MarkdownEditor and MarkdownModal components. This mechanism bypasses standard browser-level protections because the content is treated as trusted HTML by the framework, allowing any embedded scripts or event handlers to execute immediately upon rendering.
The operational impact of this vulnerability is significant for administrators who possess authenticated access to the Grav Admin panel but do not necessarily have direct file system access or FTP credentials. An attacker can exploit this weakness by injecting malicious JavaScript code disguised within plugin or theme changelog entries, which are often displayed in these Markdown components. By crafting a payload that utilizes javascript: URI schemes or inline event handlers such as onerror or onload attributes, the adversary can achieve Remote Code Execution (RCE) within the context of the victim's browser session. This allows for actions including but not limited to stealing administrative cookies and session tokens, performing unauthorized configuration changes, defacing the website interface, or pivoting further into the internal network if the admin panel is accessible from trusted networks.
From a classification perspective, this vulnerability aligns with CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as Cross-Site Scripting (XSS). More specifically, it represents an instance of Stored XSS because the malicious payload is persisted within the application's data store via changelog entries and later retrieved and executed in a user's browser. In terms of offensive security frameworks, this attack vector corresponds to ATT&CK technique T1059: Command and Scripting Interpreter, where JavaScript serves as the scripting language for execution. It also relates to T1204: User Execution, as it requires an authenticated administrator to view the compromised changelog entry within the specific UI components that trigger the rendering logic.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade Grav Admin to version 2.0.20 or later, where this sanitization gap has been addressed by developers through improved input validation and output encoding mechanisms. For environments that cannot be immediately upgraded, administrators should restrict access to the admin panel using strong authentication methods such as multi-factor authentication (MFA) and IP whitelisting to reduce the attack surface. Additionally, implementing a Content Security Policy (CSP) with strict directives can help mitigate the impact of successful XSS attacks by preventing the execution of inline scripts and restricting sources from which content can be loaded. Developers should also adopt a principle of least privilege when handling dynamic HTML injection, ensuring that any data passed to {@html} directives is rigorously sanitized using established libraries like DOMPurify before rendering.