What Is the Nodemailer Vulnerability Fix for GHSA-p6gq-j5cr-w38f?

The Nodemailer vulnerability fix for GHSA-p6gq-j5cr-w38f addresses a security flaw in how Nodemailer handles the message-level raw option. This option is designed to allow passing a pre-formed raw email message directly to the transport layer. The problem is that in unpatched versions, using raw at the message level bypasses the disableFileAccess and disableUrlAccess security flags entirely.

These flags exist specifically to prevent Nodemailer from reading local files or making outbound HTTP requests during email composition. When an attacker can influence the raw field of an outgoing message – whether directly through an API parameter or indirectly through a template, subject line, or any user-controlled input that reaches email composition – they can:

• Read arbitrary files from the server – including .env files containing database credentials and API keys, private TLS certificates, /etc/passwd, SSH keys, and any other file accessible to the Node.js process
• Perform full-response SSRF – force the server to make HTTP requests to internal services (localhost APIs, internal databases, cloud metadata endpoints like the AWS EC2 instance metadata service at 169.254.169.254) and receive the complete response back through the email

Nodemailer Version Status at a Glance

No CVE has been assigned to GHSA-p6gq-j5cr-w38f as of publication, so it is tracked only by its GitHub Security Advisory ID. That also means npm audit may not surface it consistently – checking your installed version directly is the more reliable way to confirm the Nodemailer vulnerability fix is in place.

Are You Affected? How to Confirm You Need the Nodemailer Vulnerability Fix

You are affected if any of the following apply:

• Your project uses Nodemailer version 9.0.0 or below – this includes every 6.x, 7.x, and 8.x release, not just older ones
• You set disableFileAccess or disableUrlAccess and rely on those flags for security
• User-supplied data can reach the raw message option – even indirectly through template variables, dynamic subject lines, or any email composition parameter

Check your installed version

# Check the version in your project
npm list nodemailer

# Or read the package.json directly
cat node_modules/nodemailer/package.json | grep '"version"'

Scan the entire server for all Nodemailer installs

This is the step most teams skip – and the one that leaves servers exposed. Nodemailer may be installed in multiple projects, backup directories, staging environments, or old project copies on the same server. A single unpatched install is a risk, even if the vulnerability has no CVE attached to draw attention to it.

# Find all Nodemailer installations on the server
find / -path "*/node_modules/nodemailer" -type d 2>/dev/null

# Check the version of every install found
for dir in $(find / -path "*/node_modules/nodemailer" -type d 2>/dev/null); do
  echo "--- $dir ---"
  cat "$dir/package.json" | grep '"version"' | head -1
done

How to Apply the Nodemailer Vulnerability Fix – Step by Step

cd /var/www/your-project
npm install nodemailer@latest

# Verify the version after update
npm list nodemailer
# Should show 9.0.1 or higher

for dir in \
  "/var/www/project1" \
  "/var/www/project2" \
  "/var/www/project3"; do
  echo "--- Updating $dir ---"
  cd "$dir" && npm install nodemailer@latest
done

for dir in $(find /var/www -path "*/node_modules/nodemailer" \
  -type d 2>/dev/null); do
  echo "--- $dir ---"
  cat "$dir/package.json" | grep '"version"' | head -1
done

# Every result should show 9.0.1 or higher

# Surface all vulnerabilities in the dependency tree
npm audit

# Fix issues that can be resolved without breaking changes
npm audit fix

# Fix remaining issues that require major version bumps
# WARNING: test your app after running this
npm audit fix --force

node -e "
const bcrypt = require('bcrypt');
bcrypt.hash('test', 10)
  .then(h => bcrypt.compare('test', h))
  .then(r => console.log(
    r ? 'bcrypt working correctly' : 'bcrypt broken - check Node.js version'
  ));
"

# PM2 - restart all apps
pm2 restart all

# PM2 - restart a specific app
pm2 restart your-app-name

# systemctl
sudo systemctl restart your-app-name

# Docker Compose
docker compose down && docker compose up -d

What This Vulnerability Actually Enables – and Why the Nodemailer Fix Matters

The combination of arbitrary file read and full-response SSRF in a single vulnerability makes GHSA-p6gq-j5cr-w38f more dangerous than either capability alone.

Arbitrary file read in practice

A Node.js application’s process has filesystem access scoped to what the OS user running it can read. On many production servers, this includes .env files containing database connection strings and third-party API credentials, SSL/TLS private keys, application secrets and session signing keys, and internal configuration files referencing other services. A successful exploit leaks every credential the application has access to – not just the one the attacker was looking for.

Full-response SSRF in practice

SSRF through Nodemailer returns the complete HTTP response in the email body. This means an attacker gets not just the ability to probe internal network topology – they receive the actual response content from internal services. On cloud infrastructure, this includes AWS EC2 instance metadata at 169.254.169.254/latest/meta-data/, which can expose IAM role credentials, allowing full AWS account compromise from a Node.js email vulnerability.

Four Lessons From This Nodemailer Vulnerability