Funnull Sanctioned: What the Polyfill[.]io Attack Exposed About Infrastructure Laundering

Quick answer: OFAC sanctioned Funnull Technology Inc. on 2025-05-29, along with administrator Liu Lizhi. That action reframes the Polyfill[.]io incident. It was not only a redirect campaign against websites that still loaded an old JavaScript utility. It was a browser supply-chain failure connected to a larger infrastructure laundering operation.

The lesson for security teams is direct: third-party scripts cannot be treated as trusted forever because they were trusted once. Ownership changes, CDN routing changes, and second-stage payloads can turn a normal browser dependency into an attack path.

TL;DR

• OFAC sanctioned Funnull Technology Inc. and administrator Liu Lizhi on 2025-05-29
• Treasury linked Funnull to more than $200 million in U.S. victim-reported losses
• The FBI identified 548 Funnull CNAMEs linked to more than 332,000 unique domains
• Treasury said Funnull bought and altered a web developer code repository in 2024 to redirect visitors
• The Polyfill[.]io case shows why browser-side defenses need runtime script behavior checks, not only vendor trust

What changed: Funnull is now a sanctioned infrastructure provider

The U.S. Department of the Treasury sanctioned Funnull as a Philippines-based company that provided computer infrastructure for hundreds of thousands of websites involved in virtual currency investment scams. Treasury described these scams as pig butchering and said Funnull directly facilitated schemes tied to more than $200 million in U.S. victim-reported losses.

The same action sanctioned Liu Lizhi, described by Treasury as an administrator of Funnull. Treasury said Liu was involved in operational documents and tasking that included assigning domains to cybercriminals for investment fraud, phishing scams, and online gambling sites.

The scale matters. The FBI advisory published the same day said investigators had identified 548 unique Funnull CNAMEs linked to more than 332,000 unique domains since January 2025. That is not a single bad domain. It is an infrastructure layer.

How Polyfill[.]io fits into the larger Funnull pattern

In 2024, Polyfill[.]io was already a clear browser supply-chain warning. A widely embedded JavaScript service changed hands, then served malicious redirects to a percentage of users based on runtime conditions. cside covered the incident in The Polyfill[.]io attack explained and later explained why it was more than just a redirect attack.

Treasury's Funnull action makes the connection sharper. Treasury said that in 2024 Funnull purchased a repository of code used by web developers and maliciously altered the code to redirect visitors of legitimate websites to scam websites and online gambling sites.

As of 2026-05-18, PublicWWW still listed 61,593 web pages containing "polyfill.io", even though Namecheap had taken action against the malicious domain after the 2024 supply-chain attack. That residue is the operational problem: browser dependencies can remain embedded long after a domain has been suspended, blocked, or publicly identified as unsafe.

That is the operating pattern security teams need to recognize. A script can be harmless when approved, risky when ownership changes, and malicious when the code path changes. The website owner may not change a line of code. The user's browser still executes the new payload.

What infrastructure laundering means for security teams

Infrastructure laundering is the use of credible infrastructure to hide or legitimize malicious activity. Instead of hosting every scam site on obvious low-reputation servers, an operator can route through cloud providers, CDNs, DNS chains, and front brands that look normal from a distance.

For browser security, the most important part is not the label. It is the control gap. A site may trust a CDN URL because it worked yesterday. A vendor review may approve a domain because the vendor was legitimate at the time. A tag manager may show the same top-level script while that script loads a different second-stage resource at runtime.

That is why source-based trust fails. The browser does not execute a vendor questionnaire. It executes JavaScript.

Why sanctions do not end the browser-side risk

Sanctions can disrupt a named company, freeze assets under U.S. jurisdiction, and make business with the sanctioned party legally risky for U.S. persons. They do not automatically remove every related domain, script, CDN route, or cloned front company from the internet.

The post-sanction risk is already visible in threat research. Silent Push reported that infrastructure associated with the broader Triad Nexus and Funnull ecosystem continued to evolve after the 2025 sanctions, including geographic blocking, CNAME rotation, and clean-looking front companies.

Treasury's later U.S. and U.K. action against Southeast Asian cybercriminal networks also shows the wider enforcement context. OFAC sanctioned 146 targets within the Prince Group Transnational Criminal Organization, while FinCEN finalized a rule severing Huione Group from the U.S. financial system. These are large, adaptive networks. Removing one brand does not remove the business model.

What to do this week

Start with the scripts that can touch login, checkout, account creation, payment, and personal data flows.

1. Search for polyfill[.]io, bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org, and unionadjs[.]com in source code, tag managers, CMS templates, and legacy snippets
2. Remove dead compatibility scripts that modern browsers no longer need
3. Map every third-party script to an owner, purpose, page scope, and data access level
4. Identify scripts that load additional scripts, build URLs dynamically, or execute different code by user agent, geography, referrer, or session state
5. Use SRI only where the script is static and the provider supports stable hashes
6. Tighten CSP on sensitive flows, then monitor violations before moving from report-only to enforcement
7. Add runtime monitoring so script changes, redirects, data access, and unexpected network calls are visible when users load the page

This is not only a Polyfill cleanup. It is a third-party script governance exercise.

How cside helps monitor third-party script risk

cside works at the browser layer, where third-party scripts actually execute. That matters because server logs, vendor reviews, and static inventories miss important runtime behavior.

With cside, teams can see which scripts load on real pages, what those scripts call, how they change, and whether they attempt suspicious behavior such as unexpected redirects or data access. That visibility helps security and compliance teams move from "we approved this vendor once" to "we know what this code is doing now."

The Funnull sanctions are a useful forcing function. They show that client-side supply-chain risk is not theoretical, and it is not limited to obviously malicious domains. The risk sits in the gap between trusted inclusion and runtime execution.

As of 2026-05-18, sanctions designations, infrastructure indicators, and active fronts can change. Treat the named domains and CNAMEs as investigation leads, not a complete blocklist.

Further reading

• Treasury Takes Action Against Major Cyber Scam Facilitator
• FBI advisory on Funnull infrastructure
• Silent Push research on post-sanction Funnull infrastructure
• The Polyfill[.]io attack explained
• The Polyfill[.]io attack: more than just a redirect attack
• Script integrity management for ecommerce brands