GHSA-CC9R-2J5M-2M83: Parser Differential and Domain Validation Bypass in Nodemailer

A critical parser differential vulnerability, identified as GHSA-CC9R-2J5M-2M83, exists in Nodemailer versions prior to 9.1.0.\n\nThis vulnerability arises from a misaligned implementation of the Comments and Folding White Space (CFWS) specifications defined in RFC 5322.\n\nThe parsing discrepancy allows remote attackers to bypass application-level recipient-domain validation checks.\n\nSuccessful exploitation can result in the unauthorized delivery of sensitive transactional emails to an attacker-controlled destination.

Under RFC 5322, comments enclosed within parentheses represent Folding White Space (CFWS) and function as semantic delimiters.\n\nIn Nodemailer's unpatched custom address parser located in lib/addressparser/index.js, the tokenizer failed to treat the closing parenthesis of a comment as a delimiter when followed by non-break characters.\n\nInstead, the parser incorrectly applied a noBreak state across the comment boundary, causing it to join the preceding and succeeding text tokens together during reconstruction.\n\nFor example, the parser processes the input user@good-corp.com(comment)evil.com by discarding the comment but directly concatenating the domain strings into user@good-corp.comevil.com.

The vulnerability exists within the state machine of the custom Tokenizer in lib/addressparser/index.js.\n\nIn the vulnerable implementation, the tokenizer class did not recognize the closing parenthesis as a structural boundary.\n\njavascript\n// Vulnerable logic in lib/addressparser/index.js\nif (prevToken && prevToken.noBreak && data[state].length) {\n data[state][data[state].length - 1] += token.value;\n}\n\n\nThe official patch introduced in commit 902b63e935435c30f4025901c0902dce64cd8880 mitigates this behavior.\n\njavascript\n// Patched logic in lib/addressparser/index.js\nconst tail = data[state].length ? data[state][data[state].length - 1] : '';\nconst joinsAcrossComment = tail.slice(-1) === '@' || token.value.charAt(0) === '@';\n\nif (prevToken && prevToken.noBreak && data[state].length && (!prevToken.cfws || joinsAcrossComment)) {\n data[state][data[state].length - 1] += token.value;\n}\n\n\nAdditionally, the tokenizer now explicitly flags the closing parenthesis character with a cfws property:\n\njavascript\nif (chr === ')') {\n this.node.cfws = true;\n}\n

An attack requires the target application to utilize two different parsing engines: an RFC-conformant validator and Nodemailer.\n\nThe attacker first registers a domain matching the concatenated suffix, such as good-corp.comevil.com, and establishes a mail exchange server.\n\nNext, the attacker registers on the target application using the payload attacker@good-corp.com(signup)evil.com.\n\nThe application's primary validator analyzes the string, parses the comment, and confirms that the core recipient domain is good-corp.com.\n\nUpon passing validation, the application forwards the address to Nodemailer, which reconstructs the destination as attacker@good-corp.comevil.com and transmits the message to the attacker's mail server.\n\nmermaid\ngraph LR\n A["Input: user@good-corp.com(x)evil.com"] --> B["Validator Engine"]\n B -->|"Parsed: good-corp.com (Valid)"| C["Application Control"]\n C --> D["Nodemailer Engine"]\n D -->|"Parsed: good-corp.comevil.com"| E["Attacker Mailbox"]\n

The capability to redirect email delivery from authorized corporate domains to arbitrary external domains compromises critical business logic workflows.\n\nThis flaw allows attackers to intercept sensitive communications, such as password reset links, multi-factor authentication tokens, and billing invoices.\n\nBecause the vulnerability operates silently at the parser level, standard transaction logs may show successful delivery without flagging security exceptions.\n\nThe analytical CVSS v3.1 score for this vulnerability is 9.1 (Critical), reflecting low attack complexity and high confidentiality and integrity impacts.

The primary remediation is upgrading Nodemailer to version 9.1.0 or later to ensure proper tokenization of CFWS.\n\nIf upgrading is not immediately feasible, applications should implement input-hardening rules to filter out parentheses in input fields containing email addresses.\n\njavascript\n// Hardened validation rule to reject comments in email fields\nif (/[()]/.test(emailInput)) {\n throw new Error('Invalid characters in email address');\n}\n\n\nUsing a single, unified parser for both validation and transmission phases prevents the emergence of parser differentials.