# Polyfill.io Returns: Suspicious Login Prompts Hit Toshiba, Muji, and Samsung
Major retailers and tech companies including Toshiba, Muji, Samsung, and several Japanese firms are warning customers about unexpected login prompts appearing on their websites—a lingering consequence of a 2024 supply-chain attack on the Polyfill JavaScript library. The prompts, served by the compromised polyfill.io domain, exploit a two-year-old security breach and reveal critical gaps in website cleanup practices across the industry.
## The Immediate Threat
Beginning in late May 2026, visitors to multiple corporate websites encountered unexpected authentication screens requesting usernames and passwords. The prompts appeared deceptively legitimate, mimicking each site's standard login interface. However, these screens were not generated by the companies themselves—they originated from an external service: polyfill.io, a domain notorious for hosting malicious code following a supply-chain compromise in 2024.
Affected organizations confirmed so far include:
Toshiba published an urgent notice advising website visitors to "select 'Cancel' without entering any information" if they encountered the suspicious screens. Muji issued similar guidance, asking customers to "consider your response" and cautioning that while no unauthorized access had been confirmed, the company was taking precautions. Both companies have since removed the offending code and suspended the polyfill.io service on their properties.
## Background and Context: A Supply Chain Failure with a Long Tail
The current incident traces back to February 2024, when the polyfill.io domain—which had expired—was registered by a new entity with malicious intent. The domain hosted a popular JavaScript library called Polyfill, designed to enable legacy browsers to run modern websites by providing compatibility layers for unsupported technologies. It was originally created and maintained by Andrew Betts, whose open-source project became widely adopted across the web.
### How the Domain Was Compromised
When Betts' original domain registration expired, he could not immediately reclaim it. A hostile actor purchased the domain and began distributing malicious JavaScript code through the CDN (content delivery network) infrastructure. Security researchers estimate the compromise affected more than 100,000 websites at its peak.
Upon discovering the attack, Betts immediately:
1. Publicly disclosed the compromise
2. Recommended that all website operators remove polyfill.io from their code
3. Relaunched the legitimate Polyfill service at new domains: first polyfill.com, later migrating to polyfill.top
### The Cleanup Failure
Despite these efforts, a significant number of websites never fully removed the malicious polyfill.io references from their code. Over the past two years, many organizations believed they had addressed the issue by simply deactivating the malicious domain. However, hardcoded references to polyfill.io persisted in outdated pages, archived code, or forgotten components across their web infrastructure.
## Technical Details: How HTTP 401 Became a Credential Harvester
The attack mechanism is deceptively simple yet effective, exploiting fundamental browser behavior and user expectations.
### The Attack Chain
| Step | Technical Detail |
|------|-----------------|
| 1. User visits affected page | Browser loads HTML containing old polyfill.io script reference |
| 2. Browser requests script | Standard GET request to polyfill.io |
| 3. Malicious response | Server responds with HTTP 401 Unauthorized status code |
| 4. Browser authentication dialog | Browser interprets 401 as request for credentials; displays native login prompt |
| 5. Credential entry | User, seeing what appears to be a legitimate login screen, enters credentials |
| 6. Harvesting | Credentials are transmitted to attacker-controlled server |
Why this works: Web browsers, when receiving an HTTP 401 response without a WWW-Authenticate header specifying a custom realm, display their native authentication dialog. Users accustomed to seeing login prompts on corporate websites assume these are legitimate, especially when they appear seamlessly integrated into their browsing session.
### Why It's Hard to Detect
## Implications for Organizations and Users
### Risk Assessment
Confirmed risks:
Unconfirmed but possible risks:
Current status: Security researchers report no confirmed evidence that credentials entered on these rogue prompts were harvested by attackers, but the potential exists. Organizations have not disclosed data breaches attributable to these prompts—yet.
### Broader Industry Implications
This incident exposes several systemic weaknesses:
1. Incomplete supply-chain remediation – Organizations assume "removing a vendor" means "removing all references" when cleanup is often incomplete
2. Stale code dependencies – Legacy pages and forgotten domains create persistent vulnerability windows
3. JavaScript trust assumptions – The internet's reliance on third-party JavaScript creates unavoidable attack surface
4. Monitoring gaps – Most organizations don't continuously audit external dependencies across their entire web footprint
## Recommendations for Organizations
### Immediate Actions
### Long-term Prevention
## HackWire Analysis
This incident exemplifies a critical vulnerability in the JavaScript supply chain: the persistence problem. Unlike malware with a defined lifespan or patches with clear deployment dates, compromised external services create indefinite exposure windows. Organizations patched the immediate threat in February 2024 by moving to legitimate polyfill domains, yet two years later, zombie references continue to haunt their websites.
The root cause isn't negligence—it's the sheer scope of modern web architectures. A large enterprise may have hundreds of web properties, microservices, legacy pages in archives, development environments still using outdated code, and third-party vendors who've never updated their integrations. Achieving complete cleanup across such complexity requires extraordinary coordination.
What's particularly striking is how the attack exploits *legitimate browser behavior*. There's nothing "wrong" with HTTP 401 or native authentication dialogs—they're security features. Yet when legitimate mechanisms combine with abandoned infrastructure, they become weapons.
For defenders, this reinforces three imperatives: first, maintain an authoritative inventory of all external code dependencies (this is non-negotiable); second, treat deprecated third-party services the same way you'd treat vulnerability disclosures—urgent and requiring verification; third, recognize that supply-chain compromises don't end when the vendor fixes the problem. The cleanup phase can extend years beyond the initial breach.
Organizations hit by this incident—Toshiba, Muji, Samsung, and others—made no security errors. They simply failed to reach 100% cleanup, a goal that's realistic but requires discipline and tooling many organizations still lack. — HackWire Editorial
## Related Coverage