https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 08:02:58 +0000 https://vulnerability.circl.lu/vuln/ghsa-mvxr-6m87-mv2q <p><strong>Affected:</strong> RubyGems: mail</p> <p>## Summary</p> <p>Mail::Utilities.q_value_decode and Mail::Utilities.b_value_decode 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.</p> <p>## Details</p> <p>Both decoders used a single String#match against a pattern such as /\=\?(.+)?\?[Qq]\?(.*)\?\=/m. Two problems:</p> <p>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 &#34;encoded&#34; and &#34;literal&#34; text.</p> <p>## Impact</p> <p>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.</p> <p><strong>Affected:</strong> RubyGems: mail</p> <p>## Summary</p> <p>Mail::Utilities.q_value_decode and Mail::Utilities.b_value_decode 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.</p> <p>## Details</p> <p>Both decoders used a single String#match against a pattern such as /\=\?(.+)?\?[Qq]\?(.*)\?\=/m. Two problems:</p> <p>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 &#34;encoded&#34; and &#34;literal&#34; text.</p> <p>## Impact</p> <p>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.</p> https://vulnerability.circl.lu/vuln/ghsa-mvxr-6m87-mv2q