Polyfill.io Is Back — and It’s Trapping Users With Fake Login Prompts

• The polyfill.io attack has resurfaced in 2026, two years after the original domain was hijacked and laced with malicious JavaScript.
• Toshiba and Muji both warned users about fake sign-in screens generated by the polyfill.io attack remnants still embedded in their sites.
• The dormant domain went live again in late May 2026, responding with HTTP 401 prompts that browsers render as login dialogs.
• At least six major Japanese brands were affected, including Samsung Smart TV websites, signalling the issue is broader than initially reported.

• The polyfill.io attack has resurfaced in 2026, two years after the original domain was hijacked and laced with malicious JavaScript.
• Toshiba and Muji both warned users about fake sign-in screens generated by the polyfill.io attack remnants still embedded in their sites.
• The dormant domain went live again in late May 2026, responding with HTTP 401 prompts that browsers render as login dialogs.
• At least six major Japanese brands were affected, including Samsung Smart TV websites, signalling the issue is broader than initially reported.

A 2024 Security Nightmare Just Got a 2026 Sequel

The polyfill.io attack was supposed to be a closed chapter. Back in 2024, the now-infamous domain was acquired by a Chinese entity, which promptly stuffed malicious JavaScript into a widely-used CDN service, hitting more than 100,000 websites in the process. Site owners scrambled. The open-source project’s original creator, Andrew Betts, publicly distanced himself from the compromised domain and set up a clean alternative. The web security community breathed a collective sigh of relief. Except it wasn’t over.

Starting in late May 2026, the polyfill.io domain woke back up — and it came back with a new trick. Instead of serving outright malicious redirect scripts, it began issuing HTTP 401 authentication responses. That’s a web standard signal that says, essentially, “you need to log in to access this.” Browsers dutifully interpret that signal and display a native username-and-password dialog box. To an ordinary visitor on Toshiba’s website or Muji’s online store, it looks completely legitimate. It isn’t. The polyfill.io attack, in other words, had simply entered a new phase.

Toshiba, Muji, and the Polyfill.io Attack’s Wider Blast Radius

Both Toshiba and Muji went public this week with warnings to their users. Toshiba’s advisory was direct:

“We have confirmed that some parts of our website may display a sign-in screen like the one shown below. We are currently working to eliminate this screen, but if you do see it, please select ‘Cancel’ without entering any information.”

Muji followed with a similar announcement, noting that while no confirmed unauthorised access or data leakage had been detected, the company urged customers to “consider your response” if they encountered the prompt. Both companies have since removed the offending script and suspended the polyfill.io service on their sites.

What makes this worse is the scale. Japanese media reports identified at least four other affected brands: Zojirushi, FiNC Technologies, Ishiyaku Publishers, and online publisher Hobonichi. Security researcher Pasquale Pillitteri also flagged that Samsung Smart TV websites were serving the rogue login prompt as recently as June 1. This isn’t a niche problem affecting a few forgotten corner-of-the-web sites — it’s touching major consumer brands with millions of users. The polyfill.io attack, it turns out, had a far longer reach than the 2024 headlines suggested.

Why Websites Are Still Running Code From a Domain They Abandoned Two Years Ago

This is the part that deserves real scrutiny. The polyfill.io attack was widely covered in 2024. Betts himself urged every website owner using the service to pull it immediately. Cloudflare and other CDN providers blocked the domain. The story was everywhere. So why are household brands still serving a script tag pointing at polyfill.io in mid-2026?

The honest answer is that web codebases are messy. A large site like Toshiba’s or Muji’s has thousands of pages, often built across multiple years, by different teams, using different frameworks. Legacy templates get forgotten. Third-party integrations get embedded and never revisited. A script tag that was added to a site footer five years ago doesn’t have a flashing warning light that says “this CDN was compromised” — it just sits there, quietly, until something goes wrong. That’s precisely what makes the polyfill.io attack so persistently dangerous.

This is the fundamental challenge of third-party JavaScript dependency management, and the polyfill.io situation is one of its most damning case studies. When you rely on an external domain for any piece of functionality, you’re making a bet that domain stays trustworthy indefinitely. When it was actively delivering malicious redirects in 2024, that bet failed catastrophically. And when the domain went dormant, many teams apparently treated that as job done — without actually auditing every page on their sites for remaining references.

The Mechanics: How a Dead Domain Became a Credential Trap

Understanding why these login prompts appeared requires a quick primer on how polyfill scripts work. Polyfill is a JavaScript compatibility layer — it lets modern websites function on older browsers that don’t natively support certain web features. The polyfill.io CDN served these scripts, meaning site owners added a simple script tag referencing polyfill.io, and the CDN handled delivery. It was convenient. It was also a single point of failure.

Crucially, the polyfill.io domain was never owned by Betts, the creator of the original open-source project. It was operated independently. When the domain changed hands in 2024, Betts launched replacements at polyfill.com and later polyfill.top, but he had no control over what the new owners did with polyfill.io itself.

Now, in 2026, whoever controls polyfill.io has configured it to return HTTP 401 responses — a technique that costs almost nothing to deploy but produces a convincing credential prompt in every major browser. There’s no need to inject complex JavaScript. The browser itself does the work, rendering what looks like a standard authentication dialog. Users who enter their credentials could potentially be handing them directly to whoever is running the domain. The elegance of the polyfill.io attack at this stage is precisely what makes it so insidious: the browser becomes an unwitting accomplice.

What We Still Don’t Know — and Why That’s Concerning

Here’s what’s still unclear: whether any credentials entered into these prompts were actually captured. At the time of writing, there’s no confirmed evidence of credential theft. But absence of evidence isn’t evidence of absence, and that distinction matters a great deal here.

The nature of the HTTP 401 technique means credentials could theoretically be logged server-side on polyfill.io’s infrastructure without leaving any trace on the affected websites themselves. Toshiba and Muji can scan their own servers for signs of a breach — and both say they’ve found nothing. But they have no visibility into what polyfill.io is doing with responses their visitors’ browsers send back to that domain. This opacity is one of the most troubling aspects of the polyfill.io attack in its current form.

Anyone who entered credentials into one of these unexpected prompts on any affected site should change their passwords immediately, and enable two-factor authentication if they haven’t already. The precautionary advice from both Toshiba and Muji is the right call, even without confirmed theft.

The Broader Supply Chain Warning Every Dev Team Should Hear

The polyfill.io attack saga is, in many ways, a textbook example of software supply chain risk — the same class of vulnerability that made SolarWinds a household name and that continues to plague enterprises relying on open-source packages via npm, PyPI, and similar repositories. The attack surface isn’t always your own code. Often, it’s the code you trusted someone else to maintain.

What’s different about this particular incident is the longevity. Most supply chain attacks have a defined blast period — the window between compromise and discovery. The polyfill.io attack has now stretched across two years and two distinct phases of activity. The 2024 compromise forced action. The 2026 revival caught teams who thought they’d already cleaned up.

The practical takeaway for any development or security team is straightforward: run a full audit of every external script reference across your entire site, not just the pages your team actively maintains. Tools like Subresource Integrity (SRI) checks and regular content security policy reviews should be standard operating procedure, not one-time fixes triggered by incidents. If your site has ever referenced polyfill.io, assume nothing — check every page, every template, every cached asset. The polyfill.io attack is a hard reminder that dormant threats are not defeated threats.

The web has a long memory for forgotten dependencies. Unfortunately, so do the people looking to exploit them.

Source: Bleeping Computer

Frequently Asked Questions