Toshiba and Muji Impacted by Polyfill Supply Chain Attack

Malicious Script Injection Impacts Major Retailers

Japanese tech giant Toshiba and the global retailer Muji have issued urgent warnings regarding suspicious activities on their web properties. According to BleepingComputer, visitors to these sites reported seeing unexpected sign-in prompts that were not part of the standard site architecture. These overlays are designed to collect user credentials through a sophisticated Phishing mechanism embedded directly into the site’s legitimate code base.

Investigations into these incidents reveal that the malicious behavior is a byproduct of the ongoing Supply Chain Attack targeting the Polyfill.io service. For years, web developers used Polyfill.io to ensure compatibility across different web browsers by delivering missing JavaScript functionality. However, the domain was recently sold to a Chinese entity, Funnull, which began injecting malicious code into the scripts served to millions of websites.

Technical Analysis of the Polyfill.io Compromise

The attack on Toshiba and Muji demonstrates the effectiveness of targeting shared infrastructure. When a user’s browser requests a script from the compromised domain, the server performs a check to determine the visitor’s environment. If certain conditions are met—such as the user not being a known bot or security crawler—the service returns a modified version of the polyfill script. This script facilitates XSS techniques to display unauthorized login forms.

Security researchers have noted that identifying malicious polyfill script behavior is complicated by the script’s ability to evade detection. The code often contains logic to hide itself when developer tools are open or when it detects it is running in a sandbox environment used by a SOC. Once the script determines it is on a genuine user’s machine, it can redirect the user to a malicious URL or overlay a credential-harvesting form that mimics the host site’s branding.

While no specific CVE has been assigned to this domain takeover incident itself, the risk to data integrity is high. The incident highlights a significant blind spot in many organizations’ Zero Trust architectures: the implicit trust placed in third-party scripts loaded dynamically from external Content Delivery Networks (CDNs).

How to Detect Polyfill.io Supply Chain Attack Activity

Defenders should look for unauthorized network requests originating from their web applications to domains associated with Funnull. Reviewing SIEM logs for outbound connections to polyfill.io, bootcss.com, or staticfile.org is a critical first step. Furthermore, organizations should utilize Content Security Policy (CSP) headers to restrict which domains are permitted to execute scripts on their pages. If a CSP is not configured, any compromised third-party domain can execute code with the same privileges as the site’s own developers.

Remediation and Defensive Recommendations

The immediate priority for any web administrator is the removal of the compromised domain from their source code. The original creator of the Polyfill project has publicly advised against using the service and recommended shifting to trusted alternatives. Following these Polyfill.io mitigation steps for web developers will significantly reduce the risk of credential theft:

• Audit Web Assets: Search all code repositories and third-party integrations for any reference to polyfill.io or its known mirrors.
• Transition to Trusted CDNs: Replace Polyfill.io links with those provided by reputable services like Fastly or Cloudflare, which have set up mirrors to provide the same functionality without the malicious injections.
• Implement Subresource Integrity (SRI): Use SRI hashes for all external scripts. This ensures that if the content of the script changes on the provider’s server without the developer’s knowledge, the browser will refuse to execute it.
• Update Content Security Policy: Strictly define script-src directives to prevent the execution of scripts from unauthorized or unvetted domains.

The incident serves as a stark reminder of the risks inherent in the modern web development ecosystem, where a single point of failure in a shared library can lead to widespread compromise across unrelated global brands.