A Dead Domain That Wasn’t Quite Dead
The polyfill.io domain was supposed to be a solved problem. Back in 2024, it made international headlines when a Chinese entity purchased the expired domain and injected malicious scripts into a JavaScript CDN that more than 100,000 websites had been quietly relying on. Website owners scrambled, the original Polyfill project creator Andrew Betts publicly urged everyone to strip the service from their codebases, and eventually the redirections stopped. Two years later, a measurable number of sites never finished cleaning house — and that left them exposed when polyfill.io activated again in late May 2026.
Starting around that period, the domain began returning HTTP 401 authentication responses instead of staying silent. When a browser encounters a 401 response from an embedded script source, it does exactly what it’s designed to do: it surfaces a login prompt asking the user for a username and password. For visitors on Toshiba’s website and Muji’s website, that meant an unexpected sign-in screen appearing mid-session with no obvious explanation of where it came from or why.
What Toshiba and Muji Told Their Users
Toshiba issued a public notice acknowledging that parts of its website were displaying an unusual sign-in screen, advising visitors not to enter any information and to click “Cancel” if the prompt appeared. The company stated it was working to eliminate the screen. Muji published a similar warning earlier in the same week, confirming the authentication screens were generated by the external service at polyfill.io. Muji added that, at the time of writing, it had not confirmed any unauthorized access or data leakage, but it encouraged customers to take precautions given the circumstances. Both companies have since resolved the issue and suspended the polyfill.io service from their sites.
Japanese media reporting identified several additional companies affected by the same problem. Zojirushi, FiNC Technologies, Ishiyaku Publishers, and the online publishing brand Hobonichi all encountered the same behavior. Security researcher Pasquale Pillitteri noted that Samsung Smart TV websites also displayed the rogue login prompt on June 1.
The scale here matters. These aren’t small or obscure brands. Toshiba is a multinational technology company. Muji operates hundreds of retail locations internationally and runs a well-trafficked e-commerce platform. The fact that their web teams had not fully purged a deprecated third-party script in two years reflects how difficult supply chain hygiene is to maintain at scale, particularly for legacy pages buried in large site architectures.
The Polyfill History Worth Knowing
To understand why this is still happening in 2026, it helps to retrace what Polyfill actually is and how the domain arrangement worked. Polyfill is a JavaScript compatibility layer — its purpose is to let modern websites function on older browsers by filling in support for features those browsers lack. The code itself is open source and legitimate. The problem was always the delivery mechanism.
The CDN at polyfill.io was operated independently of the project’s creator, Andrew Betts. Betts built the concept; he never owned or controlled that domain. When the domain lapsed and became available, it could be — and was — registered by anyone. In 2024, a Chinese entity acquired it and began serving modified scripts through the CDN, affecting every site that had embedded polyfill.io references without checking what those references were actually returning. When the malicious activity became public, Betts relaunched a clean version of the service, first at polyfill.com and then at polyfill.top.
The 2024 deactivation stopped the active redirections, but it did not force affected websites to audit their codebases. A page that loads a single JavaScript file from polyfill.io and has never been touched since 2023 will still call that domain every time a user visits. If the domain is inactive, nothing happens. If the domain becomes active again and starts returning unexpected responses, those sites are immediately in scope — no new attack required, no fresh compromise needed.
HTTP 401 and the Browser as a Tool Against Users
The specific mechanism here is worth examining closely.
An HTTP 401 status code signals that a resource is protected and requires authentication. Browsers handle this by displaying a native credential dialog — a simple prompt that looks like it belongs to the operating system or the site itself. There is no styling, no branding, and minimal context. Most users see a box asking for a username and password and have no way to determine whether the request is coming from the site they’re visiting or from a third-party script embedded somewhere in that page’s source. The polyfill.io domain, once it began returning 401 responses in late May 2026, was exploiting this browser behavior. Every site that still called polyfill.io became an unwitting participant in serving that prompt to its own visitors.
What makes this particularly concerning is the plausibility. A user visiting Toshiba’s website or Muji’s online store has a reasonable expectation that they may be asked to log in. An authentication prompt appearing on those pages doesn’t look immediately wrong, especially if the user was already planning to access their account. The absence of any custom branding on native browser dialogs removes one of the visual cues people rely on to detect phishing. Toshiba’s own advisory included a screenshot of the suspicious screen specifically so that users could recognize it — an acknowledgment that the prompt is convincing enough to fool people who aren’t on alert.
No Confirmed Theft — But That’s Not Clearance
At this point, there is no confirmed evidence that credentials entered into the rogue prompts were captured or transmitted to a malicious party. The 401 response mechanism generates a browser-native prompt, and whether any backend on polyfill.io was collecting submitted credentials has not been publicly established.
That uncertainty is not reassurance. Both Toshiba and Muji told users who had already entered credentials to change their passwords. That advice is correct regardless of what eventually surfaces about the backend behavior. A credential entered into an authentication prompt controlled by an unknown third party should be treated as compromised until there is specific reason to believe otherwise.
Pillitteri’s reporting that Samsung Smart TV websites also showed the prompt on June 1 suggests the issue was not contained to a small number of sites. Samsung’s web footprint is substantial, and Smart TV interfaces often connect to user accounts that hold payment information and viewing history.
What Site Owners Should Do Now
Any organization that used polyfill.io at any point before 2025 should audit every page — not just the homepage or primary landing pages — for references to that domain. Content management systems and older microsites are common places where legacy script tags survive through redesigns and platform migrations. A search across the full codebase for the string “polyfill.io” takes minutes and eliminates the exposure entirely.
For organizations that genuinely need a Polyfill service, Betts’s current project at polyfill.top is the maintained successor. The underlying code does the same job; the delivery infrastructure is under different and accountable ownership. The Fastly and Cloudflare CDNs also offered clean mirrors of the original Polyfill code during the 2024 incident, and those remain available.
The question that the Toshiba and Muji incident leaves open is harder to answer than a simple script audit: how many other sites still carry polyfill.io references, and what happens if the domain’s behavior escalates beyond a 401 prompt? Right now, an HTTP 401 is disruptive and potentially credential-harvesting. A domain with that same reach could, in the wrong configuration, return something considerably more dangerous. The 2024 malicious scripts that reached over 100,000 sites demonstrated that capability already.
Muji’s statement noted it had not confirmed unauthorized access. That qualifier — “at this time” — carries more weight the longer polyfill.io remains active at an unknown operator’s direction.
