CVE-2026-34975
Useplunk Plunk ≤ 0.8.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:NSummary
CVE-2026-34975 is a high-severity CRLF Injection (CWE-93) vulnerability in Useplunk Plunk. Its CVSS base score is 8.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 9th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34975 is a CRLF header injection vulnerability (CWE-93) in Plunk, an open-source email platform built on top of AWS SES, affecting versions prior to 0.8.0. The flaw exists in the SESService.ts component, where user-supplied values for from.name, subject, custom header keys/values, and attachment filenames are interpolated directly into raw MIME messages without sanitization, allowing the injection of carriage return/line feed (\r\n) characters.
An authenticated API user with low privileges can exploit this vulnerability over the network with low complexity and no user interaction required. Successful exploitation enables the injection of arbitrary email headers, such as Bcc or Reply-To, facilitating silent email forwarding, reply redirection, or sender spoofing. The issue has a CVSS v3.1 base score of 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), reflecting high confidentiality impact due to scope change.
The vulnerability is addressed in Plunk version 0.8.0, which implements input validation at the schema level to reject \r or \n characters in the affected fields, consistent with prior validation applied to the contentId field. Additional details are available in the GitHub security advisory at https://github.com/useplunk/plunk/security/advisories/GHSA-2mvm-rg5v-7hfq.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-19359
Vulnerability Data
Plunk is an open-source email platform built on top of AWS SES. Prior to 0.8.0, a CRLF header injection vulnerability was discovered in SESService.ts, where user-supplied values for from.name, subject, custom header keys/values, and attachment filenames were interpolated directly into…
more
raw MIME messages without sanitization. An authenticated API user could inject arbitrary email headers (e.g. Bcc, Reply-To) by embedding carriage return/line feed characters in these fields, enabling silent email forwarding, reply redirection, or sender spoofing. The fix adds input validation at the schema level to reject any of these fields containing \r or \n characters, consistent with the existing validation already applied to the contentId field. This vulnerability is fixed in 0.8.0.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V4.2.4
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops untrusted data containing CRLF sequences from reaching the component that treats CRLF as a delimiter.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and validation to block CRLF injection.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect CRLF flaws but does not itself implement the neutralization.
Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.