In early 2020, our team collaborated with independent researcher Isiraadithya to investigate the Yahoo Mail attachment handling pipeline. What we found was a stored XSS vulnerability that, when combined with Yahoo's session architecture, could have enabled full account takeover for any Yahoo Mail user. This post documents our findings, the technical details of the vulnerability, and the disclosure timeline. We are publishing this writeup now that Yahoo has confirmed the fix is deployed and the disclosure window has passed.

Background

Yahoo Mail processes incoming email attachments through a server-side rendering pipeline before displaying them to users. This pipeline handles format detection, content sanitization, and preview generation for common file types including images, PDFs, and office documents. The pipeline's purpose is to allow users to preview attachments inline without downloading them, which requires rendering potentially untrusted content within the Yahoo Mail domain context.

Rendering untrusted content within a trusted origin is inherently dangerous. Yahoo's attachment handler addressed this by running content through an HTML sanitizer that stripped known-dangerous elements and attributes before inserting the rendered output into the page. The sanitizer was effective against standard XSS vectors - script tags, event handlers, javascript: URIs, and similar payloads were correctly filtered.

However, the sanitizer had a gap in how it processed multipart MIME boundaries in email attachments, which is what caught our attention given the broader context around MIME parsing vulnerabilities at the time. CVE-2020-1940, disclosed in January 2020 against Apache SpamAssassin, highlighted parsing inconsistencies in multipart MIME handling. While our finding was distinct from that CVE, the research direction was inspired by the same class of problem.

Discovery

Our investigation began with Isiraadithya's observation that Yahoo Mail's attachment preview rendered certain HTML email attachments differently depending on the Content-Type boundary parameter. Specifically, malformed boundary declarations in multipart MIME messages caused the rendering pipeline to process content segments in an unexpected order.

We identified that when a multipart/mixed message contained a boundary string that partially matched an internal delimiter used by the rendering pipeline, the sanitizer would process the wrong content segment. The segment intended for sanitization was discarded, and a different segment - one that had bypassed the sanitizer entirely - was inserted into the DOM.

This gave us a stored XSS primitive. By crafting a multipart email with carefully structured boundary parameters, we could embed arbitrary HTML and JavaScript in a segment that the sanitizer would skip. When the recipient opened the email and the attachment preview loaded, our payload executed in the context of the Yahoo Mail origin.

Technical Details

The vulnerable behavior depended on three specific conditions.

Condition 1: Boundary collision. The multipart boundary string needed to contain a specific substring that matched an internal token used by Yahoo's rendering pipeline. We will not disclose the exact token, but it was a predictable string derived from the internal service identifier. Finding it required analyzing the behavior of the preview renderer across many different boundary strings.

Condition 2: Segment ordering. The MIME message needed to contain at least three content segments. The first segment contained benign content that would pass sanitization. The second segment contained the XSS payload. The third segment was empty. The boundary collision caused the pipeline to sanitize segment one, skip segment two (treating it as a pipeline control block), and then insert segment two's raw content into the rendered output.

Condition 3: Content-Type header. The overall message needed a Content-Type of multipart/mixed with the colliding boundary. Messages with multipart/alternative or multipart/related were processed by a different code path that was not affected.

When all three conditions were met, the XSS payload in segment two executed when the victim viewed the attachment preview. The payload ran with the full privileges of the Yahoo Mail session, including access to the session cookies and AJAX endpoints.

Impact Analysis

A stored XSS in Yahoo Mail's origin has severe implications. The attacker does not need the victim to click anything beyond opening the email. There is no URL to inspect, no redirect to notice, and no prompt to accept. The payload executes automatically when the attachment preview renders.

With JavaScript execution in the Yahoo Mail origin, an attacker could:

• Read the contents of the victim's inbox, sent folder, and drafts by making authenticated AJAX requests to Yahoo's internal API endpoints
• Send emails as the victim, enabling further phishing or social engineering
• Modify account settings, including recovery email addresses and phone numbers
• Extract session tokens and establish persistent access to the account
• Propagate the attack by sending the malicious email to the victim's contacts, creating a wormable XSS scenario

The wormable aspect was particularly concerning. Because the payload could send emails, it could automatically forward the malicious attachment to every contact in the victim's address book. Each recipient who opened the forwarded email would trigger the same payload, which would then propagate further. A single initial email could theoretically compromise thousands of accounts within hours.

We verified account takeover was possible by demonstrating that the payload could change the account's recovery email address through Yahoo's settings API. With the recovery email changed, the attacker could trigger a password reset and gain permanent control of the account even after the XSS vulnerability was patched.

Proof of Concept

Our proof-of-concept demonstrated the full attack chain: sending a crafted email, automatic payload execution on open, session token extraction, and recovery email modification. We provided Yahoo's security team with the complete PoC including the MIME structure, boundary values, and payload. In accordance with responsible disclosure practices, we are not publishing the weaponized PoC. The technical details above are sufficient for security researchers to understand the vulnerability class without enabling exploitation.

Yahoo's Response

Yahoo's security team was responsive and professional throughout the disclosure process. They acknowledged the report within 48 hours, confirmed the vulnerability within one week, and deployed a fix within 30 days. The fix addressed the root cause by modifying the rendering pipeline to sanitize all content segments regardless of boundary processing order, and by adding additional validation on boundary strings to reject those containing internal delimiter substrings.

Yahoo awarded a bounty to both our team and Isiraadithya through their HackerOne program. We appreciate Yahoo's commitment to their bug bounty program and their transparent communication during the remediation process.

Disclosure Timeline

January 15, 2020

Initial discovery of anomalous rendering behavior in attachment handler

January 28, 2020

Collaboration with Isiraadithya begins; boundary collision mechanism identified

February 5, 2020

Stored XSS confirmed with proof-of-concept in test environment

February 8, 2020

Full report with PoC submitted to Yahoo via HackerOne

February 10, 2020

Yahoo acknowledges report and begins investigation

February 17, 2020

Yahoo confirms vulnerability and classifies as High severity

March 9, 2020

Yahoo deploys fix to production environment

March 12, 2020

Fix verified by our team; bounty awarded

April 22, 2020

Public disclosure (this post)

Lessons Learned

This vulnerability reinforces several principles that guide our research methodology.

First, content rendering pipelines that process untrusted input within a trusted origin are high-value targets. The complexity of MIME parsing, format detection, and HTML sanitization creates a large attack surface. Every step in the pipeline is an opportunity for the sanitizer to lose track of which content has been validated.

Second, boundary and delimiter handling is a persistent source of parsing confusion vulnerabilities. When two systems (in this case, the MIME parser and the rendering pipeline) use similar delimiter mechanisms, collisions can cause one system to misinterpret control signals from the other. This class of bug appears across many different technologies.

Third, collaboration between researchers with complementary skills accelerates discovery. Isiraadithya's initial observation about rendering inconsistencies combined with our team's experience in MIME-based attack vectors led to a finding that neither of us would have reached as quickly alone.

We thank Yahoo's security team for their professionalism and responsiveness, and we thank Isiraadithya for the excellent collaboration on this research.