VYPR
researchPublished May 14, 2026· Updated May 18, 2026· 1 source

Outlook Junk Folder Link Preview Bypassed by Missing URI Scheme in Phishing Email Phishing

A phishing email evaded Outlook's Junk folder link preview by using an HREF with no URI scheme, hiding the destination URL while the link remained clickable in normal view.

A newly documented phishing technique has exposed a blind spot in Microsoft Outlook's security features. Security researcher Jan Kopriva reported that a phishing email he encountered in his Junk folder bypassed Outlook's link preview mechanism by simply omitting the URI scheme (protocol) from the HREF attribute. The link, which appeared as a clickable button labeled "VIEW APRIL SALARY INCREASE," was fully functional when the message was viewed normally, but the preview pane in the Junk folder showed no link at all.

The Junk folder in Outlook is designed to strip formatting and reveal the underlying URLs of all links in a message, a feature commonly recommended by security awareness trainers as a safe way to inspect suspicious emails. Kopriva, who works at Nettles Consulting and contributes to the SANS Internet Storm Center, explained that he had long relied on this mechanism. However, the April 2026 phishing message he encountered showed no links in the preview pane, prompting him to investigate.

Upon examining the HTML source of the email, Kopriva discovered that the HREF attribute contained only a path segment—such as "/click.php—without any scheme like http:// or https://. According to RFC 3986, this is not a valid URI, so Outlook's link preview parser did not recognize it as a link and did not display it. Yet, when the message was moved to a normal folder, the link was clickable and worked as intended, likely because the email client or the underlying rendering engine treated the path as relative to a base URL or defaulted to a protocol.

This behavior undermines a common security awareness recommendation: moving suspicious emails placed in the Junk folder are stripped of formatting and all link destinations become visible to the user. Kopriva noted that he often advises non-specialists to use this feature to inspect suspicious links safely. "As it turns out, it is not as dependable a mechanism as I had believed it to be," he wrote in his analysis.

The technique is particularly concerning because it exploits a parsing inconsistency rather than a complex exploit. The technique does not require any zero-day vulnerability in Outlook itself—it simply takes advantage of how the preview mechanism handles malformed URIs. The link remains functional in the normal reading pane, meaning users who click on it without previewing could be directed to a phishing site.

Kopriva also referenced a previous SANS diary from 2020 that described how embedded tags inside an A tag could modify the HREF target in unexpected ways. However, in this case, the cause was far simpler: the missing URI scheme. He emphasized that while the HREF technically violated RFC 3986, the fact that the link worked normally made the preview failure a significant security gap.

Microsoft has not yet issued a statement or patch regarding this behavior. The technique highlights a broader challenge in email security: attackers continuously probe the boundaries of how email clients parse and render HTML. As security awareness trainers update their guidance, they may need to caution that the Junk folder preview is not foolproof and that users should remain vigilant even when no links are displayed.

For now, the best defense remains a practical demonstration of how a simple HTML trick can bypass a widely trusted security feature. Organizations may want to supplement user training with additional technical controls, such as link sandboxing or URL scanning, to catch phishing attempts that exploit such parsing quirks.

Synthesized by Vypr AI