CVE-2026-34975: Plunk Email Platform XSS Vulnerability

CVE-2026-34975 Overview

CVE-2026-34975 is a CRLF header injection vulnerability discovered in Plunk, an open-source email platform built on top of AWS SES. Prior to version 0.8.0, a critical security flaw was identified in SESService.ts where user-supplied values for from.name, subject, custom header keys/values, and attachment filenames were interpolated directly into raw MIME messages without proper sanitization. This vulnerability allows an authenticated API user to inject arbitrary email headers by embedding carriage return/line feed characters in these fields.

Critical Impact

Authenticated attackers can inject arbitrary email headers (e.g., Bcc, Reply-To) enabling silent email forwarding, reply redirection, or sender spoofing through CRLF injection.

Affected Products

• Plunk versions prior to 0.8.0
• Plunk instances using SESService.ts for email processing
• Deployments with authenticated API access

Discovery Timeline

• 2026-04-06 - CVE CVE-2026-34975 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-34975

Vulnerability Analysis

This vulnerability falls under CWE-93 (Improper Neutralization of CRLF Sequences). The core issue lies in how Plunk's SESService.ts handles user-controlled input when constructing raw MIME email messages. The service directly interpolates user-supplied values without sanitizing or validating for carriage return (\r) and line feed (\n) characters.

In email protocols, CRLF sequences (\r\n) serve as delimiters between headers. When an attacker can inject these characters into header fields, they can effectively terminate the current header and begin injecting arbitrary new headers. This breaks the intended structure of the email message and allows manipulation of how email servers and clients process the message.

The vulnerability is particularly concerning because it affects multiple input vectors simultaneously: the sender name field (from.name), the subject line, custom header keys and values, and attachment filenames. Each of these represents a potential injection point that an authenticated attacker could exploit.

Root Cause

The root cause is insufficient input validation in the SESService.ts file. User-controlled data was being concatenated directly into raw MIME message construction without filtering or escaping CRLF sequences. While the application had existing validation for the contentId field that properly rejected \r and \n characters, this same validation was not consistently applied to other user-controllable fields that ultimately became part of the email headers.

Attack Vector

The attack requires authenticated API access to the Plunk platform. An attacker with valid API credentials can craft malicious input containing CRLF sequences in any of the vulnerable fields. For example, by injecting \r\nBcc: attacker@malicious.com into the from.name field, an attacker could add a blind carbon copy recipient to silently receive copies of all emails. Similarly, injecting a Reply-To header could redirect user replies to an attacker-controlled address, facilitating phishing or data interception scenarios.

The attack is network-accessible and requires low complexity to execute. The changed scope in the attack allows the vulnerability to impact components beyond the vulnerable service itself—specifically, the email recipients and their mail systems.

For detailed technical information and proof-of-concept scenarios, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-34975

Indicators of Compromise

• Unexpected email headers such as additional Bcc, Cc, or Reply-To fields in outgoing emails
• API requests containing %0d, %0a, \r, or \n encoded characters in email-related parameters
• Anomalous email routing patterns showing messages being delivered to unexpected recipients
• Log entries showing malformed MIME content or header parsing errors

Detection Strategies

• Implement input validation monitoring to detect and alert on CRLF character sequences in API requests
• Review email server logs for messages with unexpected or duplicate headers
• Monitor API access patterns for authenticated users attempting to inject control characters
• Deploy web application firewall rules to detect and block CRLF injection attempts in email-related endpoints

Monitoring Recommendations

• Enable verbose logging for the Plunk API to capture full request payloads for forensic analysis
• Set up alerts for any API errors related to malformed email content or header construction
• Monitor outbound email patterns for unusual recipient additions or routing changes
• Implement rate limiting and anomaly detection on API endpoints that handle email composition

How to Mitigate CVE-2026-34975

Immediate Actions Required

• Upgrade Plunk to version 0.8.0 or later immediately
• Review recent API logs for any suspicious activity containing CRLF sequences
• Audit sent emails for unexpected header injections or unauthorized recipients
• Temporarily restrict API access to trusted users until patching is complete

Patch Information

The vulnerability has been fixed in Plunk version 0.8.0. The fix implements input validation at the schema level to reject any fields containing \r or \n characters, consistent with the existing validation already applied to the contentId field. Organizations should upgrade to version 0.8.0 or later to address this vulnerability. For more details, see the GitHub Security Advisory.

Workarounds

• Implement a reverse proxy or WAF rule to strip or block requests containing CRLF characters in email-related parameters
• Add custom input validation middleware to sanitize from.name, subject, custom headers, and attachment filename fields before they reach SESService.ts
• Restrict API authentication tokens to trusted internal services only until the patch can be applied
• Monitor and alert on any API requests containing encoded newline characters (%0d%0a, %0D%0A)

# Example WAF rule to block CRLF injection attempts
# Add to your reverse proxy configuration (nginx example)
if ($request_body ~* "(\%0d|\%0a|\\r|\\n)") {
    return 403;
}