CVE-2026-92595 in Nodemailer
Summary
by MITRE • 09/17/2026
Nodemailer (npm package `nodemailer`) versions 9.1.0 and earlier do not honor the `disableFileAccess` and `disableUrlAccess` sandbox options when message content is resolved through the public plugin API `MailMessage.resolveContent()` using the documented legacy three-argument signature `resolveContent(data, key, callback)`. Because `shared.resolveContent()` normalizes the missing `options` argument to an empty object, the message-level flags copied into `mail.data` by the MailMessage constructor are discarded, and `resolveContentValue()` skips both access-control checks, reaching `nmfetch(url)` or `fs.createReadStream(path)`. As a result, plugin or application code that resolves untrusted message content (html, text, attachment `path` or `href`) via this API can be induced to read arbitrary local files or issue outbound HTTP(S) requests (server-side request forgery), bypassing the sandbox the application enabled. The internal paths used by `transporter.sendMail()` (`resolveAll()`, `_convertDataImages()`, and the MIME streaming path) are not affected. Fixed in version 9.1.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Nodemailer versions 9.1.0 and earlier represents a critical failure in access control enforcement within the library's plugin API, specifically affecting the MailMessage.resolveContent method when invoked using its legacy three-argument signature. This flaw allows an attacker to bypass security sandboxes designed to prevent server-side request forgery (SSRF) and arbitrary file read attacks. The core issue stems from a discrepancy between how message-level configuration options are stored during object construction and how they are processed during content resolution via the public API. When developers configure Nodemailer with disableFileAccess or disableUrlAccess flags, these settings are intended to restrict the library's ability to fetch external resources or read local files when processing email content such as HTML images, text attachments, or other embedded data sources. However, this protection mechanism is circumvented due to improper argument handling in the resolveContent function.
Technically, the vulnerability arises because the shared.resolveContent method normalizes missing arguments by defaulting them to empty objects rather than preserving inherited context from the parent MailMessage instance. When a plugin or application code calls resolveContent with only three arguments—data, key, and callback—the options object is not passed through explicitly. Consequently, this results in an empty options object being used for that specific resolution call. Since the internal logic relies on checking these options to determine whether file system access or URL fetching should be permitted, the absence of these flags causes the security checks to be skipped entirely. The code path then proceeds directly to nmfetch for URLs or fs.createReadStream for local files without verifying if such actions are prohibited by the application's configuration. This behavior effectively nullifies the sandboxing measures intended to protect against SSRF and local file inclusion attacks when using this specific API signature.
The operational impact of this vulnerability is significant, particularly in applications that process untrusted email content or allow users to define parts of an email message dynamically. An attacker who can influence the data passed into resolveContent could craft malicious payloads designed to trigger outbound HTTP requests to internal services, leading to SSRF attacks that might expose sensitive backend infrastructure or facilitate further network pivoting. Alternatively, if file access is not disabled by other means, the attacker could read arbitrary files from the server's filesystem, potentially exposing configuration files, source code, credentials, or other sensitive data stored on disk. This risk is heightened in environments where Nodemailer is used to process emails containing user-supplied HTML or attachments with external references, as the library would blindly fetch those resources without regard for security policies. It is important to note that this vulnerability does not affect internal paths such as transporter.sendMail(), resolveAll(), _convertDataImages(), or MIME streaming processes, which correctly enforce these access controls through different code pathways.
To mitigate this risk, organizations must upgrade Nodemailer to version 9.1.1 or later, where the issue has been resolved by ensuring that options are properly inherited and applied even when using the legacy three-argument signature of resolveContent. In addition to upgrading, developers should review their usage of the MailMessage.resolveContent API and consider migrating to newer signatures if available, which may offer more explicit control over security contexts. Furthermore, it is advisable to implement defense-in-depth strategies by validating all external URLs before passing them to email processing libraries and restricting file system access at the operating system level where possible. Monitoring outbound network traffic from application servers can also help detect potential SSRF attempts resulting from this vulnerability in unpatched environments. This incident highlights the importance of rigorous input validation and consistent enforcement of security configurations across all code paths, especially when dealing with public APIs that interact with external resources or local file systems. The flaw aligns with CWE-284 Improper Access Control and is relevant to ATT&CK techniques involving Server-Side Request Forgery (T1573) and Data from Local System (T1083), emphasizing the need for comprehensive security testing that covers all API entry points rather than just primary execution flows.