11 月 4 日，火绒威胁情报中心发了一份报告，讲的是从 2025 年起持续监测到的一类活动：有批账号在 GitHub 上系统性地投毒。手法不复杂——克隆正规项目、或批量造假仓库，把恶意 zip 塞进 src/、image/ 这类正常目录，再在 README 里挂下载链接。据报道，截至 2026 年 10 月，涉及 3 万余个仓库、1.5 万余个账号，恶意 URL 超过 5.6 万条。

真正值得注意的是诱饵主题：AI/大模型类占 24.5%，排第一，后面才是游戏外挂、流媒体工具、加密货币机器人。做这事的人很清楚，现在大家在 GitHub 上翻什么。

技术本质：没有漏洞，只是借了"信任"

先把边界划清楚：这次没有 0day，没有 Git 协议漏洞，GitHub 平台本身也没被攻破。攻击者用的是两样东西——开源仓库的默认信任，和 README 这个"事实上的安装文档"位置。

链路大致是这样的：

1. README 里挂链接。据报道，76.8% 的含 README 仓库里直接出现了压缩包文件名，常见做法是多个不同文字的超链接指向同一个 zip。
2. 2. 压缩包命名模仿语义化版本号，79.5% 都是这个套路，比如 tool-v2.3.1-full.zip，看起来很像正经发行包。
3. 3. 解压后结构几乎恒定：一个 .cmd、一个改名后的 LuaJIT 解释器、一个几百 KB 的混淆 Lua 文本，有时再带个 lua51.dll。
      那个 .cmd 的全部内容就一行：

start luajit.exe uix.txt

双击即中。之后是标准的信息收集流程：取机器名、用户名、临时目录，读注册表 HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid 当硬件指纹，请求 ip-api.com 拿地理位置，用 GDI 截全屏，再以 multipart 形式把截图和 beacon 发到 C2。样本里还埋了 Polygon 主网 eth_call 的备用地址回退，轮询几个公共 RPC 拿备用的 C2 域名——从工程化程度看，这不是随手玩玩。

和 2025 年初那波同类事件比，变了什么？埋包更批量、更自动了，账号池也更杂：报告中 51.8% 的账号是 2024 年及以前注册的，其中一部分是有多年真实提交历史的老号被盗后，从网页端提交了 Update README.md 把链接注进去。没变的是最后一环——永远要你自己下载、自己双击。

对普通开发者的实际影响

以前这类事主要坑爱折腾的人和做安全的，现在情况有些变化。AI 编程工具普及后，“clone 下来跑一下"这个动作被大幅加速。不少人的习惯已经变成：让 AI 助手读 README，把安装步骤列出来，然后一路回车。README 里写"下载 xx.zip 解压后运行”，AI 大概率会照做。

报告的建议里也单列了这一条：用 AI Agent 或自动化工具拉取、执行仓库脚本时，应配置沙箱隔离或加人工确认环节。这条不是客套话，是目前最容易失控的入口。

四个能马上用的检查手段

1. 看链接是否"多对一"

grep -oE 'https?://[^)"<>[:space:]]+' README.md \
  | sort | uniq -c | sort -rn | head

正常项目的 README 链接基本一一对应。如果十几个不同文字的超链接都指向同一个 raw.githubusercontent.com / githubusercontent.com 地址，基本可以判定有问题。

2. 看提交历史是不是只有 README 在动

git log --pretty='%h %ad %s' --date=short -15

报告里有个很硬的数字：91.3% 的投毒仓库，最近一次提交是 Update README.md 或主页文件修改；仅 10 月 12–14 日三天，就有 1.3 万个仓库被集中改动，其中 52.1% 是首次挂上压缩包链接。一个号称有几个功能版本的项目，提交记录里全是改 README、没有实质代码变更——这个信号足够说明问题。

3. 先看压缩包里有什么，别解压执行

unzip -l pkg.zip           # 只列目录，不落盘
unzip -p pkg.zip Launcher.cmd   # 打印内容到终端，不写文件

看到 .cmd / .bat + 一个体积极大的文本文件 + 一个改过名的解释器，这个组合直接删，不用再研究。

4. 确认下载地址的真实对象

curl -sIL "https://example.com/pkg.zip" | grep -iE 'content-type|content-length'

先看它是不是真的压缩包、有多大，和 README 里写的是否一致。

落地建议

• 陌生仓库优先 git clone 看代码，不要直接下 zip 跑脚本。 zip 是唯一不留在 git 历史里、事后无法审计的交付方式，正规项目很少需要它。
• • 企业侧：CI 拉依赖走私有镜像或锁死 commit hash，别让流水线跟着 main 分支跑；开发机别用管理员账号日常执行东西。
• • 已经双击过的：全盘扫一遍之后，还要查注册表启动项和计划任务，然后轮换密码与 token。只删文件不够——MachineGuid 和截图已经出去了，那台机器的身份基本算暴露。
    "开源不等于安全"这句话说了很多年，现在它多了一层意思：不是代码里藏着 bug，而是仓库本身就是鱼饵。

你有没有在 GitHub 上为了图省事，直接跑过 README 里的脚本？评论区聊聊。