Polyfill.io Login Prompts: A Supply Chain Security Incident
In late May 2026, users accessing websites from major entities like Toshiba and Muji encountered unexpected polyfill.io login prompts. These incidents, which continued into early June 2026 with reports affecting Samsung Smart TVs, are attributed to the reactivation of the `polyfill[.]io` domain. This event underscores persistent challenges in web supply chain security, specifically related to the MITRE ATT&CK technique T1195, Supply Chain Compromise, and its potential for T1566.002, Phishing: Spearphishing Link, through deceptive browser interactions.
Following the initial 2024 compromise of `polyfill[.]io`, security researchers and industry advisories consistently highlighted the inherent risks of relying on third-party CDNs. These discussions emphasized the critical need for robust security measures such as Content Security Policies (CSP) and Subresource Integrity (SRI), alongside a disciplined approach to managing external dependencies. The current incident demonstrates how theoretical risks, particularly concerning domain expiration and supply chain integrity, can manifest as practical security challenges.
The Incident: Unexpected Login Screens
Starting in late May 2026, users visiting websites such as Toshiba, Muji, Zojirushi, FiNC Technologies, Ishiyaku Publishers, and Hobonichi encountered unexpected polyfill.io login prompts. Even Samsung Smart TVs and their associated websites reportedly displayed similar screens on June 1, 2026. These were not legitimate site elements; they were suspicious, out-of-place pop-ups requesting credentials, indicative of a potential T1566.002 (Phishing: Spearphishing Link) attempt.
Toshiba and Muji quickly addressed the issue, suspending the problematic service and advising users to cancel any prompts without entering information. While Muji has not confirmed unauthorized access or data leakage, and there's no indication of direct website breaches, the immediate concern remains credential harvesting rather than a compromise of the companies' systems.
How a Dead CDN Came Back to Life
The Original Compromise (2024): `polyfill[.]io` is a JavaScript CDN designed to help modern websites function on older browsers. The domain, however, was not owned by the open-source project's creator, Andrew Betts. In 2024, after the domain expired, a Chinese entity acquired it. They then injected malicious scripts into the JavaScript served by the CDN, impacting over 100,000 websites that were still using the service. This initial event represents a clear instance of T1195 (Supply Chain Compromise), specifically targeting software supply chain integrity.
The "Fix" and the Remnants: Following the 2024 incident, Andrew Betts recommended that website owners remove the service entirely. He relaunched the legitimate project under new domains like `polyfill.com` and `polyfill.top`. Many sites did deactivate `polyfill[.]io`, stopping the malicious redirections. However, some websites failed to clean up *all* their pages, leaving remnants of the old `polyfill[.]io` code embedded deep in their site architecture.
The Reactivation (Late May 2026): Fast forward to late May 2026. The `polyfill[.]io` domain became active again. This time, instead of injecting malicious JavaScript directly, it began responding with HTTP 401 authentication requests.
The Browser's Reaction: When a browser receives an HTTP 401, it interprets this as a request for a username and password. Consequently, for any page that still contained a lingering call to `polyfill[.]io`, the browser displayed a native polyfill.io login prompt. This appears legitimate because it's the browser itself asking, not a fake web page element. Security research and penetration testing consistently demonstrate how even an innocuous HTTP response can trigger unexpected UI interactions, making social engineering surprisingly effective, aligning with the deceptive nature of T1566.002.
This isn't a direct hack of Toshiba or Muji's servers, but rather a supply chain issue where a previously compromised and supposedly inactive service reactivates, exploiting forgotten code on otherwise secure websites.
The Impact: Credential Harvesting and User Confusion
The immediate impact is potential credential harvesting, a direct consequence of the T1566.002 (Phishing: Spearphishing Link) technique. If a user, seeing a seemingly legitimate browser prompt triggered by the polyfill.io login prompts, entered their username and password, those credentials could have been sent to the reactivated `polyfill[.]io` domain. Although direct theft hasn't been confirmed, the exposure risk for credentials is significant.
This incident, driven by the deceptive polyfill.io login prompts, also deeply confuses users. People are conditioned to trust browser-level prompts more than in-page forms. This is a subtle yet effective method to trick users, especially when it appears on a trusted brand's website. The fact that major Japanese companies and even Samsung Smart TVs were affected demonstrates the broad reach of this kind of legacy code problem.
The Response: Clean Up Your Dependencies
Toshiba and Muji correctly responded by immediately suspending the service and advising users to cancel prompts and change passwords if any information was entered.
Beyond the immediate response, this incident highlights crucial aspects of organizational hygiene and supply chain security:
Websites require a complete sweep for *all* instances of `polyfill[.]io` code. Simply stopping the use of a service is insufficient; every remnant must be removed. This means looking beyond obvious header and footer includes, digging into older, less frequently updated pages or templates, and auditing third-party plugins that might embed such calls.
Finally, user education remains vital. We must continue to advise users to be wary of *any* unexpected authentication prompt, even if it appears to originate from their browser. When in doubt, cancel the prompt and navigate directly to the site.
The polyfill.io login prompts incident powerfully demonstrates how even old, forgotten dependencies can become critical attack vectors. The initial compromise in 2024 should have been the end of it, but the failure to fully excise the code from websites allowed the threat to lie dormant, waiting for the domain to be reactivated. Organizations must understand that using a third-party service means owning its security implications, even years later. Clean up your code, enforce strong policies, and assume that anything you do not control can, and eventually will, become a problem.
