Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Authenticated editor (PR:L) stores a payload that fires only when a victim views it (UI:R) in another security context (S:C), enabling admin session/API compromise (C:H/I:H); no availability impact.
Primary rating from Vendor (https://github.com/getkirby/kirby).
CVSS VectorVendor: https://github.com/getkirby/kirby
Lifecycle Timeline
6DescriptionCVE.org
TL;DR
This vulnerability affects Kirby sites and plugins that use the writer or list fields or that use $dom->sanitize(), Sane::sanitize(), Sane\Html::sanitize(), Sane\Svg::sanitize(), Sane\Xml::sanitize(), Sane::sanitizeFile() or $file->sanitizeContents() with untrusted input.
It was possible to inject malicious markup as children of an unknown HTML/XML tag, which would then be passed through Dom::sanitize() without being correctly sanitized according to the provided sanitization rules, causing a cross-site scripting (XSS) risk.
This vulnerability is of high severity for affected sites.
The default file upload protection is *not* affected, so sites that only *validate* uploaded files are not exposed to this vulnerability. The vulnerability can only be exploited by authenticated users.
----
Introduction
Cross-site scripting (XSS) is a type of vulnerability that allows executing any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can, for example, trigger requests to Kirby's API with the permissions of the victim.
In a *stored* XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors.
Such vulnerabilities are critical if you might have potential attackers in your group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible.
A specific class of stored XSS is auto-firing, meaning the maliciously injected JavaScript code is executed by the browser when the page loads without the victim having to perform a specific action.
Affected components
The Dom::sanitize() method allows removing unwanted or malicious elements or attributes from DOM documents (which includes HTML, SVG or arbitrary XML data). Sanitized content is supposed to be protected against cross-site scripting (XSS) attacks by removing their impact from untrusted content input.
Dom::sanitize() internally checks all nodes and attributes of the DOM document. It removes nodes, attributes, processing instructions, doctypes and namespaces that are not allowed according to the provided configuration. Nodes with tags that have been explicitly blocklisted are removed together with their children. Nodes with explicitly allowlisted tags are kept. If a tag is neither allowlisted nor blocklisted, nodes with that tag are unwrapped by Dom::unwrap() (meaning the children are kept).
Dom::sanitize() is used in the following components:
- The
writerfield sanitizes all entered content on the backend before it is saved to the content file. - The
listfield performs the same sanitization as thewriterfield since Kirby 5.4.1 (and in backported versions since Kirby 4.9.1). - The
Kirby\Saneclass package includes higher-level classesSane\Html,Sane\SvgandSane\Xmlthat all rely on DOM sanitization. - These classes are in turn also used by
Sane::sanitizeFile()and$file->sanitizeContents(). - Any of the mentioned methods could also be used in site or plugin code, for example in a
file.create:beforehook that cleans uploaded SVG/HTML files.
Only the sanitization path (returning a cleaned document) is affected. The validation path is *not* affected by this vulnerability. Kirby's default upload protection performs validation, so malicious SVG or HTML uploads continue to be rejected.
Impact
In affected releases, Dom::sanitize() did not sanitize nodes that had been unwrapped from their parent node. The affected child nodes would be copied into the resulting sanitized document without being sanitized.
An authenticated Panel user who can edit a writer or list field can store markup that survives sanitization and executes as JavaScript when the content is rendered, both in the Panel and on the site frontend. This allows a lower-privileged editor to run scripts in the context of higher-privileged users (for example admins) who view the content ("stored XSS"). Where a plugin or custom code cleans uploaded SVG/HTML with the Sane API, the same flaw leaves active content in the stored file, which executes when the file is served.
Patches
The problem has been patched in Kirby 4.9.4 and Kirby 5.4.4. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, Dom::unwrap() now *moves* the allowed children to the parent instead of cloning them, so the exact nodes remain in the document and are covered by the sanitization pass.
Note that content that was passed through the sanitizer and stored as field content before the patch may contain malicious content that was not properly sanitized due to the vulnerable code. If you cannot rule out attackers under the authenticated users of a security-critical site, we advise reviewing the content for possible attacks or to re-sanitize all content of affected fields.
Credits
Thanks to Shafiq Aiman (@shafiqaimanx) for responsibly reporting the identified issue.
AnalysisAI
Stored cross-site scripting in Kirby CMS (getkirby/cms) lets an authenticated Panel editor inject markup that survives Dom::sanitize() and executes as JavaScript when content is rendered in the Panel or on the site frontend. The flaw affects the writer and list fields plus the Sane HTML/SVG/XML sanitization API, and versions ≤ 4.9.3 and 5.0.0-alpha.1 through 5.4.3 are vulnerable. No public exploit identified at time of analysis, and this is not in CISA KEV, but the vendor rates it high severity because a low-privileged editor can escalate to an admin session.
Technical ContextAI
Kirby is a flat-file PHP CMS. The root cause is CWE-79 (improper neutralization of input during web page generation) inside Kirby\Toolkit\Dom::sanitize(), which walks a DOM tree (HTML, SVG, or arbitrary XML) and removes disallowed nodes/attributes/PIs/doctypes/namespaces. Tags that are neither allowlisted nor blocklisted are 'unwrapped' via Dom::unwrap(), keeping their children. The vulnerable code cloned those unwrapped children into the result document without re-running the sanitization pass over them, so malicious markup nested under an unknown/unrecognized tag was copied through verbatim. Dom::sanitize() underpins the writer field, the list field (since 5.4.1 / backported 4.9.1), and the Sane\Html, Sane\Svg, Sane\Xml classes used by Sane::sanitizeFile() and $file->sanitizeContents(). Affected package per CPE is pkg:composer/getkirby/cms.
RemediationAI
Vendor-released patch: upgrade to Kirby 4.9.4 (https://github.com/getkirby/kirby/releases/tag/4.9.4) for the 4.x line or Kirby 5.4.4 (https://github.com/getkirby/kirby/releases/tag/5.4.4) for the 5.x line - or any later release; the vendor recommends moving to Kirby 5. In the fix, Dom::unwrap() now moves allowed children into the parent instead of cloning them, so those nodes remain covered by the sanitization pass. Critically, patching does not clean already-stored data: content sanitized and saved before the update may still contain injected payloads, so on security-critical multi-user sites you should audit existing writer/list field content (and any Sane-cleaned stored SVG/HTML files) and re-sanitize or manually review it after upgrading. As an interim compensating control before patching, restrict Panel/editing access to fully trusted users only and avoid serving stored SVG/HTML that was cleaned via the Sane API; the trade-off is reduced collaborative editing capability.
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-42687
GHSA-wr9h-4r83-f4v6