Polyfill supply-chain injection on trusted sites
Polyfill supply-chain injection sits in a bad place between old code and user trust. A site can look normal, load normally, and still end up showing an unexpected sign-in box because a third-party JavaScript dependency changed behaviour after deployment.
The risk is not limited to one brand or one page. Any page that still points at the old service, or a cached variant of it, can surface browser-native credential prompts that appear to belong to the site.
How a legacy compatibility script became a live login prompt
Polyfill libraries exist to patch older browsers with modern JavaScript features. That makes them convenient, and also easy to forget about once the main site appears stable.
In this case, the useful bit was the problem. Pages that still referenced the external Polyfill service started showing login prompts when the domain began returning HTTP 401 authentication responses. Browsers treated that as a normal username and password challenge, so the prompt appeared as part of the browser, not as some clumsy pop-up bolted onto the page.
That distinction matters. Users tend to trust native browser dialogs more than page content. If the prompt sits in the browser UI and shows up on a familiar site, a fair number of people will type credentials before thinking twice.
Where the prompt came from in the request path
The failure started with residual references to the old CDN. The site template did not need to be broken for the prompt to appear. A single remaining script reference, or a cached version of that reference, was enough to pull in the compromised path.
Residual polyfill references after the original incident
Leftover references are boring until they are not. The original service change had already pushed people towards removing the dependency, but some pages were still loading it. That left a live edge where the external domain could influence what the browser showed.
The annoying part is how ordinary the weakness looks in logs. There is no dramatic page defacement here. The request still goes to a trusted page, then out to a third-party script host, then the browser reacts to the host’s response. Nothing about that chain needs the main application to be altered.
HTTP 401 responses that browsers turned into native sign-in boxes
A 401 response is standard HTTP authentication behaviour. Browsers know what to do with it, and that includes showing a username and password prompt. If the response comes from a domain that used to serve compatibility code, the result looks like a site login dialog even when it is not.
That is the neat trick of this failure mode. The site does not have to ask for credentials. The browser does it on the site’s behalf, using a trust relationship the site never meant to hand over.
What actually exposes users and what does not
The immediate exposure is credential harvesting risk. If the prompt looks site-owned, users may enter usernames and passwords into a box that exists only because a third-party script path changed behaviour.
There was no confirmed unauthorised access or data leakage in the reported cases. That does not make the prompt harmless. It only means the obvious damage had not been shown at the time the issue was being handled.
Credential harvesting risk when the prompt looks site-owned
This is the part that matters operationally. An injected login overlay does not need to be visually perfect to be dangerous. It only needs to be believable enough for a rushed user on a phone, a TV, or a browser tab they already trust.
A page that suddenly asks for sign-in details outside the expected flow is a bad sign even when the rest of the site looks fine. Users should not type credentials into an unexpected browser prompt just because the domain name looks familiar. The safer response is to cancel it and treat the page as suspect.
Why the problem sits in third-party JavaScript rather than the page template
The page template is only the delivery mechanism. The real dependency is the external script host. Once third-party JavaScript is involved, the site’s visible integrity depends on a domain and response pattern outside the site owner’s direct control.
That is why this belongs in supply-chain thinking, not just front-end tidy-up work. Removing a script tag is easy. Tracking every place that still loads the old CDN, every cached asset, and every forgotten variant takes longer, which is exactly why leftovers survive.
Removing the dependency without leaving a hole behind
The fix is dull and manual. Remove the old dependency everywhere, not just from the obvious templates. Then check the pages that matter most, because the last surviving reference is usually hiding where nobody expects to look.
Trace every page that still loads the old CDN or any cached variant
Start with the known URLs, then search for any reference to the old Polyfill domain across the site, including templates, bundled assets, and archived pages that still render client-side JavaScript. If any page still requests the old host, treat that as an active dependency, not a cosmetic leftover.
A one-page audit is not enough. The fault often sits in a partial, a legacy build, a copied footer, or an ancient page that still survives because no one has looked at it since the last redesign. That is how these things stay alive.
Verify the fix with website integrity monitoring and browser checks
Website integrity monitoring gives you a way to catch a familiar page loading unfamiliar code. It should flag script source changes, unexpected redirects, and any new browser prompt behaviour before users see it first.
Browser checks matter too. Load the affected pages in a clean browser session and watch for authentication prompts, script errors, and anything that looks like a native sign-in box where none should exist. If a page still produces a credential prompt after the dependency is removed, the site still has a path reaching that host or a cached asset still in play.
That is the part people miss when they assume a script removal is done. The page may look fixed. The browser still remembers how to be awkward.
