GHSA-wr9h-4r83-f4v6
GHSA-wr9h-4r83-f4v6 is a Cross-site Scripting (XSS) vulnerability in getkirby/cms. O3 Security confirms whether GHSA-wr9h-4r83-f4v6 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Kirby: Cross-site scripting (XSS) from incomplete HTML/XML sanitization in `Dom::sanitize()`
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-wr9h-4r83-f4v6.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
getkirby/cms🐘getkirby/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | getkirby/cms | all versions | 4.9.4 |
| 🐘Packagist | getkirby/cms | ≥ 5.0.0-alpha.1&&< 5.4.4 | 5.4.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for getkirby/cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update getkirby/cms to 4.9.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wr9h-4r83-f4v6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wr9h-4r83-f4v6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wr9h-4r83-f4v6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wr9h-4r83-f4v6 in your dependencies?
O3 detects GHSA-wr9h-4r83-f4v6 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.