
// TL;DR
After an earlier address-bar spoofing bug I reported in Edge was fixed as CVE-2018-8383, I found a related issue in the same area: Edge would render a page’s dialog box first while the real site loaded in the background, letting an attacker show spoofed content or dialogs that appear to belong to the loading page. It’s a low-risk content-spoofing bug — a sub-category of address-bar spoofing — but it’s useful for making phishing more convincing. Microsoft decided it “doesn’t meet the bar” for a fix, so I’m documenting it here.
Background: the address-bar spoofing CVE
Some context first. Earlier, I found a simpler issue in Edge: the browser loads the domain in the address bar first, then performs the redirect. By holding that redirect — for example by supplying a port — it was possible to leave a misleading URL showing in the address bar. That was an address-bar spoofing vulnerability, and Microsoft fixed it in a later version of Edge as CVE-2018-8383.
This writeup is about a different bug I found afterward in the same general area — one that remained unfixed.
What is content spoofing?
Content spoofing is a sub-category of address-bar spoofing attacks. Instead of (or in addition to) faking the URL, the attacker spoofs dialog boxes or a portion of the page’s content so the victim sees something that appears to come from a legitimate, trusted page.
It’s generally rated low risk on its own — you’re manipulating what’s displayed, not executing code or stealing data directly. But it can be a meaningful aid to phishing, because it lets an attacker put convincing fake prompts or content in front of a user under the appearance of a real site.
The finding

The bug comes down to a rendering race. In Edge, when loading a page, the browser would display the page’s dialog box first, while the real destination site loaded quickly in the background.
That ordering is the problem. Because the attacker’s dialog (or injected content) appears before — and over — the genuine page that’s still loading behind it, the victim is presented with attacker-controlled content that looks like it belongs to the site now showing in the window. The spoofed dialog or content borrows the credibility of the real page loading behind it.
In practical terms: a crafted page could pop a dialog or render a portion of content that the user reasonably believes is part of a legitimate site, effectively a visual defacement / spoof in the victim’s browser.
Impact & why it matters
- It aids phishing. A fake “sign in” or “your account needs verification” dialog that appears to belong to a trusted site is more convincing than a random pop-up. Content spoofing supplies exactly that framing.
- It’s a visual trust attack. Users judge legitimacy by what the browser shows them. When the browser’s own rendering order lets an attacker control that first impression, the user’s trust signal is compromised.
- Low severity, real nuisance. No code execution or direct data theft, which is why it sits at the low end — but “low” content-spoofing bugs are routinely chained into higher-impact social-engineering campaigns.
Disclosure
I reported this to the Microsoft security team. Their response was that the report “doesn’t meet the bar” for a fix, so I didn’t pursue a follow-up. Since it was declined rather than fixed, I’m disclosing it here for awareness.
Browsers accumulate a long tail of low-risk, unpatched rendering quirks like this one, and while each is individually minor, they’re worth understanding — both as a defender evaluating what your users might be shown, and as a researcher learning how spoofing primitives are built.
Thanks for reading — happy hacking!
Leave a Reply