Kirby CMS (<= 4.9.3) - CraftedSignal Threat Feed

Kirby: Cross-site scripting (XSS) from incomplete HTML/XML sanitization in Dom::sanitize()

hello@craftedsignal.io — Thu, 18 Jun 2026 15:25:22 +0000

A high-severity cross-site scripting (XSS) vulnerability, identified as CVE-2026-54002, affects Kirby CMS versions prior to 4.9.4 and between 5.0.0-alpha.1 and 5.4.3. This flaw stems from incomplete HTML/XML sanitization within the Dom::sanitize() method, which is integral to the platform's content processing, including writer and list fields, and Sane API functions. An authenticated Panel user can exploit this by injecting malicious markup as children of unknown HTML/XML tags. The Dom::sanitize() method fails to correctly sanitize these unwrapped child nodes, allowing the malicious content to be stored and subsequently executed as JavaScript in the browser of other users, including administrators, when they view the affected content in the Panel or on the site frontend. This creates a risk of privilege escalation and other client-side attacks.

Attack Chain

An authenticated attacker logs into the Kirby CMS Panel with legitimate credentials.
The attacker navigates to an editable content field, such as a writer or list field, or interacts with a custom plugin using the Sane API functions ($dom->sanitize(), Sane::sanitizeFile(), etc.).
The attacker crafts and injects malicious markup, specifically including JavaScript code (e.g., ) as children of an unknown HTML/XML tag (e.g., ).
The Kirby backend processes the submitted content, invoking the vulnerable Dom::sanitize() method.
Due to the flaw, Dom::sanitize() unwraps the unknown parent tag but fails to sanitize the malicious child nodes, allowing the JavaScript payload to be saved unsanitized into the content data.
Another user, potentially a higher-privileged administrator, accesses the Panel or frontend page where the maliciously injected content is displayed.
The victim's web browser renders the unsanitized content, leading to the execution of the injected JavaScript within their session context.
The executed script can steal session cookies, perform unauthorized actions via Kirby's API (e.g., privilege escalation), redirect the user, or deface the interface, compromising the victim's account and potentially the entire CMS.

Impact

The vulnerability poses a significant risk to affected Kirby CMS installations, particularly those with multiple authenticated users where some may be untrusted or malicious. Successful exploitation allows for stored XSS, meaning the injected JavaScript persists and executes each time the compromised content is viewed. This can lead to privilege escalation, enabling lower-privileged authenticated users to escalate their access by compromising higher-privileged user sessions (e.g., administrators). The impact can range from session hijacking, data exfiltration through unauthorized API calls to Kirby's backend, to defacement or other client-side attacks affecting any user viewing the malicious content. The advisory notes that content stored before patching may still contain malicious payloads, emphasizing the persistent nature of the threat.

Recommendation

Patch CVE-2026-54002: Immediately update Kirby CMS to version 4.9.4, 5.4.4, or a later release to remediate the sanitization flaw.
Review and Re-sanitize Content: If untrusted authenticated users had access to the Kirby Panel on a security-critical site, review and re-sanitize all existing content that may have passed through affected fields (e.g., writer, list fields, or custom code using Sane API) for potential malicious payloads.
Deploy Sigma Rule for XSS Attempts: Deploy the Detect CVE-2026-54002 XSS Injection in Kirby Panel Sigma rule to your webserver logs (category webserver) to identify attempts to inject XSS payloads into Kirby content fields.
Implement WAF/API Security: Implement a Web Application Firewall (WAF) or API security gateway to block requests containing known XSS patterns targeting CMS editing endpoints, acting as an additional layer of defense.

Critical Kirby CMS Vulnerability Allows Remote Admin Account Creation via Reverse Proxy Headers (CVE-2026-54003)

hello@craftedsignal.io — Thu, 18 Jun 2026 15:18:49 +0000

A critical vulnerability, tracked as CVE-2026-54003, affects Kirby CMS versions up to 4.9.3 and from 5.0.0-alpha.1 to 5.4.3. This flaw, dubbed "External Initialization," enables unauthenticated remote attackers to create the initial administrative user account, effectively installing the Kirby Panel with full control over the CMS. The vulnerability arises in specific configurations where Kirby sites, without any configured user accounts, operate behind a reverse proxy that uses the Forwarded: for=..., X-Client-IP, or X-Real-IP HTTP headers. Kirby's isLocal check, designed to prevent remote installation, failed to properly account for these headers, leading it to incorrectly assume a remote connection was local. This misidentification grants an attacker the ability to bypass security controls and seize control of the Kirby instance.

Attack Chain

Reconnaissance: Attacker identifies a publicly accessible Kirby CMS instance lacking any configured user accounts, typically indicated by a redirect to the installation wizard upon accessing the Panel URL (/panel).
Reverse Proxy Identification: Attacker determines that the target Kirby instance is fronted by a reverse proxy that uses Forwarded: for=..., X-Client-IP, or X-Real-IP headers for client IP forwarding.
Craft Malicious Request: Attacker crafts an HTTP POST request to the Kirby Panel installation endpoint (e.g., /api/system/install or similar, depending on Kirby version and setup), including a forged Forwarded, X-Client-IP, or X-Real-IP header set to a local IP address (e.g., 127.0.0.1).
Bypass isLocal Check: The crafted request containing the local IP in the vulnerable header is forwarded by the reverse proxy to the Kirby backend. Kirby's isLocal check misinterprets the request as originating from a local source due to the forged header.
Initial Admin Account Creation: The Kirby application proceeds with the installation process, allowing the attacker to provide desired credentials (username, password, email) for a new administrator account via the HTTP POST body.
Administrator Access: Upon successful submission, the attacker-defined administrator account is created, granting full administrative control over the Kirby CMS instance.
Post-Exploitation: The attacker can now perform any actions available to an administrator, including content modification, data exfiltration, plugin installation, or further system compromise.

Impact

Successful exploitation of CVE-2026-54003 grants unauthenticated attackers full administrative control over the affected Kirby CMS instance. This directly leads to complete compromise of the website, allowing for arbitrary content modification, defacement, data theft (including user information if stored), and potentially the injection of malicious code or backdoors into the web application. Given Kirby's use in various industries for content management, the potential victim scope includes any organization or individual utilizing unpatched Kirby versions behind specific reverse proxy configurations with no existing admin users. The vulnerability's criticality stems from the ease of exploitation and the immediate elevation to administrative privileges.

Recommendation

Patch CVE-2026-54003 immediately: Update Kirby CMS to version 4.9.4, 5.4.4, or a later patched version as detailed in the advisory.
Deploy the provided Sigma rules: Implement the Detects CVE-2026-54003 Exploitation - Kirby Remote Panel Init rules to your SIEM to identify attempts to exploit this vulnerability.
Configure Workarounds: If immediate patching is not feasible, perform the Panel installation yourself by creating an initial admin account. This disables the vulnerable installation code.
Disable Panel API: As an alternative workaround, if the Panel is not needed, disable the REST API with the 'api' => false option in config.php to prevent access to the installation endpoint.
Review Reverse Proxy Configuration: Ensure your reverse proxy is configured to properly handle X-Forwarded-For or Client-IP headers if possible, or verify that Forwarded: for=..., X-Client-IP, and X-Real-IP are not inadvertently exposing internal IP addresses or being spoofed.