CVE-2026-65644: unauth stored HTML injection

CISO Take

An unauthenticated REST endpoint in Rocket.Chat's Livechat feature accepts a visitor 'name' field with zero sanitization, stores it raw, and renders it via dangerouslySetInnerHTML inside the Omnichannel Queue panel that support agents watch all day — meaning anyone on the internet can plant a real, clickable, attacker-controlled link with arbitrary social-engineering copy directly into a trusted internal tool. No CVSS score, EPSS data, or CISA KEV listing is published yet, and there's no known public exploit or Nuclei template, so this hasn't been weaponized at scale — but the barrier to entry is trivial: no authentication, no privileges, just a single crafted API call. The real risk isn't code execution on the server, it's that support agents — who often hold elevated access to backend systems, customer data, or AI-assisted handoff tooling — are being phished from inside a console they implicitly trust. Patch to 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8, or 7.10.15 (whichever matches your branch) and treat this as a priority item for any team running customer-facing Livechat, since the fix is already merged upstream (PR #41595) and disclosed via HackerOne.

Sources: NVD ATLAS

What is the risk?

Moderate severity, low exploitation complexity. There is no authentication or privilege requirement — the visitor registration endpoint is public by design — so any attacker can inject content with a single unauthenticated HTTP request. The impact is contained to the browser context of Livechat/Omnichannel agents (stored HTML/link injection, CWE-79) rather than server-side code execution, and no CVSS score, EPSS percentile, KEV listing, or public exploit/scanner exists yet, so near-term mass exploitation is unlikely. However, the trivial exploitation bar combined with a human-in-the-loop target (support agents who routinely click links as part of their job) makes this a realistic, low-cost social engineering vector for targeted campaigns against organizations running public Livechat widgets.

How does the attack unfold?

Entry point

Attacker sends an unauthenticated POST to /api/v1/livechat/visitor with a crafted HTML anchor tag in the 'name' field.

AML.T0049

Stored injection

Rocket.Chat stores the unsanitized name field raw in the database without escaping (CWE-79).

Rendering to target

The malicious link renders live and clickable inside the Omnichannel Inquire Side Panel viewed by support agents, via dangerouslySetInnerHTML.

AML.T0011.003

Impact

An agent clicks the link, leading to credential phishing, malware delivery, or compromise of an account that may hold elevated backend or AI-tooling access.

Entry point

Attacker sends an unauthenticated POST to /api/v1/livechat/visitor with a crafted HTML anchor tag in the 'name' field.

AML.T0049

Stored injection

Rocket.Chat stores the unsanitized name field raw in the database without escaping (CWE-79).

Rendering to target

The malicious link renders live and clickable inside the Omnichannel Inquire Side Panel viewed by support agents, via dangerouslySetInnerHTML.

AML.T0011.003

Impact

An agent clicks the link, leading to credential phishing, malware delivery, or compromise of an account that may hold elevated backend or AI-tooling access.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

Patch immediately to Rocket.Chat 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8, or 7.10.15 (select the release matching your current branch) — the fix is already merged (github.com/RocketChat/Rocket.Chat/pull/41595). Until patched, restrict or rate-limit unauthenticated access to POST /api/v1/livechat/visitor at the reverse proxy/WAF layer if Livechat is not actively needed publicly. As a compensating control, train Omnichannel agents to treat any embedded link inside a visitor's display name as untrusted and never click it directly from the queue view. For detection, review Livechat visitor registration logs for names containing HTML tags, 'href=', or URL patterns, and audit historical Inquire queue entries for anomalous injected content.

How is it classified?

Social Engineering Code Execution API AML.T0011.003 - Malicious Link AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MANAGE-4.1 - Third-party AI system risks are periodically monitored

Frequently Asked Questions

What is CVE-2026-65644?

An unauthenticated REST endpoint in Rocket.Chat's Livechat feature accepts a visitor 'name' field with zero sanitization, stores it raw, and renders it via dangerouslySetInnerHTML inside the Omnichannel Queue panel that support agents watch all day — meaning anyone on the internet can plant a real, clickable, attacker-controlled link with arbitrary social-engineering copy directly into a trusted internal tool. No CVSS score, EPSS data, or CISA KEV listing is published yet, and there's no known public exploit or Nuclei template, so this hasn't been weaponized at scale — but the barrier to entry is trivial: no authentication, no privileges, just a single crafted API call. The real risk isn't code execution on the server, it's that support agents — who often hold elevated access to backend systems, customer data, or AI-assisted handoff tooling — are being phished from inside a console they implicitly trust. Patch to 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8, or 7.10.15 (whichever matches your branch) and treat this as a priority item for any team running customer-facing Livechat, since the fix is already merged upstream (PR #41595) and disclosed via HackerOne.

Is CVE-2026-65644 actively exploited?

No confirmed active exploitation of CVE-2026-65644 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-65644?

Patch immediately to Rocket.Chat 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8, or 7.10.15 (select the release matching your current branch) — the fix is already merged (github.com/RocketChat/Rocket.Chat/pull/41595). Until patched, restrict or rate-limit unauthenticated access to POST /api/v1/livechat/visitor at the reverse proxy/WAF layer if Livechat is not actively needed publicly. As a compensating control, train Omnichannel agents to treat any embedded link inside a visitor's display name as untrusted and never click it directly from the queue view. For detection, review Livechat visitor registration logs for names containing HTML tags, 'href=', or URL patterns, and audit historical Inquire queue entries for anomalous injected content.

What systems are affected by CVE-2026-65644?

This vulnerability affects the following AI/ML architecture patterns: Customer support / Livechat interfaces, Human-AI agent handoff consoles.

What is the CVSS score for CVE-2026-65644?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Customer support / Livechat interfacesHuman-AI agent handoff consoles

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

Rocket.Chat in versions before 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8, and 7.10.15 has a REST API endpoint POST /api/v1/livechat/visitor that accepts an unauthenticated, unsanitized name field for Livechat visitors. This name is stored raw and later rendered via dangerouslySetInnerHTML in the Omnichannel Queue side panel (InquireSidePanelItem.tsx), injecting a real, clickable HTML link - pointing to any attacker-controlled domain, with arbitrary social-engineering text - into the DOM of any agent viewing the queue.

Exploitation Scenario

An attacker with no account and no credentials sends a single unauthenticated POST to /api/v1/livechat/visitor, setting the 'name' field to a crafted HTML anchor tag pointing to an attacker-controlled domain with convincing text (e.g., 'URGENT: verify payment method here'). Rocket.Chat stores this value raw. Moments later, any support agent monitoring the Omnichannel Queue sees what looks like a normal visitor name — except it renders as a live, clickable link inside InquireSidePanelItem.tsx via dangerouslySetInnerHTML. An agent who clicks, trusting the internal console, lands on a phishing page or malware drop; if that agent's credentials also grant access to backend systems, ticketing, or AI/bot configuration tied to the Livechat pipeline, the attacker gains a foothold well beyond the original chat widget.

Weaknesses (CWE)

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.