你的 AI 编程助手正在悄悄植入一条供应链后门。在 polyfill.io 被出售给一个后来受到制裁的运营方并沦为恶意软件 CDN 一年后，仍有近 2000 个活跃的 GitHub Pages 站点（超过 18000 个页面、合计 53 万以上的 Star）从该网络加载脚本。而 AI 让情况变得更糟：我们测试过的每一个大语言模型在生成前端代码时，仍然会推荐这些已被攻陷的 CDN 链接。
某天下午，我打开了自己的个人网站（我知道，这很随机）。一件意想不到的事情发生了：一个灰色弹窗出现，要求输入用户名和密码。这是 nginx 的认证对话框，按理说也算正常——但我的网站根本没有配置 nginx 认证。那么，这个弹窗是从哪里来的？
困惑了几分钟后，我找到了罪魁祸首。HTML 深处藏着一个我甚至不知道存在的 `<script src="https://polyfill.io/...">` 标签。修复方法很简单：删除这个标签，重新构建，然后推送。问题解决了。
一周后，我在浏览一位顶级 AI 研究员的个人网站。你猜怎么着——同样的灰色弹窗又出现了。同样的认证窗口，同样的 polyfill.io 指纹。
我们俩对此都毫不知情。我们正在从一个 CDN 运营商那里运行代码，而该运营商早在几个月前就因一起臭名昭著的恶意软件事件被美国外国资产控制办公室列入了制裁名单。幸运的是，这个脚本已经不再注入任何恶意内容。如果当时存在恶意代码，只要在本地打开一次网站，或者点击一次该网站，就可能导致我们或其他研究人员的计算机出现难以估量的安全问题。
这引发了一个我无法放下的问题：还有多少人受到了影响却毫不知情？为什么连安全研究员都会在毫无察觉的情况下落入这个陷阱？
一个合法服务如何沦为恶意软件分发网络
要理解这些问题，我们得先知道 polyfill.io 是什么。
近十年来，polyfill.io 一直是一项备受推崇的前端开发服务。只需一个 polyfill 脚本标签，就能让使用旧版浏览器的访客正常渲染你的网站。它出现在教程、样板仓库和 Stack Overflow 的回答中，次数高达数百万次。
2024 年初，该域名被出售给 Funnull Technology Inc.。数周内，该服务开始有条件地向其提供的脚本中注入恶意载荷——针对移动端用户，重定向至诈骗网站，并覆盖虚假身份验证提示以窃取凭证。由于注入仅在特定条件下触发（错误的浏览器、错误的时间段、首次访问），许多网站所有者从未察觉。
Polyfill.io 实际上只是更大规模网络中最显眼的一环。Sansec 和 Censys 的安全研究人员发现，Funnull 使用相同的 Cloudflare 账户凭证运营着多个流行的 CDN——相同的基础设施，相同的运营者：
| 域名 | 证据 |
|---|---|
| bootcss.com | 直接证据：恶意重定向载荷已被解码并公布（2023 年 6 月） |
| polyfill.io | 直接证据：恶意载荷已在真实环境中被捕获（2024 年） |
| bootcdn.net | 间接证据：相同的 Cloudflare 账户；被 Google 在广告商警告中提及 |
| staticfile.org / .net | 间接证据：相同的 Cloudflare 账户；相同的运营者 |
2025 年 5 月，OFAC 对 Funnull Technology Inc. 实施制裁，该公司随即更名为 Triad Nexus。这些 CDN 域名仍保持运行。研究人员此后发现了一批新的伪装站点——cdn1.ai、bolecnd.com、yunray.ai——据评估，这些是 Funnull 自 2025 年 6 月起启用的别名。
结论：这五个 CDN 均不可信任。
扫描 12,000 多个 GitHub Pages 站点后的发现
为什么选择 GitHub Pages？
GitHub Pages 已成为学术个人网站、课程页面、开源文档、项目演示和开发者作品集的默认托管地之一。它免费、易于搭建、与 GitHub 仓库紧密集成，并提供便捷的 github.io 域名，用户无需自行管理托管基础设施。正是这种便利性，使其在学术界和开源社区中得到如此广泛的应用。
但同样的便利性也造成了安全盲区。网站一旦部署，便可在几乎无需维护的情况下持续运行多年。一个最后更新于 2021 年的仓库，可能在 2026 年仍托管着活跃网站——而每一位访问者都会加载原始开发者嵌入的所有脚本标签。
我们的搜索内容
我们对 polyfill.io、bootcss.com、bootcdn.net、staticfile.org 和 staticfile.net 进行了扫描，覆盖了已识别的整个 Funnull CDN 家族。
我们搜索了从 GitHub Code Search 和 Sourcegraph 获取的 GitHub 页面。我们通过源代码确认了感染情况，并通过实时爬取网站上的所有页面验证了恶意 CDN 的存在。
我们的发现
| 指标 | Polyfill | 其他 Funnell CDN |
|---|---|---|
| 提及相关内容的网站 | 4,634 | 7,955 |
| 源代码被感染的网站 | 3,000 | 2,306 |
| 正在活跃加载恶意软件的网站 | 786 | 1,191 |
| 活跃网站中受感染的页面总数 | 4,228 | 14,156 |
触目惊心。仍有 1,960 个网站和 18,384 个页面处于感染状态。受害者并非只是不知名的个人作品集。平均而言，受影响的页面拥有 271 颗星标，其中有 66 个仓库的星标数超过 1,000。受影响页面的星标总数超过 53 万。
这些受影响的页面包括
- CyC2018/CS-Notes（184K ⭐）：一份技术面试参考资料
- hollischuang/toBeTopJavaer（25K ⭐）：一份 Java 职业发展指南
- microsoft/AirSim（18K ⭐）：微软开源的一款无人机和自动驾驶模拟器
- 加州大学伯克利分校、哈佛大学、鲁汶大学的课程页面
- 以及更多其他页面
该存档中的每一个页面都指向同一个恶意域名。
为什么情况会因 AI 而变得更糟
如今，每个人都在使用 AI 来处理前端工作。然而，每个大语言模型或多或少都学到了 `https://cdn.polyfill.io/v3/polyfill.min.js` 是加载浏览器 polyfill 的标准方式。这个推荐出现在数百万个 Stack Overflow 答案、博客文章和教程仓库中。它作为正确做法被融入了训练数据。
我们直接对此进行了测试。我们向四个模型发送了四个真实的代码生成提示词：Moonshot Kimi K2.7 Code、Meta Llama 3.3 70B、Qwen 2.5 7B 以及通过 Claude Code CLI 使用的 Opus4.8。这四个提示词涵盖了开发者实际工作流程中可能出现的情景：构建一个使用 MathJax 的学术页面、修复浏览器兼容性问题、生成一个作品集页面，以及编写一个使用 CDN 镜像的页面。
| 模型 | 不安全 | 出现的域名 |
|---|---|---|
| Llama 3.3 70B | 4 / 4 | polyfill.io, staticfile.org |
| Kimi K2.7 Code | 3 / 4 | polyfill.io, bootcdn.net, staticfile.org |
| Qwen 2.5 7B | 1 / 4 | polyfill.io |
| Opus 4.8 | 1 / 4 | bootcdn.net |
最引人注目的数字是：所有模型都至少返回了一个由 Funnull 运营的域名。
这并非单纯的模型幻觉问题。这些 URL 是真实存在的，代码也能正常运行，生成的页面可能正确渲染。从模型的角度来看，它给出了一个看似合理的答案。
问题在于，训练数据所对应的世界已经发生了变化。2019 年安全的依赖项，到了 2024 年可能变得危险；出现在数千个教程中的 CDN，其所有权日后可能变更；曾经代表兼容性的脚本标签，后来可能成为每个访问者浏览器中远程代码执行的突破口。
AI 编程助手尤其容易放大这类缺陷，因为其输出看起来毫无异常。没有语法错误，没有测试失败，也没有构建中断。审查生成 HTML 的开发者可能会看到一个熟悉的 CDN URL 就直接跳过。在很多情况下，开发者甚至根本不知道模型添加了这个依赖项。
软件供应链风险不仅关乎你安装的软件包，也关乎你代码所信任的 URL。静态网站看似静止不动，但其依赖项却是实时生效的。
应对措施与后续步骤
我们建议在你的源代码和生成的网站输出中搜索已识别的 CDN URL。一个快速示例如下：
grep -RInE 'polyfill\.io|polyfill\.com|polyfill\.cn|bootcss\.com|bootcdn\.net|staticfile\.org|staticfile\.net' .
如果发现匹配项，不要只修补你碰巧注意到的那个源文件。请检查你的模板、主题、生成的 HTML、归档页面、供应商资源以及文档构建产物。静态网站生成器可能会在你从一个页面删除该标签后，又在其他地方重新引入它。
Your AI coding assistant is quietly shipping a supply-chain backdoor. A year after polyfill.io was sold to a since-sanctioned operator and turned into a malware CDN, nearly 2,000 live GitHub Pages sites (18,000+ pages, 530K+ combined stars) still load scripts from that network. And AI makes it worse: every LLM we tested still recommends these compromised CDN URLs in generated front-end code.
One afternoon, I opened my personal website (very random, I know). Something unexpected happened: a grey popup appeared, asking for a username and password. This is an nginx authentication dialog, so it may be normal – except my site has no nginx auth. So where did it come from?
After a few minutes of confusion, I found the culprit. There is a single <script src="https://polyfill.io/..."> tag deeply buried in the HTML that I did not even know existed. But the fix is simple: remove the tag, rebuild, and push. Problem solved.
A week later, I was browsing a top AI researcher’s personal website. And guess what – the same grey popup appeared. The same authentication window, the same polyfill.io fingerprint.
Neither of us had any idea. We were running code from a CDN operator that the US Office of Foreign Assets Control had sanctioned months ago due to a notorious malware incident. Luckily, the script was not injecting any malicious content anymore. Had there been any malicious code, a single serving of the website locally or a single click onto the website may lead to unfathomable security problems on either our or other researchers’ computers.
This raised a question I could not let go: how many more people are affected without knowing? And why even a security researcher would fall into this trap without any awareness?
How a legit service became a malware delivery network
To understand these questions, we have to know what is polyfill.io.
For nearly a decade, polyfill.io was a well-regarded service for front-end development. One polyfill script tag will allow visitors with older browsers to render your website properly. It appeared in tutorials, boilerplate repositories, and Stack Overflow answers millions of times.
In early 2024, the domain was sold to Funnull Technology Inc.. Within weeks, the service began conditionally injecting malicious payloads into the script it served – targeting mobile users, redirecting to scam sites, and overlaying fake authentication prompts to harvest credentials. Because the injection only fires under specific conditions (wrong browser, wrong time of day, first visit), many site owners never noticed.
Polyfill.io turned out to be only the most visible part of a larger network. Security researchers at Sansec and Censys identified that Funnull operated several popular CDNs under the same Cloudflare account credentials – the same infrastructure, the same operator:
| Domain | Evidence |
|---|---|
bootcss.com | Direct: malicious redirect payload decoded and published (June 2023) |
polyfill.io | Direct: malicious payloads captured in the wild (2024) |
bootcdn.net | Indirect: same Cloudflare account; named by Google in advertiser warnings |
staticfile.org / .net | Indirect: same Cloudflare account; same operator |
In May 2025, OFAC sanctioned Funnull Technology Inc., and the company promptly rebranded as Triad Nexus. The CDN domains remained up. Researchers have since identified a new generation of fronts – cdn1.ai, bolecnd.com, yunray.ai – assessed as Funnull aliases standing up as of June 2025.
Takeaway: None of these five CDNs should be trusted.
What scanning 12,000+ GitHub Pages sites revealed
Why GitHub Pages?
GitHub Pages has become one of the default homes for academic personal sites, course pages, open-source documentation, project demos, and developer portfolios. It is free, easy to set up, tightly integrated with GitHub repositories, and provides a convenient github.io domain without requiring users to manage their own hosting infrastructure. This convenience is exactly why it is so widely adopted across academia and open-source communities.
But that same convenience also creates a security blind spot. Once a site is deployed, it can keep serving content for years with little or no maintenance. A repository last updated in 2021 may still be hosting a live website in 2026 – and every visitor still loads whatever script tags the original developer included.
What we searched for
We ran a scan, on polyfill.io, bootcss.com, bootcdn.net, staticfile.org, and staticfile.net, covering the full Funnull CDN family identified.
We searched through Github pages retrieved from Github Code Search and Sourcegraph. We confirmed the infection through the source and verified the existence of the malicious CDNs via live crawling of all the pages on the website.
What we found
| Metric | Polyfill | Other Funnell CDNs |
|---|---|---|
| Sites with any mentions | 4,634 | 7,955 |
| Sites with infected source code | 3,000 | 2,306 |
| Sites actively loading malware | 786 | 1,191 |
| Total infected pages across live sites | 4,228 | 14,156 |
Shocking. 1,960 sites and 18,384 pages are still infected. The victims are not just unknown personal portfolios. On average, the affected pages has 271 stars, with 66 repos over 1K stars. The total number of stars of the affected pages exceed 530K.
These affected pages include
- CyC2018/CS-Notes (184K ⭐): a technical interview reference
- hollischuang/toBeTopJavaer(25K ⭐): a Java career guide
- microsoft/AirSim (18K ⭐): a Microsoft open-source drone and autonomous vehicle simulator
- Course pages from UC Berkeley, Harvard, KU Leuven
- And many, many more
Every page in that archive serves the same malicious domain.
Why this will get worse, with AI
Nowadays everyone is using AI to do their front-end chores. However, every large language model learned more or less that https://cdn.polyfill.io/v3/polyfill.min.js is the standard way to load browser polyfills. This recommendation appears in millions of Stack Overflow answers, blog posts, and tutorial repositories. It is baked into the training data as the correct practice.
We tested this directly. We sent four realistic code-generation prompts to four models: Moonshot Kimi K2.7 Code, Meta Llama 3.3 70B, Qwen 2.5 7B, and Opus4.8 via the Claude Code CLI. The four prompts cover scenarios likely to appear in a developer’s real workflow: building an academic page with MathJax, fixing browser compatibility, generating a portfolio, and writing a page using CDN mirrors.
| Model | Insecure | Domains seen |
|---|---|---|
| Llama 3.3 70B | 4 / 4 | polyfill.io, staticfile.org |
| Kimi K2.7 Code | 3 / 4 | polyfill.io, bootcdn.net, staticfile.org |
| Qwen 2.5 7B | 1 / 4 | polyfill.io |
| Opus 4.8 | 1 / 4 | bootcdn.net |
The headline number: all of the models returned at least one Funnull-operated domain.
This is not simply a hallucination problem. The URLs are real. The code works. The generated page may render correctly. From the model’s perspective, it has produced a plausible answer.
The problem is that the world changed underneath the training data. A dependency that was safe in 2019 can become dangerous in 2024. A CDN that appeared in thousands of tutorials can later change ownership. A script tag that once represented compatibility can become a remote code-execution foothold in every visitor’s browser.
AI coding assistants are especially likely to amplify this class of bug because the output looks ordinary. There is no syntax error. No failing test. No broken build. A developer reviewing the generated HTML may see a familiar CDN URL and move on. In many cases, the developer may not know the model added the dependency at all.
Software supply-chain risk is not only about packages you install. It is also about URLs your code trusts. Static websites feel inert, but their dependencies are live.
What to do and what’s next
We recommend searching your source and the generated site output for the identified CDN URLs. A quick example:
grep -RInE 'polyfill\.io|polyfill\.com|polyfill\.cn|bootcss\.com|bootcdn\.net|staticfile\.org|staticfile\.net' .
If you find a match, do not just patch the source file you happen to notice. Check your templates, themes, generated HTML, archived pages, vendored assets, and documentation builds. Static-site generators may reintroduce the same tag even after you remove it from one page.