Summary
- Six Nodemailer vulnerabilities received new CVE records, but several underlying advisories and fixes date back months.
- The most serious issues include server-side file disclosure and SSRF, plus improper TLS validation during OAuth2 token retrieval.
- The publication should not be treated as evidence of a new exploitation campaign or newly introduced vulnerabilities.
Six vulnerabilities affecting Nodemailer have received CVE assignments, bringing previously disclosed security issues involving server-side file access, server-side request forgery, TLS validation, and message handling into central vulnerability-tracking systems.
The 31 August CVE publication is a tracking development rather than the discovery of six new flaws. Several of the underlying Nodemailer security advisories were published earlier in 2026, and patched releases have already been available for months.
That distinction is important because vulnerability databases are frequently used as the starting point for enterprise remediation. A new CVE entry can therefore appear in scanning or software-composition tools long after a maintainer has disclosed and fixed the underlying problem.
The most serious of the group is associated with Nodemailer’s raw-message functionality and affects versions up to and including 9.0.0. It bypasses the disableFileAccess and disableUrlAccess protections intended to prevent user-controlled message content from reading local files or retrieving remote URLs.
In vulnerable applications, an attacker whose input is passed into the relevant Nodemailer message structure can cause a server-side file or HTTP resource to be read despite those restrictions. The resulting data can then become part of the email that Nodemailer sends.
That creates both arbitrary file-disclosure and full-response server-side request-forgery exposure. The practical reach depends on the embedding application: the attacker must be able to influence the relevant message data, while the information exposed is limited by the files and network locations accessible to the application process.
The issue was fixed in Nodemailer 9.0.1, released in June.
A separate vulnerability affects the way older Nodemailer releases handled TLS certificate validation when retrieving OAuth2 tokens. The affected path did not properly validate the remote certificate, creating an opportunity for credential interception where an attacker was already able to position themselves between the application and the token endpoint.
The prerequisite is therefore significant. This is not a vulnerability through which an arbitrary remote attacker can simply request OAuth credentials. It becomes relevant where the network path can be intercepted, at which point client secrets, refresh tokens, or access tokens may be exposed.
Other advisories in the set cover a similar access-control bypass in jsonTransport, CRLF injection affecting List-* header comments, SMTP command handling, and denial-of-service behaviour.
The version boundaries differ between the flaws. Some were fixed in Nodemailer 8.x releases, while the raw-message issue requires 9.0.1 or later. The project’s changelog records further hardening in later 9.0.x releases.
Nodemailer is a software library rather than a standalone mail platform, so exposure depends substantially on how applications integrate it. A library handling attacker-influenced input inherits the filesystem permissions, network access, and credentials of the application process in which it runs.
That makes security boundaries inside the library important even where the affected component is not directly internet-facing. An application may deliberately enable disableFileAccess or disableUrlAccess because it accepts partially untrusted mail content and relies on Nodemailer to prevent that content reaching local or remote resources.
A bypass of those controls undermines the application’s assumption about what the library will contain.
The delayed CVE assignments also expose a vulnerability-management timing problem. Organisations that watch a project’s own advisories or dependency updates may have dealt with the flaws months ago, while those relying heavily on central CVE feeds may only now see formal records appear in their tooling.
No active exploitation campaign has been established in the material reviewed for the six vulnerabilities. The new development should therefore not be described as a fresh Nodemailer attack wave.
Instead, the CVE publication provides a formalised view of already disclosed weaknesses across several parts of the mail library. Organisations using current releases may already have the relevant fixes; those running older versions now have clearer vulnerability identifiers against which to check their dependency inventories.
