Description

Mail is an internet library for Ruby designed to handle email generation, parsing, and sending. Prior to 2.9.1, Mail::Utilities.q_value_decode and Mail::Utilities.b_value_decode used a single String#match and an overly greedy charset capture to decode only the first RFC 2047 encoded-word and mishandle surrounding or subsequent text. A crafted malformed encoded-word in an address display name or local part could cross ? delimiters and make decoded From, To, or Reply-To header values differ from the raw values inspected by a human reviewer or downstream parser, enabling apparent sender or recipient spoofing, phishing, or authorization-check bypass. This issue is fixed in version 2.9.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-01T21:18:35.287Z",
  "pubdate": "2026-09-01T21:18:35.287Z",
  "executiveSummary": "The Ruby Mail library prior to version 2.9.1 is susceptible to a security vulnerability involving the improper decoding of RFC 2047 encoded-words. This flaw, stemming from the use of overly greedy regular expressions within the decoding utilities, allows for the misinterpretation of email header fields such as From, To, and Reply-To.\nBy injecting malformed encoded-word sequences, an attacker can manipulate how these headers are parsed, causing the decoded output to deviate from the raw content presented to human reviewers or secondary security parsers. This discrepancy facilitates sophisticated sender or recipient spoofing, phishing campaigns, and the potential bypass of authorization or filtering checks that rely on header integrity.\nThe vulnerability affects systems utilizing the Mail gem for email generation and parsing. Exploitation does not require prior authentication and can be performed by any external actor capable of sending crafted emails to the vulnerable system. The impact is significant, as it undermines the trust model of email communication by allowing malicious actors to masquerade as legitimate entities or hide the true source of an email, potentially evading downstream security controls.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of Mail::Utilities.q_value_decode and Mail::Utilities.b_value_decode. Prior to version 2.9.1, these functions utilized a single String#match operation combined with an overly greedy regular expression to process RFC 2047 encoded-words. RFC 2047 defines a syntax for encoding non-ASCII characters in email headers using the format =?charset?encoding?encoded-text?=. The vulnerable implementation failed to account for subsequent text or multiple encoded-words correctly, as it only focused on parsing the initial sequence.\nThe regex-based parser exhibits an 'overly greedy' behavior regarding the charset capture group, which enables an attacker to craft a payload that crosses the standard '?' delimiters defined by the specification. By manipulating these delimiters, an attacker can effectively 'break out' of the intended scope of the encoded-word. When the library processes a maliciously crafted address display name or local part, the parser misinterprets the boundary markers.\nThe attack flow proceeds as follows: An attacker sends a crafted email containing a specially formatted header value. The input includes an encoded-word string designed to terminate prematurely or consume characters that should have been treated as distinct parts of the header. Because the Mail library parses the string incorrectly due to the greedy match, the final decoded string results in an output that appears legitimate to a human user or an application-level parser, while the actual raw data remains different. This 'semantic mismatch' creates a window for exploitation where the application performs security logic on the 'decoded' header—which may look like a legitimate sender—while the actual email content carries a different, malicious payload.\nThis vulnerability is particularly critical because downstream security filters, such as SPF, DKIM, or DMARC, might validate the raw email, while application-level access controls or display logic rely on the corrupted decoded output. By exploiting this discrepancy, an attacker can conduct effective phishing attacks or bypass authorization checks that verify the sender's identity. The issue affects all Mail gem versions before 2.9.1, and because the parsing logic is inherent to the library's utility functions, no specific privileges are required to trigger the exploit; the vulnerability is exposed whenever the library parses untrusted header data."
}