For weeks, customers visiting Toshiba and Muji websites were greeted by a clean little sign-in prompt asking for their credentials. Neither company built that prompt. It was injected by a third-party script both retailers had been loading on their pages for months after the original library was bought by a foreign owner and quietly weaponized. The cybersecurity question this raises has nothing to do with zero-days, patch velocity, or detection backlog. It’s about what your site loads when nobody on your team is looking.

Polyfill.io is the script in question. It was a free CDN-hosted shim that filled in missing JavaScript features for older browsers. It was useful, popular, and embedded on hundreds of thousands of commercial sites. In 2024 the domain was sold. Within days, the new owners turned it into a delivery channel for malicious redirects. The original maintainer publicly warned everyone to remove it. Cloudflare and others stood up mirrors. And here we are in mid-2026, with two mega-brands still serving a hijacked script straight into customer browsers.

The Script Tag You Inherited Is Now A Phishing Page

The mechanics are dull, and that’s exactly the problem. A developer two re-orgs ago dropped a <script src="https://cdn.polyfill.io/..."> tag into a template. That template propagated into checkout pages, product pages, and account flows. Nobody owns the tag. Nobody removes the tag. The domain changes hands, and the script silently starts asking your customers for their passwords.

Your firewall does nothing here. Your WAF inspects requests hitting your origin. The hostile code lives on someone else’s CDN, runs in the customer’s browser, and exfiltrates to attacker infrastructure. None of that traffic crosses your perimeter. Threat detection scoped to your servers is blind to it. The credentials get harvested, the customer gets phished, your support inbox fills up, and the first time your security team hears about it is when a journalist emails for comment.

If you can’t list every external host your production pages load JavaScript from, you don’t have a client-side supply chain problem. You have a client-side supply chain you’ve been ignoring.

This is the same failure pattern as the npm worms, the abandoned OAuth grants, and the orphaned GitHub Actions everyone has been talking about. It’s not specific to Polyfill. Pick any retailer site and run the network tab. Count the third-party domains. Now ask who in the company is responsible for each one. The answer is almost always nobody, or somebody who left two years ago.

Trust Doesn’t Travel With File Extensions Either

SANS Internet Storm Center flagged the return of a related trick this week: MSI installer payloads wrapped inside what looks like an ordinary JPEG image. A user gets a WeTransfer link from a sender they vaguely recognize. They download what appears to be a background image. Windows executes it as an MSI because the actual file is an installer with a JPEG header glued on. Antivirus that sniffs based on extension or file-type heuristics passes it through. Email gateways pass it through. The endpoint runs the install.

This is the same shape of problem as the Polyfill hijack. Trust is treated as a property of the source, the domain, or the extension, when in reality it’s a property of the bytes you’re about to execute right now. A script tag from a domain you whitelisted three years ago. An image attachment that’s actually an installer. A polyfill CDN that changed owners overnight. The trust decision was made in the past. The bytes are evaluated in the present. The gap between those two events is where every modern cyber security incident lives.

Defense in depth used to mean stacking controls at the network edge. It now has to mean stacking controls at the execution edge: in the browser, in the endpoint installer service, in the npm post-install hook, in the GitHub Action runner. Anywhere bytes get evaluated, you need a check that doesn’t rely on “we trusted this domain once.”

What To Actually Do This Week

Skip the strategic five-year roadmap. Here’s the short list that would have stopped both stories.

• Inventory every external script your production pages load. Open the network tab on your highest-traffic flows (login, checkout, account, password reset). Write down every third-party host. If the list is longer than ten entries on your login page, you have a problem worth a meeting.
• Pin every external script with Subresource Integrity (SRI). An integrity hash on the tag means the browser refuses to execute the file if the bytes change. Polyfill wouldn’t have run on a single SRI-pinned site.
• Deploy a Content Security Policy with reporting. Even in report-only mode, CSP will tell you when a page is loading scripts or making requests you didn’t authorize. It’s the single highest-yield piece of security hardening for a marketing-led web property.
• Assign an owner to every third-party tag. Marketing owns the analytics pixel. Engineering owns the framework polyfills. The CISO’s office owns the consent banner. Tags without owners get removed at the next deploy.
• Treat tag manager changes like production deploys. If a marketer can push a new external script into your checkout flow without code review, you’ve outsourced your security model to whoever sells your marketing team’s favorite tool this quarter.
• Strip MSI, LNK, and other installer payloads at the email and link-share gateway. Yes, even from WeTransfer. Especially from WeTransfer.
• Build a customer-credential incident response playbook. When (not if) credentials your site touched get exposed, you need to know how fast you can force resets, alert on brute-force replay against your auth, and notify customers. Rehearse it before the press release writes itself.

The Toshiba and Muji situation is going to keep happening. Some 2027 incident will involve a script that was hijacked in 2024 and still loads on a Fortune 500 checkout page. The thing that will change is which companies got serious about owning what their pages execute, and which ones found out from a customer tweet that they’d been phishing their own users for half a year.

Sources

• Suspicious Polyfill login prompts pop up on Toshiba, Muji websites
• The Evil MSI Background is Back!