{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/header-injection/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":8.5,"id":"CVE-2026-34975"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["crlf","header-injection","plunk","cve-2026-34975","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003ePlunk, an open-source email platform built on top of AWS SES, is vulnerable to CRLF header injection. Prior to version 0.8.0, the application failed to properly sanitize user-supplied values for fields like \u003ccode\u003efrom.name\u003c/code\u003e, \u003ccode\u003esubject\u003c/code\u003e, custom header keys/values, and attachment filenames. This vulnerability, identified as CVE-2026-34975, allows an authenticated API user to inject arbitrary email headers by including carriage return (\u003ccode\u003e\\r\u003c/code\u003e) and line feed (\u003ccode\u003e\\n\u003c/code\u003e) characters in these fields. Successful exploitation could lead to silent email forwarding to unauthorized recipients, redirection of replies to attacker-controlled addresses, and spoofing of the sender\u0026rsquo;s identity. The vulnerability was addressed in Plunk version 0.8.0 by implementing input validation to reject any of the affected fields containing \u003ccode\u003e\\r\u003c/code\u003e or \u003ccode\u003e\\n\u003c/code\u003e characters. Defenders should ensure Plunk installations are upgraded to version 0.8.0 or later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains authenticated access to the Plunk API.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious API request to send an email.\u003c/li\u003e\n\u003cli\u003eIn the \u003ccode\u003efrom.name\u003c/code\u003e, \u003ccode\u003esubject\u003c/code\u003e, custom header keys/values, or attachment filename fields, the attacker injects carriage return (\u003ccode\u003e\\r\u003c/code\u003e) and line feed (\u003ccode\u003e\\n\u003c/code\u003e) characters followed by arbitrary email headers. For example: \u003ccode\u003eSubject: legitimate subject\\r\\nBcc: attacker@example.com\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Plunk application, prior to version 0.8.0, processes the request without proper sanitization. The injected CRLF sequences are interpreted as header delimiters, and the attacker-supplied headers are added to the email.\u003c/li\u003e\n\u003cli\u003eThe Plunk application constructs a raw MIME message including the injected headers.\u003c/li\u003e\n\u003cli\u003ePlunk sends the email via AWS SES.\u003c/li\u003e\n\u003cli\u003eThe recipient receives the email, which now includes the attacker-injected headers (e.g., \u003ccode\u003eBcc\u003c/code\u003e, \u003ccode\u003eReply-To\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as silently receiving a copy of the email (Bcc), redirecting replies to an attacker-controlled address (Reply-To), or impersonating another sender (From).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of the CRLF injection vulnerability (CVE-2026-34975) in Plunk can lead to significant confidentiality and integrity breaches. Attackers can silently intercept sensitive email communications by adding themselves as Bcc recipients. They can also redirect replies to attacker-controlled addresses, potentially gaining access to further information. Furthermore, attackers can spoof the sender\u0026rsquo;s identity, enabling them to conduct phishing attacks or distribute malicious content under the guise of a trusted source. The number of potential victims is proportional to the number of Plunk users and the sensitivity of the information they handle. The risk is particularly high for organizations using Plunk to manage critical communications or sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Plunk to version 0.8.0 or later to remediate CVE-2026-34975, which introduces input validation to prevent CRLF injection.\u003c/li\u003e\n\u003cli\u003eMonitor Plunk application logs for suspicious API requests containing carriage return (\u003ccode\u003e\\r\u003c/code\u003e) or line feed (\u003ccode\u003e\\n\u003c/code\u003e) characters in email fields. Implement a rule to detect these characters in \u003ccode\u003ecs-uri-query\u003c/code\u003e within the webserver logs.\u003c/li\u003e\n\u003cli\u003eImplement input validation on any custom email sending functionality to prevent CRLF injection vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T17:17:11Z","date_published":"2026-04-06T17:17:11Z","id":"/briefs/2024-01-30-plunk-crlf/","summary":"A CRLF header injection vulnerability in Plunk versions prior to 0.8.0 allows authenticated API users to inject arbitrary email headers, enabling silent email forwarding, reply redirection, or sender spoofing.","title":"Plunk Email Platform CRLF Header Injection Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-30-plunk-crlf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-32913","credential-access","header-injection","openclaw"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOpenClaw, a Node.js framework, is susceptible to a critical vulnerability (CVE-2026-32913) affecting versions prior to 2026.3.7. The vulnerability lies in the \u003ccode\u003efetchWithSsrFGuard\u003c/code\u003e function, which improperly validates headers. This flaw allows attackers to potentially forward custom authorization headers, such as \u003ccode\u003eX-Api-Key\u003c/code\u003e and \u003ccode\u003ePrivate-Token\u003c/code\u003e, across cross-origin redirects. Successful exploitation enables the interception of sensitive credentials intended for the original, legitimate destination. The vulnerability was reported in March 2026 and impacts applications using the vulnerable versions of OpenClaw. Defenders should prioritize patching and implementing compensating controls to prevent credential leakage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious URL targeting an OpenClaw application using a version prior to 2026.3.7.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s browser or application requests the malicious URL, including custom authorization headers like \u003ccode\u003eX-Api-Key\u003c/code\u003e or \u003ccode\u003ePrivate-Token\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003efetchWithSsrFGuard\u003c/code\u003e function in OpenClaw fails to properly validate or sanitize headers during cross-origin redirects.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their malicious server to respond with an HTTP 302 redirect to a different origin controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe victim\u0026rsquo;s client, upon receiving the redirect, unknowingly forwards the sensitive authorization headers to the attacker\u0026rsquo;s server.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s server logs or captures the leaked \u003ccode\u003eX-Api-Key\u003c/code\u003e and/or \u003ccode\u003ePrivate-Token\u003c/code\u003e values.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to gain unauthorized access to resources or data protected by those credentials on the original target application.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-32913 can lead to the leakage of sensitive API keys and private tokens. This allows unauthorized access to protected resources, potentially leading to data breaches, account compromise, and other malicious activities. While the specific number of affected applications remains unknown, all OpenClaw deployments prior to version 2026.3.7 are vulnerable. The impact is significant due to the potential for widespread credential compromise across various sectors utilizing OpenClaw for their applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenClaw to version 2026.3.7 or later to patch CVE-2026-32913 (see references for patch information).\u003c/li\u003e\n\u003cli\u003eImplement server-side validation to sanitize and strip potentially sensitive authorization headers before following redirects.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious Header Forwarding\u003c/code\u003e to identify potential exploitation attempts by monitoring for cross-origin redirects involving sensitive headers.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual redirect activity and suspicious user agents (see log source information in the Sigma rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-24T12:00:00Z","date_published":"2026-03-24T12:00:00Z","id":"/briefs/2026-03-openclaw-header-leak/","summary":"OpenClaw before 2026.3.7 is vulnerable to improper header validation in fetchWithSsrFGuard, allowing attackers to intercept sensitive authorization headers via cross-origin redirects.","title":"OpenClaw Improper Header Validation Leads to Credential Leakage","url":"https://feed.craftedsignal.io/briefs/2026-03-openclaw-header-leak/"}],"language":"en","title":"CraftedSignal Threat Feed — Header-Injection","version":"https://jsonfeed.org/version/1.1"}