当你向AI代理发出一段指令，期待它自动调用某个GitHub上的MCP服务器完成任务时，你是否想过——那个仓库可能是精心布置的陷阱？
约7600个虚假GitHub仓库、6600个伪造账号、超过1400万次下载——这就是FakeGit的规模。在被曝光的行动中，超过800个仓库伪装成AI技能和MCP服务器，分发SmartLoader等恶意载荷。
这是2026年7月由安全公司Island记录的恶意活动。它的特别之处不在于技术有多复杂，而在于攻击者精准地瞄准了一个正在爆发的新生态：AI代理。
为什么MCP服务器会成为攻击目标？
Model Context Protocol（模型上下文协议，MCP）由Anthropic在2024年底推出，旨在为AI代理与外部工具、数据源之间提供标准化的连接方式。开发者可以通过编写MCP服务器，让AI代理访问数据库、文件系统、API接口乃至执行代码。
短短两年内，MCP已成为AI代理领域事实上的"工具接口标准"，GitHub上涌现出成千上万的社区贡献仓库。而这也正是问题所在：AI代理默认信任它调用的工具，而开发者往往不会像审查npm或PyPI包那样审查一个MCP服务器的源码。
攻击者利用了这种信任落差。在FakeGit活动中，他们批量创建高仿真度的仓库，配备完整的README文档、提交历史和Star数，甚至使用与知名项目高度相似的命名。当一个AI代理或开发者在搜索"免费的AI搜索工具"或"MCP浏览器自动化"时，这些假仓库便自然浮现。
SmartLoader：从下载到全面沦陷
一旦开发者或AI代理拉取了这些仓库中的代码，SmartLoader便会启动。这是一种具备持久化驻留、远程命令执行和信息窃取能力的加载器类恶意软件。它可以静默下载后续载荷，将受害者的开发环境变为攻击者的跳板。
更令人担忧的是攻击链的自动化潜力。AI代理被设计为自主执行任务——安装依赖、运行脚本、调用远程服务。如果代理在评估仓库可信度时缺乏严格校验，恶意代码可能在没有人类点击"允许"的情况下被部署到生产环境或CI/CD流水线中。
Island的报告指出，这800余个仿冒AI技能和MCP服务器的仓库只是冰山一角。FakeGit的整体规模达到7600个仓库、6600个虚假账号和1400万次下载，说明这种"大规模养号+批量伪造仓库"的模式已经形成产业化操作。
AI代理生态的安全短板
这一事件暴露了AI代理生态中三个结构性问题：
第一，信任模型过于宽松。 许多AI代理框架默认信任来自公共仓库的MCP服务器，缺少签名验证或来源审计机制。攻击者只需让仓库出现在搜索结果中，就有机会被代理自动加载。
第二，发现机制易被操纵。 搜索引擎和代码托管平台的排序算法容易被伪造的Star、Fork和下载量欺骗。GitHub本身并不对仓库的安全性背书，但用户在AI辅助下倾向于将"高排名"等同于"可信"。
第三，开发者安全意识滞后。 传统供应链攻击主要针对依赖包管理器（如npm、pip），开发者已经形成了一定警惕。但MCP服务器和AI技能是相对新颖的概念，许多人尚未意识到它们同样需要严格的代码审查和来源验证。
应对之道：从被动扫描到主动防御
面对AI代理带来的新攻击面，企业需要建立多层防御：
在代理层面，应强制对MCP服务器进行签名验证和权限沙箱化，禁止代理自动加载未经审计的外部工具。在开发流程层面，建议将AI技能和MCP服务器纳入现有的软件成分分析（SCA）和供应链安全策略中，与npm、PyPI等传统依赖同等对待。在平台层面，GitHub等托管服务需要加强对批量伪造账号和仓库的检测，尤其是针对AI生态中高热度关键词的异常创建行为。
更根本的是，AI代理的设计哲学需要从"默认信任"转向"默认验证"。代理的自主性越强，其所依赖的信任边界就越需要被严格划定。否则，每一次自动化的工具调用，都可能成为攻击者渗透企业内网的入口。
FakeGit不会是个案。随着AI代理在企业中的部署加速，针对MCP服务器、AI技能库和代理工具链的攻击只会更加频繁和隐蔽。这场围绕AI代理信任的攻防战，才刚刚开始。
本文编译自AI News
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接