CVE-2026-119417 in CakePHP
Summary
by MITRE • 10/30/2026
CakePHP 4.5.12, 4.6.5, 5.1.8 through 5.1.10, 5.2.14 through 5.2.15, 5.3.7, and 5.4.0 through 5.4.3 contain an email header injection vulnerability because SmtpTransport and MailTransport strip only CRLF pairs from header values, an incomplete fix for CVE-2026-77634. Attackers controlling custom headers set via Message::setHeaders() or Message::addHeaders() can insert a bare CR or LF to inject headers like Bcc, redirecting or altering outgoing mail.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The identified vulnerability represents a critical flaw in the email transport mechanisms of CakePHP versions 4.5.12, 4.6.5, and various releases within the 5.x series including 5.1.8 through 5.1.10, 5.2.14 through 5.2.15, 5.3.7, and 5.4.0 through 5.4.3. This issue is classified as an incomplete fix for the previously disclosed CVE-2026-77634, indicating that prior remediation attempts failed to fully address the root cause of email header injection. The core technical flaw lies in how SmtpTransport and MailTransport handle input sanitization when processing custom headers provided by developers via Message::setHeaders() or Message::addHeaders(). Specifically, these transport classes employ a filtering mechanism designed to strip Carriage Return Line Feed CRLF pairs from header values to prevent attackers from injecting new lines into email headers. However this implementation is flawed because it only removes complete CRLF sequences and fails to adequately handle isolated carriage return CR characters or line feed LF characters independently.
This incomplete sanitization allows an attacker who has control over custom header inputs to bypass the intended security controls by inserting a bare CR or LF character directly into a header value. In email protocols such as SMTP, headers are delimited by CRLF sequences. When an application fails to properly validate and sanitize these delimiters, it becomes possible for malicious input to be interpreted as structural elements of the email message rather than content within a specific header field. By injecting a bare CR or LF, an attacker can effectively terminate the current header line prematurely and introduce new headers that were not originally intended by the application logic. This capability fundamentally breaks the isolation between user-controlled data and system-defined protocol structures enabling unauthorized manipulation of the outgoing mail stream.
The operational impact of this vulnerability is severe as it enables email header injection attacks that can lead to significant security breaches including mass spam distribution, phishing campaigns, and reputation damage for the affected organization. An attacker leveraging this flaw could inject a Bcc header to silently copy recipients on sensitive communications thereby violating confidentiality requirements under standards such as GDPR or HIPAA depending on the data involved. Alternatively an attacker might redirect outgoing emails by modifying To or Cc fields ensuring that confidential information is sent to unauthorized external parties rather than legitimate intended recipients. Furthermore malicious actors can alter message content headers such as Content-Type or MIME boundaries potentially leading to cross-site scripting XSS attacks if the injected headers cause the email client to render untrusted HTML content safely bypassing standard security filters embedded in web applications.
From a classification perspective this vulnerability aligns with CWE-74 Improper Neutralization of Special Elements used in an Output Directory or Command known commonly as injection flaws and more specifically relates to CWE-93 Improper CRLF Injection which is the root cause allowing unauthorized header insertion. In terms of adversary tactics this behavior maps directly to ATT&CK technique T1568.002 Dynamic Resolution via Domain Fronting or similar email-based delivery mechanisms where attackers manipulate communication channels for malicious purposes although in this context it primarily facilitates data exfiltration and social engineering through compromised email infrastructure. The vulnerability persists across multiple major versions of CakePHP suggesting a systemic issue within the framework's core messaging abstraction layer that requires comprehensive remediation rather than patch-level fixes.
Mitigation strategies must prioritize immediate updates to patched versions of CakePHP where this specific CRLF handling logic has been corrected to ensure both CR and LF characters are strictly prohibited or properly encoded in all header values regardless of whether they appear as standalone characters or part of a sequence. Developers should also implement defense-in-depth measures by validating input data at the application layer before it reaches transport classes using strict allowlists for permitted characters in headers rather than relying solely on blacklist-based filtering which is inherently prone to bypasses via encoding variations or partial character sequences. Additionally enabling SPF DKIM and DMARC records helps mitigate some downstream impacts such as phishing success rates even if header injection occurs by ensuring that forged emails are flagged or rejected by recipient mail servers although this does not prevent the initial data leakage caused by Bcc injection. Regular security audits of email sending functionality combined with static analysis tools configured to detect improper CRLF handling patterns can further reduce exposure to similar vulnerabilities in custom code built upon CakePHP frameworks.