CVE-2026-113355 in Chatwoot
Summary
by MITRE • 10/20/2026
Chatwoot before 4.14.0 contains a stored cross-site scripting vulnerability that allows account administrators to inject JavaScript by crafting video-embed links in Help Center articles. Attackers can use angle-bracket link destinations with double quotes to break out of the unescaped iframe src attribute in render_embed_from_match, executing scripts for public visitors and stealing cw_conversation widget tokens.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Chatwoot versions prior to 4.14.0 represents a significant security flaw classified as Stored Cross-Site Scripting, commonly referred to as CWE-79. This type of vulnerability occurs when an application stores untrusted data and subsequently renders it in a web page without proper validation or encoding. In the specific context of Chatwoot, this flaw resides within the Help Center module, where account administrators have the ability to create and edit articles that may include embedded media content. The security failure stems from insufficient sanitization of input fields used for video embed links, allowing malicious actors to inject executable JavaScript code into stored records rather than just transient session data.
The technical mechanism behind this exploitation involves the rendering function render_embed_from_match, which processes user-supplied URLs intended for embedding videos or other media. The application fails to properly escape special characters within these URL strings before inserting them into HTML iframe elements. Specifically, an attacker can craft a video-embed link that utilizes angle brackets and double quotes to break out of the src attribute context of the iframe tag. By injecting code such as <iframe src="javascript:alert(1)"> or similar variations, the malicious script becomes part of the stored article content. When this content is rendered by the browser, the JavaScript executes within the security context of the Chatwoot domain rather than the intended video provider's domain.
The operational impact of this vulnerability extends beyond simple defacement or alert boxes. Because the vulnerable code is executed in the context of the victim user's session, it allows for severe data theft and potential account takeover scenarios. The primary target of such an attack is the cw_conversation widget token, which serves as a critical authentication credential for real-time chat interactions within Chatwoot. By stealing this token through malicious scripts embedded in Help Center articles, attackers can impersonate legitimate users, access private conversation histories, inject messages into active chats, and potentially escalate privileges if combined with other vulnerabilities or misconfigurations. This poses a direct threat to the confidentiality and integrity of customer support communications handled by organizations using Chatwoot.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Client-side Scripting Injection and Data from Information Repositories. The attacker leverages stored content as a vector for delivery, ensuring that every user who views the compromised article is exposed to the malicious payload without requiring further interaction beyond page load. This persistence mechanism makes detection difficult through traditional perimeter defenses, as the exploit code resides within legitimate application data rather than external network traffic or executable files.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. The most effective solution is to upgrade Chatwoot to version 4.14.0 or later, where this specific input validation flaw has been addressed by the development team. For organizations unable to patch immediately due to operational constraints, implementing a Web Application Firewall with rules capable of detecting and blocking iframe src attribute manipulation attempts can provide temporary relief. Additionally, enforcing strict Content Security Policy headers that restrict inline script execution and limit allowed sources for iframes can significantly reduce the impact of successful injection attacks. Developers should also adopt secure coding standards such as OWASP Secure Coding Practices, specifically ensuring that all dynamic content is contextually encoded before being rendered in HTML attributes to prevent attribute breakout scenarios like those exploited here.