Loading vulnerability…
CVE-2026-34975 is a CRLF header injection vulnerability in Plunk, an open-source email platform built on AWS SES, affecting versions prior to 0.8.0. In SESService.ts, user-controlled values including from.name, subject, custom header keys, custom header values, and attachment filenames were inserted directly into raw MIME email messages without sanitization for carriage return and line feed characters. Because these fields were interpolated into message headers, an authenticated API user could supply embedded \r and \n sequences to terminate the intended header and inject arbitrary additional headers into the outbound message. The issue specifically enabled manipulation of raw MIME structure and header composition during email generation. Version 0.8.0 fixes the issue by adding schema-level validation rejecting these fields when they contain CR or LF characters, aligning with existing validation already applied to the contentId field.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone proof-of-concept for CVE-2026-34975 affecting useplunk/plunk. It contains two files: a README describing the vulnerability, root cause, impact, and affected source locations, and a Python PoC script (poc.py) that demonstrates exploitation against Plunk’s email-sending API. The exploit targets Plunk’s POST /v1/send endpoint, where the backend reportedly constructs raw MIME messages by directly interpolating user-controlled values into email headers without sanitizing CRLF sequences. The PoC demonstrates four injection vectors: from.name, subject, custom header values, and attachment filename. The main exploit capability is arbitrary email header injection, especially Bcc insertion, enabling silent forwarding of outbound emails to an attacker-controlled mailbox. The script also notes possible manipulation of Reply-To, Return-Path, Sender, and MIME structure. Repository structure is minimal and focused: README.md documents the vulnerability and exploitation rationale; poc.py is the executable entry point. The Python script uses argparse and requests, builds crafted JSON payloads, prints expected raw MIME outcomes for each vector, and optionally sends one exploit request to the target endpoint using a Bearer API key. If no key is supplied, it operates in dry-run mode and prints the vulnerable code references instead of sending traffic. This is a real exploit PoC rather than a detection-only script. It requires authenticated access to the target API and appropriate sender configuration, so it is not unauthenticated RCE or takeover code. Its practical outcome is email interception/exfiltration through header injection in a web API-backed mail service.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.