CVE-2026-86062

LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, lightrag_webui/src/components/retrieval/ChatMessage.tsx renders answer and thinking content with react-markdown, rehypeRaw, and skipHtml=false without an HTML sanitizer. An attacker who can add a document can store raw HTML that is returned through the query path and rendered as active content by MessageMarkdown. A user who later retrieves the content can execute attacker-controlled JavaScript through elements such as an iframe srcdoc; the additional Mermaid securityLevel: loose rendering path also injects generated SVG through innerHTML. The script runs in the LightRAG WebUI origin and can read the API token in localStorage and perform API actions as the victim. This issue is fixed in version 1.5.5.

LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, lightrag_webui/src/components/retrieval/ChatMessage.tsx renders answer and thinking content with react-markdown, rehypeRaw, and skipHtml=false without an HTML sanitizer. An attacker who can add a document can store raw HTML that is returned through the query path and rendered as active content by MessageMarkdown. A user who later retrieves the content can execute attacker-controlled JavaScript through elements such as an iframe srcdoc; the additional Mermaid securityLevel: loose rendering path also injects generated SVG through innerHTML. The script runs in the LightRAG WebUI origin and can read the API token in localStorage and perform API actions as the victim. This issue is fixed in version 1.5.5.

Summary

The LightRAG WebUI renders assistant/answer chat content as raw HTML — react-markdown is configured with rehypePlugins={[rehypeRaw]} and skipHtml={false} and no HTML sanitizer (rehype-sanitize), element allow-list, or custom urlTransform. Because answer content is derived from user-ingested documents, an attacker who can add a single document can store an HTML/JavaScript payload that executes in the browser of any user who later retrieves it (typically an administrator), leading to auth-token theft from localStorage and full API takeover. No authentication is required in the default configuration.

Details

Sink — lightrag_webui/src/components/retrieval/ChatMessage.tsx:

• Main answer (MessageMarkdown, lines ~348-351) and thinking content (lines ~252-272) render with rehypePlugins={[rehypeRaw, …]} and skipHtml={false}. The components map (lines ~111-156) only restyles safe formatting tags (p, h1–h4, ul, ol, li, code); there is no rehype-sanitize, no allowedElements/disallowedElements, and no custom urlTransform.
• Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
• Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, [email protected], [email protected].

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):…

LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, lightrag_webui/src/components/retrieval/ChatMessage.tsx renders answer and thinking content with react-markdown, rehypeRaw, and skipHtml=false without an HTML sanitizer. An attacker who can add a document can store raw HTML that is returned through the query path and rendered as active content by MessageMarkdown. A user who later retrieves the content can execute attacker-controlled JavaScript through elements such as an iframe srcdoc; the additional Mermaid securityLevel: loose rendering path also injects generated SVG through innerHTML. The script runs in the LightRAG WebUI origin and can read the API token in localStorage and perform API actions as the victim. This issue is fixed in version 1.5.5.

LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, lightrag_webui/src/components/retrieval/ChatMessage.tsx renders answer and thinking content with react-markdown, rehypeRaw, and skipHtml=false without an HTML sanitizer. An attacker who can add a document can store raw HTML that is returned through the query path and rendered as active content by MessageMarkdown. A user who later retrieves the content can execute attacker-controlled JavaScript through elements such as an iframe srcdoc; the additional Mermaid securityLevel: loose rendering path also injects generated SVG through innerHTML. The script runs in the LightRAG WebUI origin and can read the API token in localStorage and perform API actions as the victim. This issue is fixed in version 1.5.5.

Summary

The LightRAG WebUI renders assistant/answer chat content as raw HTML — react-markdown is configured with rehypePlugins={[rehypeRaw]} and skipHtml={false} and no HTML sanitizer (rehype-sanitize), element allow-list, or custom urlTransform. Because answer content is derived from user-ingested documents, an attacker who can add a single document can store an HTML/JavaScript payload that executes in the browser of any user who later retrieves it (typically an administrator), leading to auth-token theft from localStorage and full API takeover. No authentication is required in the default configuration.

Details

Sink — lightrag_webui/src/components/retrieval/ChatMessage.tsx:

• Main answer (MessageMarkdown, lines ~348-351) and thinking content (lines ~252-272) render with rehypePlugins={[rehypeRaw, …]} and skipHtml={false}. The components map (lines ~111-156) only restyles safe formatting tags (p, h1–h4, ul, ol, li, code); there is no rehype-sanitize, no allowedElements/disallowedElements, and no custom urlTransform.
• Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
• Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, [email protected], [email protected].

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):…

Summary

The LightRAG WebUI renders assistant/answer chat content as raw HTML — react-markdown is configured with rehypePlugins={[rehypeRaw]} and skipHtml={false} and no HTML sanitizer (rehype-sanitize), element allow-list, or custom urlTransform. Because answer content is derived from user-ingested documents, an attacker who can add a single document can store an HTML/JavaScript payload that executes in the browser of any user who later retrieves it (typically an administrator), leading to auth-token theft from localStorage and full API takeover. No authentication is required in the default configuration.

Details

Sink — lightrag_webui/src/components/retrieval/ChatMessage.tsx:

• Main answer (MessageMarkdown, lines ~348-351) and thinking content (lines ~252-272) render with rehypePlugins={[rehypeRaw, …]} and skipHtml={false}. The components map (lines ~111-156) only restyles safe formatting tags (p, h1–h4, ul, ol, li, code); there is no rehype-sanitize, no allowedElements/disallowedElements, and no custom urlTransform.
• Second sink: mermaid is initialized with securityLevel: 'loose' (line ~433) and the rendered SVG is injected via container.innerHTML = svg (line ~483) + bindFunctions(container). 'loose' disables mermaid's output sanitization, so a ```mermaid block in answer content (HTML label / click directive) is an additional script-execution path.
• Hardening (not code execution): KaTeX is set with trust: true (lines ~261/~359). \href{javascript:…} is blocked by React 19, but \includegraphics{URL} renders a live remote <img src> (arbitrary external resource load from the victim's browser). Recommend trust: false.

Source → sink: POST /documents/text or POST /documents/upload stores the document → POST /query returns it (verbatim when only_need_context=true, lightrag/api/routers/query_routes.py:27; otherwise echoed by the LLM) → the response is streamed into assistantMessage.content (lightrag_webui/src/features/RetrievalView.tsx:340) → rendered by the sink above.

react-markdown's built-in defenses do NOT cover this: it sanitizes href/src URLs (so javascript: links are blocked) and React ignores string event handlers (so <img onerror> is dropped), but raw elements such as <iframe srcdoc="…"> and <svg><script> are rendered unchanged and execute.

PoC

Benign, local-only. Tested at commit f3378a3 (v1.5.5) with react@19, [email protected], [email protected].

Fastest check (code review, ~10s): in ChatMessage.tsx, the <ReactMarkdown> that renders answers uses rehypePlugins={[rehypeRaw, …]} with skipHtml={false} and no rehype-sanitize / allow-list. Per react-markdown's own documentation, rehype-raw on untrusted input without rehype-sanitize allows HTML injection — that is the vulnerability.

Runnable proof (~2 min) — reproduces the exact renderer config and shows it execute in a browser:

mkdir xss-check && cd xss-check
npm init -y
npm install react@19 react-dom@19 react-markdown@10 rehype-raw@7
# save the script below as poc.mjs, then:
node poc.mjs
# open the generated poc.html in any browser (or headless):
#   msedge --headless=new --dump-dom "file:///ABS/PATH/poc.html"

poc.mjs:

import React from 'react';
import { renderToStaticMarkup } from 'react-dom/server';
import ReactMarkdown from 'react-markdown';
import rehypeRaw from 'rehype-raw';
import { writeFileSync } from 'fs';

// Stands in for an assistant answer built from an ingested document.
const answer =
  `<iframe srcdoc="<script>` +
  `var h=parent.document.createElement('h1');h.style.color='red';` +
  `h.textContent='XSS EXECUTED on '+(parent.document.domain||'this page');` +
  `parent.document.body.appendChild(h);parent.document.title='XSS-EXECUTED';` +
  `<\/script>"></iframe>`;

// EXACT options from ChatMessage.tsx (rehypeRaw + skipHtml:false, no sanitizer):…