CVE-2026-104083 in SmarterMail
Summary
by MITRE • 10/09/2026
SmarterMail before build 9777 contains a stored mutation cross-site scripting vulnerability that allows remote attackers to inject executable script by placing payloads inside a <style> element nested within MathML foreign content (<math><mtext><mglyph>), which the custom HTML sanitizer treats as inert CDATA text but browsers reparse as live markup. Attackers can deliver a crafted calendar (iCal) message containing an <img src=x onerror=...> payload that executes automatically in the recipient's webmail session at /interface/message-iframe when the message is opened, enabling script execution and data exfiltration unconstrained by the interface's permissive Content-Security-Policy.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in SmarterMail versions prior to build 9777 represents a sophisticated stored cross-site scripting flaw rooted in a discrepancy between server-side sanitization logic and client-side browser rendering engines. This specific weakness is classified under CWE-80, commonly known as Improper Neutralization of Script-Related HTML Tags in a Web Page, but it exhibits characteristics of CWE-913 due to the complex interaction with MathML foreign content contexts. The core technical flaw arises from how the application's custom HTML sanitizer processes nested elements within MathML tags. Specifically, when an attacker injects script payloads inside a style element that is itself nested within a math tag containing mtext and mglyph elements, the server-side parser incorrectly interprets this structure as inert CDATA text. Consequently, the sanitization process fails to strip or escape the malicious content, allowing it to be stored in the database without modification.
The operational impact of this vulnerability is significant because it enables remote attackers to execute arbitrary JavaScript code within the context of a victim's webmail session. The attack vector typically involves delivering a crafted calendar message formatted as an iCal file that contains the malformed HTML structure described above. When the recipient opens this message in their browser, specifically within the /interface/message-iframe component, the browser does not treat the content as inert text as intended by the application logic. Instead, modern browsers reparse the MathML foreign content and interpret the nested style element as live markup. This triggers the execution of any JavaScript contained within event handlers or other executable attributes embedded in the payload, such as an image tag with an onerror attribute designed to trigger script execution upon failure to load a resource.
This exploitation path effectively bypasses the application's Content-Security-Policy (CSP), which is configured permissively for the message viewing interface. The CSP is intended to restrict the sources from which scripts can be loaded and executed, but because the malicious code is injected directly into the DOM via the browser's native parsing of the malformed HTML rather than being fetched from an external source, it executes inline without violating standard CSP restrictions that target script-src directives. This allows for unconstrained data exfiltration, session hijacking, or further lateral movement within the mail system environment. The stored nature of this vulnerability means that a single successful injection can compromise multiple users if they view the infected message, amplifying the risk profile considerably.
From an offensive security perspective, this attack aligns with MITRE ATT&CK technique T1059.007, which covers JavaScript execution in web browsers, and specifically relates to stored XSS patterns where malicious content is persisted on a target system for later activation. The use of MathML as a vector highlights the importance of considering non-standard HTML contexts during security assessments, as many sanitizers are optimized for standard DOM structures and may overlook edge cases involving SVG or MathML namespaces. Mitigation strategies must focus on hardening the server-side sanitizer to correctly identify and neutralize scriptable content within all foreign content contexts, not just standard HTML elements. Additionally, implementing a strict Content-Security-Policy that disallows inline scripts via the 'unsafe-inline' keyword would provide an effective defense-in-depth measure, ensuring that even if such parsing discrepancies occur in the future, the malicious code cannot execute without violating policy constraints.