CVE-2026-3455

What it actually does

CVE-2026-3455 is a cross-site scripting vulnerability in the nodemailer mailparser package before version 3.9.3. The issue is in the textToHtml() function, which converts email text into HTML but does not correctly sanitize URLs when an attacker injects an extra quote character into a URL. If an application renders the generated HTML in a browser or webmail-style interface, attacker-controlled JavaScript can execute in the viewer’s browser. The vulnerability requires user interaction because a victim must view or interact with the rendered malicious email content, but it does not require attacker authentication if the application processes untrusted inbound email.

Why it matters to the business

Applications that use vulnerable versions of mailparser to display email content may expose users, administrators, or support staff to script execution in their browsers. Successful exploitation can lead to session theft, account actions performed as the victim, phishing overlays, malicious redirects, or unauthorized access to data visible in the affected web application. The CVSS score is moderate at 6.1, EPSS is currently low at 0.00311 with no observed 30-day increase, and it is not listed in CISA KEV, but internet-facing mail viewers, ticketing systems, CRM tools, helpdesk platforms, and security triage portals that render parsed email should still treat this as important because attacker-supplied email is a common input path.

How an attack unfolds

An attacker crafts an email containing a URL that includes an additional quote character followed by embedded JavaScript or an event-handler payload. A vulnerable application receives the message and uses mailparser before 3.9.3 to convert the email text body into HTML through textToHtml(). Because the URL is not properly sanitized, the generated HTML can break out of the intended link context and introduce executable script or HTML attributes. When a victim views the rendered email in a browser-based interface, the injected script runs in the security context of that application. From there, the attacker may attempt to steal session tokens or CSRF-protected data available to JavaScript, perform actions as the victim, redirect the victim to credential-harvesting pages, or pivot within the application based on the victim’s privileges.

How to fix it

Upgrade nodemailer mailparser to version 3.9.3 or later. If the package is included transitively through another dependency, update the parent package or use dependency resolution/override controls to force mailparser to a fixed version where compatible. Rebuild and redeploy affected applications after dependency updates. As defense in depth, sanitize rendered email HTML with a robust allowlist-based HTML sanitizer, disable or rewrite dangerous URL schemes such as javascript:, escape attribute boundaries correctly, and apply a restrictive Content Security Policy that blocks inline scripts and limits script sources. If immediate upgrade is not possible, avoid rendering textToHtml() output as trusted HTML; render email bodies as escaped plain text or pass them through a proven sanitizer before display.

How to confirm the fix worked

Confirm the installed mailparser version is 3.9.3 or later in package lock files, software composition analysis results, build artifacts, and deployed runtime images. For Node.js projects, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls mailparser, and container image dependency reports. Validate behavior by testing a non-production instance with a benign proof-of-concept email containing a quoted URL break-out payload and confirming that the payload is escaped, neutralized, or rendered as inert text rather than executable HTML. Review web responses that display parsed email and confirm dangerous characters in URLs are encoded and that javascript: URLs, injected attributes, and script tags are not present in rendered output. Also verify that browser security headers, especially Content-Security-Policy, are active on pages that display email content.

Typical attack path

1. Identify an application or workflow that ingests untrusted email and renders parsed message bodies in a browser.
2. Craft an email body containing a malicious URL with an extra quote character and embedded JavaScript or HTML event-handler content.
3. Send the malicious email to a mailbox, support address, ticketing queue, or automated processing address handled by the vulnerable application.
4. The application parses the email using a vulnerable mailparser version and calls textToHtml() to produce HTML output.
5. A victim views the rendered message in a web interface.
6. The injected script executes in the victim’s browser under the affected application’s origin.
7. The attacker uses the script execution to steal accessible data, perform actions as the victim, redirect the user, or deliver further social-engineering content.

How to detect it

To determine whether exploitation has already occurred, review logs and artifacts from systems that receive, parse, store, or display email content. Relevant sources include raw inbound email archives, mail gateway logs, helpdesk or ticketing message records, application logs for email ingestion and rendering, web server access logs for pages that display parsed email, reverse proxy logs, WAF alerts, CSP violation reports, browser telemetry, and endpoint/browser security events from users who viewed suspicious messages. Search for URLs in email bodies containing quote characters followed by HTML attributes, script tags, javascript: schemes, or common XSS event handlers. Also look for CSP violation reports referencing inline script execution, blocked javascript: navigation, or unexpected external script destinations from email-rendering pages. If suspicious messages are found, identify users who viewed them, review their session activity immediately afterward, and look for anomalous account actions, unexpected redirects, credential prompts, or data access performed through the affected web application.

• javascript:
• <script
• </script>
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onmouseenter=
• href="javascript:
• src="javascript:
• \" onerror=
• \" onload=
• \" onclick=
• \" onmouseover=
• \" autofocus onfocus=
• textToHtml(
• mailparser
• blocked-uri: inline
• violated-directive: script-src
• script-src-elem
• script-src-attr

What your security team should do

• Prioritize identifying all applications that process inbound email and render message bodies in browser-based interfaces, including helpdesk, ticketing, CRM, mail review, and security operations tools.
• Upgrade mailparser to version 3.9.3 or later wherever it appears as a direct or transitive dependency.
• Run software composition analysis across source repositories, CI artifacts, and container images to find vulnerable mailparser versions before deployment.
• If upgrade cannot be completed immediately, render parsed email as escaped plain text or sanitize output with an allowlist-based HTML sanitizer before display.
• Add or tighten Content Security Policy on pages that display email content to reduce the impact of any residual XSS.
• Search historical email, application, proxy, and web logs for suspicious URL break-out and script payload patterns associated with attempted exploitation.
• Add regression tests around textToHtml() handling of URLs containing quotes, event handlers, javascript: schemes, and HTML metacharacters.
• Monitor advisories for downstream packages that bundle or depend on mailparser, since the affected ecosystem may include applications that do not declare mailparser directly.