FORSMILE
JA
セキュリティ2026/08/31

Nodemailer CVE-2026-82854: Update to 8.0.4+ — SMTP Injection via envelope.size

An SMTP command injection in Nodemailer via envelope.size. It does not occur under default settings, and scoring is split between LOW and CRITICAL. Here is how to tell whether you are actually affected.

Back to Blog

CVE-2026-82854, an SMTP command injection in the Node.js mail library Nodemailer, was published to NVD on 31 August 2026.

Most people do not need to rush. It does not occur under default settings, and the fix has been available since 25 March 2026. More interestingly, this CVE is scored LOW (2.3) by one party and CRITICAL (9.8) by another.

This article explains why the scores diverge and, more usefully, how to determine whether your own application is affected.

⚠ CVE Score — 低危険度 / LOW
2.3LOWCVSS v4.0CVE-2026-82854

The score above is from the GitHub Security Advisory — the maintainer-side assessment. It differs from the value shown on NVD. Here is why.

The scoring is split between LOW and CRITICAL

Two assessments coexist for the same CVE. Read from the numbers alone they lead to opposite conclusions, so be clear about which one you are looking at.

  • GitHub Security Advisory (GHSA-c7w3-x93f-qmm8): CVSS 4.0 2.3 / LOW, vector `CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N`
  • NVD (assessed by VulnCheck): CVSS 3.1 9.8 / CRITICAL (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`) and CVSS 4.0 9.3 / CRITICAL (`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`)

The divergence sits mainly in AT (Attack Requirements) and PR (Privileges Required), plus how large the impact is judged to be. GitHub treats exploitation as requiring a precondition (AT:P) with limited integrity impact (VI:L); VulnCheck treats it as having no precondition (AT:N) and high impact across confidentiality, integrity and availability.

This article uses the GitHub assessment, because as shown below the maintainers themselves document the precondition. Note that when checked on 31 August 2026, NIST had not finished its own analysis — the NVD API reported `vulnStatus` as `Received`.

What actually happens

When a custom `envelope` object is passed to `sendMail()` and its `size` property contains CRLF characters, the value is concatenated straight into the SMTP `MAIL FROM` command as `SIZE=...`.

Because Nodemailer writes each command to the raw TCP socket followed by `\r\n`, a CRLF inside `size` terminates `MAIL FROM` early and whatever follows is parsed as a new SMTP command. That allows injecting `RCPT TO`, which silently adds attacker-controlled recipients to outgoing mail.

Within the same function, addresses such as `from` and `to` are validated against `[\r\n<>]`, and DSN parameters are encoded via `encodeXText()`. Only `size` was missing that handling.

How to tell whether you are affected

This is the part that matters. The GitHub Security Advisory states it plainly: by default Nodemailer builds the envelope automatically from the message's `from` and `to` fields, and does not include `size`.

So the vulnerability only applies when your application explicitly passes a custom `envelope` containing `size` to `sendMail()` — and on top of that, the value has to be reachable by attacker-controlled input.

There is one further runtime condition. The affected code sits inside `if (this._envelope.size && this._supportedExtensions.includes('SIZE'))`, so `SIZE=...` is only appended when the SMTP server you connect to advertises the SIZE extension. Against a server without SIZE support, this code path never runs.

  • Search your code for an `envelope` option passed to `sendMail()`. If you never pass one, this vulnerability does not affect you
  • If you do pass one, check whether it sets a `size` property
  • If it sets `size`, trace where that value comes from — user input, an external API, or a database field an attacker could influence
  • Check whether the SMTP server you connect to advertises the SIZE extension (without it, the affected code path does not run)
  • Either way, move Nodemailer to 8.0.4 or later (the current line is 9.0.6)
  • Update `package-lock.json` or `yarn.lock` and confirm the resolved version with `npm ls nodemailer`

The fix shipped five months ago

Every version before 8.0.4 is affected, and the fixed release is 8.0.4.

The timeline is worth noting. 8.0.4 was published to npm on 25 March 2026, and the GitHub Advisory Database entry was published on 26 March 2026 (the `published_at` field of the GitHub Advisory API). The CVE only reached NVD on 31 August 2026 — roughly five months after the fix.

So most projects that update regularly were already patched before this CVE existed publicly. The current Nodemailer line is 9.0.6. Only projects pinned to an old version need to check.

bash
npm ls nodemailer
npm install nodemailer@^9
# to stay on the 8.x line, use 8.0.4 or later
npm install nodemailer@^8.0.4

What to take away from this one

A CVSS score depends on who assigned it. A 2.3 and a 9.8 sitting side by side, as here, is not unusual. Rather than triaging on the number alone, it is more reliable to read the precondition and check whether your application meets it.

Also: the CVE publication date is not the fix date. Here the fix led by five months. The reverse happens too — a fixed release can exist with no CVE published at all. Dependency updates should not be gated on CVE publication.

Related articles