SUPPLY-CHAIN ATTACKS

Fake login pop-ups on trusted sites: how to spot the credential trap

A password box can appear on a website you trust without that website doing anything wrong. A hijacked third-party script can put it there. Here is how to read one, and why the right move is almost always Cancel.

SB

SafeBrowz Threat Research Security ResearchJune 11, 202610 min read

Why a site you trust can show you a fake login box

Almost every modern website pulls in code it did not write. Analytics, fonts, chat widgets, and small compatibility libraries called "polyfills" are loaded from third-party servers (content delivery networks, or CDNs) at the moment the page renders in your browser. Your browser runs that borrowed code with the same trust it gives the site you visited. That is normal, and it is everywhere.

The catch is the trust. If one of those third-party domains is taken over by an attacker, every site that still points at it starts serving the attacker's code, on the attacker's schedule, to real visitors on the real site. There is no phishing email, no bad link, no typosquatted domain. You navigated to a site you use, and the address bar is correct. The danger rode in on a script the site forgot it was still loading.

That is precisely what happened with the polyfill case. In June 2026, BleepingComputer reported that suspicious sign-in prompts began popping up on legitimate sites including Toshiba and Muji, served through the external polyfill[.]io service. The background is the original polyfill supply-chain compromise from 2024, when the domain changed hands and began injecting malicious scripts that reached a very large number of sites that embedded it. In the 2026 round, the reactivated domain started responding to requests with an HTTP 401 "authentication required" status. Browsers reading a 401 do the natural thing: they show the user a login prompt. Japanese media reported other affected brands such as Zojirushi, and a security researcher noted similar prompts appearing in some Samsung Smart TV web interfaces. At the time of the reporting, there was no confirmation that credentials typed into these screens had been collected, but the affected companies told users who had entered their details to change their passwords as a precaution. That advice is the whole point of this article.

What the fake pop-up actually looks like

You are browsing a retailer, a manufacturer support page, or a brand site you have used before. The page loads normally. Then a small box appears asking you to sign in, or it asks for your username and password "to continue." It might be a plain browser-native dialog with no styling at all, or it might be a box dressed up with the brand's colors that looks almost right but slightly off. The address bar still reads the real domain. Nothing about the URL warns you.

The tell is the timing and the context. You did not click a "Log in" or "Account" button. You did not navigate to a checkout or a members area. The page just decided, mid-browse, that you need to authenticate. A real site does not surprise you with a password demand on a product page or an article. When a credential prompt appears that you did not summon, treat it as guilty until proven innocent.

The endpoint matters too. A real login form on a real brand posts your password back to that brand's own login service. An injected fake box quietly sends what you type to a server that has nothing to do with the brand, an off-domain address that you never see because it lives in the page's code, not in your address bar. For illustration only, a harvested credential might be shipped to something like cdn-auth-verify.click or account-session-sync.top, addresses that have no relationship to the trusted brand whose page you are on. You will not spot that endpoint by eye. That is the architectural problem this whole article is about.

How a hijacked script injects a login box, in plain language

Picture the supply chain like a sandwich shop that buys bread from one bakery. The shop is honest. The customers trust the shop. But if a criminal buys the bakery and starts baking something harmful into the bread, every sandwich the shop sells is now compromised, and the shop owner may not even know for a while. The customer trusts the shop, the shop trusted the bakery, and the trust flowed straight through to the harm.

On the web, the "bakery" is the third-party script domain. When that domain is reactivated or bought by someone hostile, three things can happen, and the polyfill case showed two of them. First, the domain can simply answer requests with an HTTP 401, and your browser politely renders a built-in login prompt because that is what a 401 is supposed to mean. Second, the domain can return actual JavaScript that draws a styled login box on top of the real page and wires the form to an attacker-controlled endpoint. Either way, the box is appearing on the legitimate site, in your browser, with the real domain in the address bar. The site's own servers were never breached. The compromise lives one hop upstream, in a dependency the site embedded and trusted.

This is not fearmongering, and it is not a reason to distrust every website. It is a reason to understand one specific failure mode so you recognize it the one time it matters. The defense is simple and it is the same every time: a credential prompt you did not ask for is a prompt you do not answer.

Red flags that the login pop-up is fake

You do not need to inspect any code. The signals are all things you can see or remember.

• It appeared mid-browse, unprompted. You did not click "Sign in," "Log in," or "My account." The page asked for your password on its own. That alone is enough to stop.
• You are not on a login page. The prompt popped up over a product page, a support article, a homepage, or a TV interface, not a dedicated account screen.
• It asks for a password or 2FA code you were not in the middle of entering. A real second-factor request comes after you typed your password, not out of nowhere.
• The address bar is right but the box is wrong. The URL shows the real, trusted domain, yet the login box looks bare, slightly off-brand, or styled differently from the site's normal sign-in screen.
• It is a plain, browser-native dialog with no branding. The HTTP 401 style prompt is an unstyled gray box from your browser, not the site's polished login page. Real brands almost never authenticate you through that bare dialog.
• The wording is generic. "Authentication required," "Please sign in to continue," with no explanation of why, on a page that never needed a login before.
• It reappears or behaves oddly. Closing it and reloading brings it back instantly, or it blocks the page until you fill it in.
• You have no memory of being logged out. You were not signed out, your session did not expire, and nothing you did should have triggered a fresh login.

What SafeBrowz sees on the network

This attack is interesting precisely because the page you are on is legitimate. The trusted domain is not the problem, so a defense that only looks at the top-level URL would wave it through. SafeBrowz reads the page the way the attack actually behaves, across all three detection layers.

First, the engine does not stop at the address bar. It looks at where a credential form is trying to send what you type. A login box on a trusted brand that posts to an unrelated off-domain endpoint, especially a young domain on a cheap top-level domain, is a structural contradiction. The brand on the page does not match the destination of the data, and that mismatch is a strong signal on its own.

Second, the third-party script source is itself checked. When a page loads a library from a domain that threat-intelligence feeds have flagged as a compromised or known-bad CDN or script host, that is caught at the API layer, independent of how innocent the host page looks. A bad script origin pulls the verdict down even when the visited domain is spotless.

Third, the content of the box is analyzed. An injected credential prompt has a recognizable shape: a bare authentication dialog or a brand-styled login form rendered on a page that is not a login page, asking for a password without the user navigating there. AI content analysis (via our proxy) reads that shape and recognizes a credential-harvest pattern even on a brand-new injection that no blocklist has seen.

The summary is simple. The attack hides behind a trusted domain, so SafeBrowz judges the form and its destination, not just the domain in the address bar.

Which trusted sites attackers ride next

The polyfill case is one domain, but the technique is general. Any widely embedded third-party script is a potential single point of failure, and attackers gravitate to the dependencies that sit on the most pages with the least scrutiny. The believable next pivots follow that logic.

• Retail and e-commerce checkout pages. The highest-value place to inject a credential or card prompt, because the user already expects to enter sensitive data there.
• Consumer-electronics and appliance support portals. The polyfill round already touched manufacturer sites and smart-TV interfaces. Firmware and "register your device" pages are full of embedded helpers.
• Banking, fintech, and crypto front-ends that embed analytics or chat widgets. A single hijacked widget on a financial page is the most lucrative version of this attack.
• Media, publishing, and large content sites. They load the most third-party ad and analytics code, giving the widest blast radius from one compromised dependency.
• SaaS dashboards and login portals. A fake "your session expired, sign in again" box on a tool people use daily is highly believable.

The brand on the page is interchangeable. The mechanic, a trusted site silently serving a malicious dependency, is not. That is why the defense has to be structural rather than brand-by-brand.

Why browser-side detection beats email filtering for this one

Most phishing advice tells you to scrutinize the email. There is no email here. The attack originates on a site you chose to visit, served through code that site loads, with the correct domain in your address bar. An email gateway never sees it. A "check the sender" instinct never fires. Carrier spam filters and inbox rules are looking at a channel this attack does not use.

The attack only completes in one place: in your browser, on the page, at the moment the injected box renders and asks for your password. That is also the only place a defense can catch it, because that is the only place the malicious behavior actually exists. A browser-layer scanner sits exactly there. It can see the unexpected credential form, see that the form posts to a destination unrelated to the brand, and see that the script came from a flagged source, and it can stop you before you type, regardless of the fact that there was never an email to filter. Email security and browser security are complementary, but for an attack that starts on a legitimate site, the browser layer is the one standing where the harm happens.

How SafeBrowz blocks this threat

SafeBrowz runs a 3-layer detection architecture: Local + APIs + AI.

• Layer 1 - Local detection: 60+ URL patterns + 550+ brand-specific signatures (including Cyrillic and Punycode homograph variants) + community whitelist/blacklist, all running directly in the extension before the page renders. It flags credential forms that post to off-domain endpoints, lookalike login domains, and the cheap-TLD destinations these harvesters favor.
• Layer 2 - API checks: aggregates Google Safe Browsing, PhishTank, URLhaus, ScamAdviser, plus domain-age lookup and known-bad script and CDN host intelligence, so a compromised dependency origin is caught even when the visited site is legitimate.
• Layer 3 - AI deep scan: content-aware analysis in 100+ languages reads the injected login box itself and recognizes a credential-harvest pattern on a brand-new injection that no blocklist has seen yet.

Detection signatures are derived from threat-intelligence research and our internal brand database, not from user browsing data. SafeBrowz does not store per-user browsing history.

For people who do not want to install anything, the same engine powers the free public URL checker. If a suspicious box hands you a link, or you want to vet a page, paste it and get a verdict in seconds.

What to do when the pop-up appears

If a login box just showed up on a site you trust and you did not summon it, here is the whole correct response.

1. Do not type anything into it. Not your email, not your password, not a 2FA code. The box is the entire attack.
2. Hit Cancel, or close the tab. A plain browser dialog has a Cancel or Escape. A styled overlay can be dismissed by closing the tab outright. Dismissing it costs you nothing.
3. Sign in by typing the official address yourself. If you genuinely need to log in to that brand, open a fresh tab and type the company's real address into the address bar, or use a bookmark you saved earlier. Never authenticate through a box that appeared on its own.
4. Use a password manager as a tripwire. If your password manager refuses to auto-fill the box, that is a signal: it does not recognize the form as belonging to the real site. Trust that hesitation.
5. If the prompt keeps returning, leave the site for now. A persistent unexpected login demand means the page is misbehaving. Come back later, when the site has had time to remove the bad dependency.

What victims do right now

If you already typed your details into one of these boxes, do not panic, but move quickly. The companies in the polyfill case told affected users to change their passwords precisely because the harvested credentials may have been collected. Treat your password as exposed.

1. Change your password on the real site immediately. Go to the brand's real address yourself (type it, do not click anything from the suspicious page) and change the password for that account. If you reused that password anywhere else, change it on those sites too, starting with email and banking.
2. Turn on or re-check two-factor authentication. Enable 2FA on the affected account if it is not already on. If it was on, confirm the registered phone or authenticator is still yours and no new method was added.
3. Watch for session-token abuse, not just password use. Sign out of all active sessions in the account's security settings to invalidate any token an attacker may be riding. Then watch for unexpected login alerts, new devices, or changed recovery email and phone.
4. If you entered card details, call your bank. Use the number on the back of your card, freeze or lock the card in your banking app, and watch your statements.
5. Report it. File with the FTC at reportfraud.ftc.gov and with the FBI's Internet Crime Complaint Center at ic3.gov. Contact the brand's official support so they know the prompt appeared. If you want to confirm a suspicious endpoint or link, you can also check it at virustotal.com.

If you typed something but caught yourself before submitting, you are most likely fine: close the tab and change the password anyway as a precaution. Our full "I got scammed, what do I do now" walkthrough covers the first-hour recovery playbook in detail.

How to report it

Reporting helps the next person, and it gets the bad dependency taken down faster.

• Tell the brand. Use the company's official support contact, found by typing their real address yourself, and describe exactly where the login box appeared and what it looked like. The site owner may not yet know a third-party script is misbehaving.
• File with the FTC at reportfraud.ftc.gov if you are in the US, with the link or endpoint and a screenshot.
• File with the FBI's IC3 at ic3.gov if you entered credentials or lost money.
• Submit the suspicious page or endpoint to a public scanner like virustotal.com so other tools learn about it.

Frequently asked questions

Can a login pop-up on a website I trust really be fake?

Yes. A website you trust loads code from third-party servers when the page renders. If one of those servers is taken over, it can inject a fake login box onto the real site, with the correct domain still showing in your address bar. The site itself was not necessarily hacked. The compromise lives in a dependency it embedded. The polyfill case in June 2026 did exactly this on legitimate retailer and manufacturer sites.

What was the polyfill supply-chain attack?

Polyfill was a widely used service that delivered small compatibility scripts to a very large number of websites. In 2024 the domain changed hands and began serving malicious code. In June 2026 the reactivated domain started returning HTTP 401 responses, which made visitors' browsers display login prompts on trusted sites such as Toshiba and Muji. The companies advised users who entered their details to change their passwords.

How can I tell the difference between a real login box and a fake one?

Ask whether you summoned it. A real login appears after you click "Sign in" or navigate to an account page. A fake one pops up on its own, mid-browse, over a page that never needed a login. A bare, unbranded browser dialog asking for a password on a normal page is a strong warning sign. When in doubt, hit Cancel and sign in by typing the official address yourself.

I clicked Cancel and did not type anything. Am I safe?

If you dismissed the box without entering anything, you most likely gave away nothing. Close the tab to be sure. If you want to use that site, open a new tab and type its real address yourself rather than interacting with the page that showed the prompt. There is no harm in changing your password later as a precaution.

I entered my password into the pop-up. What do I do now?

Treat the password as exposed. Go to the brand's real site yourself and change it immediately, and change it anywhere else you reused it. Turn on two-factor authentication, sign out of all active sessions to kill any stolen token, and watch for unexpected login alerts. If you entered card details, call your bank and freeze the card. Report it at reportfraud.ftc.gov and ic3.gov.

Why does email or spam filtering not stop this?

Because there is no email. The attack starts on a site you chose to visit, delivered through a script that site loads, with the real domain in your address bar. Email and spam filters look at a channel this attack never uses. A browser-layer scanner that inspects the page, the credential form, and where it posts is the layer positioned to catch it.

Install SafeBrowz free

Add the browser extension that runs every check in this article automatically, on every page, before it renders. Free forever.

Add to Chrome Add to Firefox Add to Edge