CVE-2026-65644 in Rocket.Chat
Summary
by MITRE • 08/21/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Rocket.Chat versions prior to 8.8.0 and various earlier maintenance releases represents a critical Cross-Site Scripting (XSS) flaw within the platform's live chat infrastructure. This security defect is located specifically at the REST API endpoint POST /api/v1/livechat/visitor, which serves as the entry point for registering new visitors in the omnichannel system. The core technical failure lies in the application's handling of user-supplied input during this registration process. Specifically, the name field provided by an unauthenticated actor is accepted without adequate sanitization or validation checks before being persisted to the database. This lack of input validation allows attackers to inject arbitrary HTML and JavaScript content directly into the system's data store, bypassing standard security controls that should filter out malicious payloads during ingestion.
The operational impact of this vulnerability extends beyond simple script execution, as it facilitates a sophisticated social engineering attack vector against support agents. Once the malicious name is stored in raw form, it is subsequently rendered within the Omnichannel Queue side panel via the dangerouslySetInnerHTML function in the InquireSidePanelItem.tsx component. This React-specific method bypasses automatic HTML escaping, allowing the injected content to be interpreted as executable code by the browser of any agent viewing the queue interface. An attacker can craft a payload that appears as legitimate text but contains a clickable hyperlink pointing to an external domain controlled by the adversary. When an agent interacts with or views this entry in their dashboard, they are effectively presented with a deceptive link designed to trick them into visiting a malicious site.
This scenario aligns closely with CWE-79, which classifies improper neutralization of input during web page generation as Cross-site Scripting. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques such as T1059.007 for JavaScript execution and potentially T1189 for Drive-by Compromise if the linked domain hosts exploit kits or malware downloads. The severity is amplified by the fact that no authentication is required to trigger this vulnerability, making it accessible to any internet user who can reach the Rocket.Chat instance's API endpoint. This lowers the barrier to entry significantly compared to authenticated XSS vulnerabilities and increases the likelihood of successful exploitation in environments where live chat services are publicly exposed or widely used for customer support.
Mitigation strategies must focus on immediate remediation through software updates as well as architectural improvements to input handling. The primary defense is upgrading Rocket.Chat to version 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 and later, where the developers have addressed this specific input validation gap. For organizations unable to patch immediately due to operational constraints, implementing a Web Application Firewall (WAF) rule that blocks requests containing HTML tags in the visitor name field can provide temporary relief. Additionally, enforcing strict Content Security Policy headers on the agent-facing interface can help mitigate the impact of any successfully injected scripts by restricting where resources are loaded from and preventing inline script execution. Long-term architectural fixes should involve replacing dangerouslySetInnerHTML with safer rendering methods that automatically escape HTML entities or using a dedicated sanitization library like DOMPurify to clean user input before it is ever rendered in the UI.