# 恶意CDN仍潜伏GitHub Pages，AI让情况恶化

- 来源：Berkeley RDI：Blog（AI 安全与评测）
- 发布时间：2026-06-24 00:00
- AIHOT 分数：82
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmr3zwbz500pgslw2rjca8wxd
- 原文链接：https://rdi.berkeley.edu/blog/polyfill

## 精选理由

polyfill.io等恶意CDN仍在GitHub Pages上感染近2000个站点，更可怕的是所有测试的AI模型都还会推荐这些链接，AI编码的便利正在变成供应链投毒的加速器。

## AI 摘要

UC Berkeley研究人员发现，近2000个GitHub Pages站点（18000+页面，累计530K+星标）仍在加载来自polyfill.io及其关联恶意CDN的脚本。这些CDN由已被OFAC制裁的Funnull Technology Inc.（现更名Triad Nexus）运营，2024年被出售后开始条件性注入恶意载荷，劫持移动用户、跳转欺诈站点、伪造认证弹窗窃取凭证。扫描12000+站点确认786个加载polyfill.io，1191个加载其他Funnull CDN。更严峻的是，所有测试的大语言模型在生成前端代码时仍推荐这些被污染的CDN URL，包括CyC2018/CS-Notes（184K⭐）、microsoft/AirSim（18K⭐）等知名项目及多所大学课程页面。

## 正文

[](https://rdi.berkeley.edu/)

首页研究教育动态博客关于

首页研究教育动态博客关于联系

恶意 CDN 仍然潜伏在 GitHub Pages 中，而 AI 让情况变得更糟

**Hao Wang, Koushik Sen, Dawn Song**

加州大学伯克利分校

2026 年 6 月 * *

_你的 AI 编程助手正在悄然植入一条供应链后门。在 polyfill.io 被出售给一家后来受到制裁的运营商并沦为恶意 CDN 一年之后，仍有将近 2000 个活跃的 GitHub Pages 站点（超过 18000 个页面，合计 53 万以上的 Star）从该网络加载脚本。而 AI 让情况更加糟糕：我们测试的每一个大语言模型，在生成前端代码时仍然会推荐这些已被入侵的 CDN URL。_ * *

一天下午，我打开了自己的个人网站（我知道，这很随机）。意想不到的事情发生了：一个灰色的弹窗弹出，要求输入用户名和密码。这是 nginx 的身份验证对话框，所以看上去可能很正常——但我的网站并没有 nginx 认证。那么它是从哪里来的？

困惑了几分钟后，我找到了罪魁祸首。在 HTML 深处埋藏着一个我甚至都不知道其存在的 ` ```

是加载浏览器 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，后来可能易主。一个曾代表兼容性的 script 标签，如今可能成为每个访问者浏览器中远程代码执行的突破口。

AI 编程助手尤其容易放大这类 bug，因为其输出看起来平平无奇。没有语法错误，没有测试失败，也没有构建中断。开发者在审查生成的 HTML 时，可能会看到一个熟悉的 CDN URL 就直接跳过了。在很多情况下，开发者甚至完全不知道模型添加了这个依赖项。

软件供应链风险不仅仅关乎你安装的包，也关乎你的代码所信任的 URL。静态网站看似固化，但其依赖项是动态的。 该做什么，以及下一步

我们建议你在源码和生成的站点输出中搜索已识别的 CDN URL。一个简单的示例：

如果发现匹配项，不要只修补你碰巧注意到的那个源文件。请检查你的模板、主题、生成的 HTML、归档页面、打包资源以及文档构建产物。静态站点生成器即使你从一个页面中删除了该标签，它也可能在其他地方重新引入。

推荐的修复方式： **完全移除 polyfill.io** —— 如果你不需要它。现代浏览器已支持这些脚本最初用于修补的绝大多数特性。 **用可靠的替代方案替换不安全的 CDN 链接**，例如 ``、``、``，或者自托管资源。 **尽可能使用子资源完整性（SRI）**。SRI 哈希值能让浏览器在字节意外发生变化时拒绝加载该脚本。 **审查你的内容安全策略（Content-Security-Policy）**。受影响的域名不应出现在 `script-src`、`default-src` 或其他白名单中。 **在发布前审计 AI 生成的 HTML**。将编程助手建议的 CDN URL 视为依赖项，而非无害的样板代码。

我们还发布了一个小型扫描工具，可自动检查某个网站是否仍在加载这些域名。你只需输入一个 URL，该工具就会爬取网站、检查 script 来源，并报告是否发现与受影响 CDN 家族相关的引用。

立即用 Bootlegg 扫描你的网站 → Berkeley RDI

推动去中心化与 AI 的科学、技术及教育，以赋能负责任的数字经济。

[主页] [研究] [教育] [活动] [博客] [关于我们]

版权所有 © 2025 加州大学董事会；保留所有权利。