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

CVE-2026-61816 is an uncontrolled resource consumption vulnerability (CWE-400) in the zbateson/mail-mime-parser PHP library, a popular alternative to PHP's imap* functions for parsing Internet Message Format (RFC 822) emails. The vulnerability affects versions >= 2.0.0 and < 3.0.6, and >= 4.0.0 and < 4.0.2; versions prior to 2.0.0 used a different parser and are not affected by all three attack paths. It was privately reported by Ilia Alshanetsky and publicly disclosed on June 24, 2026, with a GitHub Security Advisory published September 24, 2026. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The vulnerability stems from three independent super-linear (algorithmic complexity) parsing paths in the library (CWE-400), meaning a byte-size cap on input alone does not bound the computational work performed. First, deep multipart nesting is O(depth²): MimeParserService::findContentBoundary() tests each content line against the current part and all ancestors via ParserMimePartProxy::setEndBoundaryFound(), so a nesting depth of D costs 1+2+…+D comparisons — a ~600 KB message nested ~10,000 deep never finishes parsing. Second, many sibling parts is O(n²): PartChildrenContainer::add() uses array_splice() to append each child, reindexing the entire array on every call. Third, header buffering is unbounded: HeaderParserService::parse() reads header lines with no limit on count or total size, allowing a few megabytes of headers to hold hundreds of megabytes or more in memory. Parsing is lazy, so the cost is only incurred when getAllParts() or content reading is triggered (GitHub Advisory).

Successful exploitation results in denial of service against any PHP application that parses untrusted email using the affected library. A crafted message under 2 MB can consume seconds of CPU time or hundreds of megabytes to multiple gigabytes of RAM, potentially triggering an out-of-memory (OOM) kill of the application process. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue affecting mail servers, webmail applications, and any email processing service built on this library (GitHub Advisory).

A complete, runnable PHP proof-of-concept (PoC) is publicly available in the GitHub Security Advisory, demonstrating all three attack vectors with measured CPU and memory consumption results. The vulnerability requires no authentication, no user interaction, and is exploitable over the network, making it fully automatable. No in-the-wild exploitation has been observed as of the advisory date, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.39%, reflecting low but non-negligible exploitation probability (GitHub Advisory, Feedly).

1. Identify target: Locate PHP applications that accept untrusted email input and use zbateson/mail-mime-parser versions 2.0.0–3.0.5 or 4.0.0–4.0.1 (e.g., mail servers, webmail platforms, email processing APIs).
2. Craft malicious MIME payload: Choose one of three attack vectors:
   • Nested multipart (nestedMessage()): Generate a MIME message with ~10,000 levels of multipart nesting (~600 KB), triggering O(depth²) boundary comparisons in findContentBoundary().
   • Sibling parts (siblingMessage()): Generate a single multipart message with ~50,000 sibling parts (~1.72 MB), triggering O(n²) reindexing via array_splice() in PartChildrenContainer::add().
   • Header flooding (headerMessage()): Generate a message with ~300,000 header lines (~2.29 MB), causing unbounded memory buffering in HeaderParserService::parse().
3. Deliver the message: Send the crafted email to the target application via SMTP, an API endpoint, or any other email ingestion mechanism. The message appears as valid MIME and requires no special encoding or obfuscation.
4. Trigger parsing: The application calls MailMimeParser::parse() (lazy — no cost yet), then calls getAllParts() or reads message content, activating the super-linear code paths.
5. Achieve denial of service: The parser exhausts CPU (e.g., 2.08s for nesting depth=2000, 5.11s for 50k siblings in PoC) or memory (e.g., 380 MB for 300k headers in PoC, potentially gigabytes in real attacks), causing the process to be killed by the OS OOM killer or time out, denying service to legitimate users (GitHub Advisory).

• Network: Inbound email messages under 2 MB with unusually deep multipart nesting structures, extremely large numbers of MIME parts, or abnormally large header sections; repeated delivery of such messages from the same source IP.
• Logs: PHP error logs showing out-of-memory fatal errors (Allowed memory size exhausted) or maximum execution time exceeded errors during email parsing operations; application logs recording parse errors such as 'Maximum MIME part nesting depth reached' or 'Header count or total size limit reached while parsing headers' (present in patched versions).
• Process: PHP worker processes consuming abnormally high CPU or memory when processing incoming email; processes being killed by the OS OOM killer (oom_kill_process in kernel logs on Linux) during mail parsing.
• File System: No specific file artifacts expected, as this is a pure DoS vulnerability with no code execution component (GitHub Advisory).

Upgrade to zbateson/mail-mime-parser version 3.0.6 (or later, e.g., 3.0.7) or 4.0.2 (or later) immediately. The fixes add configurable limits on multipart nesting depth (default: 256), header count (default: 1,000), and total header size (default: 1 MB), recording a parse error when limits are exceeded rather than throwing an exception, and change sibling append from O(n²) to O(n). Version 2.x is end-of-life and will not receive patches — users on 2.x must upgrade to the 3.x or 4.x branch. As a temporary workaround until patching is complete, restrict parser exposure to untrusted input and enforce PHP memory_limit and max_execution_time constraints so that a malicious message fails its own request rather than exhausting the host (GitHub Advisory, Patch Commit 4.x, Patch Commit 3.x).

The vulnerability was found and privately reported by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches applied by the maintainer. The advisory notes that the reporter's proposed fixes directly shaped the final implementation. Coverage has appeared on automated vulnerability tracking platforms including VulDB, Vulners, and CVE Feed, as well as a Mastodon post from @thehackerwire. No significant independent researcher commentary or broader media coverage has been identified beyond standard vulnerability database aggregation (GitHub Advisory).