Summary

Mail::Utilities.qvaluedecode and Mail::Utilities.bvaluedecode decoded only the first RFC 2047 encoded-word in a string and used an overly greedy pattern to match the charset token. A crafted, malformed encoded-word embedded in an address display name or local part could cause the decoded output to differ from what a human reviewer or downstream parser would expect, allowing an attacker to spoof the apparent sender/recipient address.

Details

Both decoders used a single String#match against a pattern such as /\=\?(.+)?\?[Qq]\?(.)\?\=/m. Two problems:

1. Single match, dropped remainder. Only the first =?charset?Q?...?= (or ?B?) word was decoded. Any additional encoded-words or surrounding text were not handled consistently, so the decoded result could silently omit or alter parts of the input. 2. Greedy charset capture. (.+)? is greedy and matches across ? delimiters, so a malformed word could span more of the string than a strict RFC 2047 parse would, changing the boundary between "encoded" and "literal" text.

Impact

Applications using mail to parse and display or authorize based on decoded header values (From, To, Reply-To, etc.) may present or act on an address different from the one a validator inspecting the raw header would see. Primary risk is spoofing / phishing and authorization-check bypass. No RCE.