How an attacker could modify your sent items!

Ashley King 20/02/2026 Microsoft

In the world of business disputes, the "Sent Items" folder is often treated as the source of truth. We implicitly trust that what sits in that folder is an exact, immutable record of what left our outbox.

But what if an attacker could trick your Outlook client into rewriting that history, just by having you look at an attachment?

This post demonstrates a security vulnerability I found in Microsoft's New Outlook, how it worked and MSRC's response.

The Vulnerability

By modifying the body of a .eml file while preserving its original Message-ID header, an attacker can force the Outlook client to corrupt the view of the victim's valid "Sent Items" folder. When the victim views the malicious attachment, Outlook encounters a Message-ID collision and incorrectly updates the in-memory display of the existing Sent Item to match the malicious attachment's content.

Proof of Concept

Prerequisite: Two email accounts (User A "Victim" and User B "Attacker").

  1. Original Transmission:
    • User A sends an email to User B containing specific financial data (e.g., "Cost: £1,850").
    • User A verifies this email is correctly stored in their "Sent Items" folder.
  2. Tampering (The Exploit Creation):
    • User B receives the email and saves it as a .eml file.
    • User B opens the .eml file in a text editor (e.g., Notepad).
    • User B modifies the HTML body to change the value (e.g., change "£1,850" to "£1,450").
    • Crucial Step: User B does not change the Message-ID header. The ID remains identical to the original sent message.
  3. Delivery:
    • User B creates a new email to User A and attaches the modified .eml file.
    • User B sends the email.
  4. Execution (The Cache Poisoning):
    • User A receives the email in Outlook Desktop.
    • User A double-clicks the attached .eml file to view it.
    • The Bug: Immediately after opening the attachment, User A navigates to their own "Sent Items" folder.
  5. Observation:
    • The original email in "Sent Items" now displays the modified value (£1,450) instead of the actual sent value (£1,850).
    • The integrity of the "Sent Items" folder has been compromised for the duration of the session.
Impact:
  • Loss of Non-Repudiation: Users can no longer trust their own mailbox history to verify past actions.
  • Fraud Facilitation: An attacker can "trick" a victim during active negotiations by making the victim's software validate a lie (e.g., convincing a finance officer they approved a different invoice amount).
  • Trust Boundary Violation: Untrusted external input (an attachment) is allowed to mutate the display of trusted internal records.

The Technical "Why": Message-ID Collisions

The core vulnerability lies in UI Integrity and Client-Side Caching.

When Outlook opens a .eml file, it loads it into memory. It appears that the client prioritizes the most recently loaded object with a specific Message-ID. Because the attacker preserved the original ID, the Outlook client assumes the attachment is the original email and updates the in-memory view of the "Sent Items" folder to match the currently open file.

The Vendor Response (MSRC)

I reported this behavior to the Microsoft Security Response Center (MSRC). After review, the report was initially closed as Won't Fix.

To investigate your report, we will need an explanation on how an attacker could use the information to exploit another user remotely without the use of social engineering

Essentially, because the attack requires the user to open an attachment, it falls under "Social Engineering" rather than a technical vulnerability.

I did push back and was asked to submit a new report. The new report was achknowledged.

We confirmed the behavior you reported. We'll continue our investigation and determine how to address this issue.

MSRC followed up and confirmed a fix was released.

A fix was released for the issue you presented. We normally do not provide acknowledgments for Low/Moderate Severity cases, but since this was tracked, we are providing you with one. Microsoft would like to recognize your efforts on our public security researcher acknowledgement page

Does this qualify for a CVE?

Based on the assessment on this one, this won't qualify for a CVE. The fix has been released for this one.

Conclusion & Mitigation

This finding serves as a reminder that email clients are complex browsers that render HTML and manage databases simultaneously.

For businesses and individuals, the takeaway is simple:

  1. Never trust a .eml attachment as a verification of a past conversation.
  2. If you suspect a discrepancy in your Sent Items, restart Outlook to force a reload from the server.
  3. When in doubt, check your "Web Access" (OWA/Gmail Web) version, as this client-side cache bug does not affect the server-side data.