CVE-2026-63435: 
Ruby vulnerability analysis and mitigation

CVE-2026-63435 is an email address spoofing vulnerability in the Ruby mail gem (mikel/mail) caused by flawed RFC 2047 encoded-word decoding. Prior to version 2.9.1, Mail::Utilities.q_value_decode and Mail::Utilities.b_value_decode used a single String#match with an overly greedy charset capture pattern, causing only the first encoded-word to be decoded and surrounding or subsequent text to be mishandled. A crafted malformed encoded-word in an address display name or local part could make decoded From, To, or Reply-To header values differ from the raw values, enabling sender/recipient spoofing, phishing, or authorization-check bypass. The vulnerability affects all versions of the mail gem before 2.9.1 and was disclosed on July 1, 2026, with NVD publication on September 1, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory).

The root cause is classified as CWE-436 (Interpretation Conflict): the mail gem's decoders interpreted RFC 2047 encoded-words differently from how a human reviewer or downstream parser would, creating a discrepancy exploitable for spoofing. Both q_value_decode and b_value_decode used a regex pattern such as /=?(.+)??[Qq]?(.*)?=/m with two critical flaws: (1) a single String#match call decoded only the first encoded-word, silently dropping or altering any subsequent encoded-words or surrounding literal text; and (2) the greedy (.+)? charset capture matched across ? delimiters, allowing a malformed encoded-word to consume more of the string than a strict RFC 2047 parser would permit (Github Advisory, PR #1664). An attacker can craft a malformed encoded-word such as =?UTF-8?Q?spoof?Q?agent?=@example.com embedded in an address field, causing the decoded output to represent a different address than the raw header value (Patch Commit). No authentication or user interaction is required; the attack is network-accessible and automatable.

Successful exploitation allows an unauthenticated attacker to make email-processing applications display or act upon a spoofed sender or recipient address that differs from the actual raw header value. Applications that use the mail gem to parse and then authorize or display From, To, or Reply-To headers are at risk of authorization-check bypass — for example, allowlist checks based on decoded addresses could be circumvented. The primary risks are phishing (presenting a trusted sender identity to recipients) and logic bypass in email-driven workflows; there is no remote code execution, confidentiality loss, or availability impact (Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). No threat actor attribution has been reported. The EPSS score is approximately 0.328% (26th percentile), indicating a low near-term exploitation probability. The NVD SSVC assessment marks exploitation as "none" and automatable as "yes", meaning the attack can be carried out at scale without manual interaction. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Identify target application: Determine that the target Ruby application uses the mail gem (versions < 2.9.1) to parse inbound emails and makes authorization or display decisions based on decoded From, To, or Reply-To header values.
2. Craft malformed encoded-word: Construct a malformed RFC 2047 encoded-word in the address field that exploits the greedy charset capture. For example, embed a payload like "John Doe" <=?UTF-8?Q?spoof?Q?agent?=@example.com> in the From header, where the malformed encoding causes the decoded address to differ from the raw value.
3. Send the crafted email: Deliver the email to the target application via SMTP. No authentication to the target system is required — only the ability to send email.
4. Trigger decoding: The application calls Mail::Utilities.q_value_decode or Mail::Utilities.b_value_decode on the header value. Due to the single-match and greedy-pattern flaws, the decoded output misrepresents the actual address (e.g., resolves to spoof?Q?agent@example.com instead of the raw value).
5. Achieve spoofing or bypass: The application displays the spoofed sender identity to a user (phishing), or an authorization check comparing the decoded address against an allowlist passes incorrectly, granting unintended access or triggering privileged email-driven workflows (Github Advisory, Patch Commit).

• Network: Inbound emails containing RFC 2047 encoded-words with malformed or nested ? delimiters in From, To, or Reply-To headers (e.g., patterns like =?charset?Q?...?Q?...?= or unusually long charset tokens spanning ? boundaries).
• Logs: Application logs showing email header values that differ between raw SMTP-level logging and application-decoded output for the same message; authorization decisions granting access to addresses not present in the raw header.
• File System / Application: Unexpected authorization grants or allowlist bypasses in email-driven workflows where the authorized address does not match what appears in raw email headers when inspected with an independent parser.

Upgrade the mail gem to version 2.9.1 or later, which fixes both q_value_decode and b_value_decode by switching from String#match to String#gsub-based per-word decoding and tightening the charset capture regex to [^?]+ to prevent cross-delimiter matching (Github Advisory, Release 2.9.1). No configuration-based workaround is available; patching is the only reliable remediation. As a defense-in-depth measure, implement SPF, DKIM, and DMARC email authentication to reduce the effectiveness of spoofed emails, and avoid making authorization decisions solely on decoded display-name or local-part values without also validating the raw header.