安全工具本身不安全，是最危险的事
6月25日的安全情报报告中，两个看似不相关的漏洞同时亮起了红灯：Flowise AI平台的MCP Server命令注入漏洞（CVE-2026-56274），以及picklescan的五个安全检查绕过漏洞（CVE-2026-56315为主CVE）。
一个是AI应用构建平台，一个是ML模型安全扫描工具。它们分别代表了AI供应链的两个关键环节——构建时安全和部署时安全。两个环节同时出问题，意味着AI基础设施的安全防线正在从内部瓦解。
Flowise AI：低代码平台的隐形攻击面
Flowise是一个流行的拖拽式AI应用构建平台，允许用户通过可视化界面快速搭建LLM工作流。其MCP Server自定义功能的安全校验存在严重缺陷，攻击者可通过validateCommandFlags和validateArgsForLocalFileAccess函数绕过注入命令。
更具体的问题是Flowise助手更新端点存在批量赋值漏洞（GHSA-hp26-q66v-q2w7），允许已认证用户修改workspaceId等服务器控制属性，打破多工作空间环境中的租户隔离。CVSS评分7.6（高危）。
修复版本为Flowise 3.1.2。
为什么这很重要？ Flowise被大量中小企业和创业团队用于快速构建AI应用。低代码平台的价值主张是"简单"，但简单往往意味着安全控制的简化。当一个平台同时处理模型编排、工具调用和MCP协议时，任何一环的漏洞都可能导致整个AI应用的沦陷。
picklescan：ML供应链安全关卡失效
picklescan是Python pickle文件的安全扫描工具，被广泛集成在Hugging Face模型下载管道中，用于检测恶意序列化对象。它的作用是在用户加载ML模型之前，拦截其中隐藏的任意代码执行攻击。
但CVE-2026-56315及其四个子绕过项证明，这个安全关卡可以系统性地被绕过：
| CVE编号 | 绕过路径 |
|---|---|
| CVE-2026-56315 | 主CVE，安全检查绕过 |
| CVE-2025-71376 | idlelib.autocomplete |
| CVE-2025-71370 | torch.jit.unsupported_tensor_ops |
| CVE-2025-71365 | numpy.f2py.crackfortran.myeval |
| CVE-2025-71341 | profile.Profile.runctx |
主CVE的CVSS评分高达9.8。这意味着依赖picklescan做安全检查的组织一直处于虚假安全感中——恶意模型可通过多个Python标准库模块暴露的任意命令执行函数绕过检测。
修复版本为picklescan 1.0.4。
AI供应链攻击的系统性特征
这两个漏洞不是孤立事件。6月同期还出现了：
- mamba-ssm框架（CVE-2026-31239，CVSS 9.8）：加载HuggingFace模型时使用
torch.load()未启用weights_only=True，允许反序列化任意Python对象 - Hades供应链攻击活动：泄露的Miasma工具包被武器化，针对PyPI、npm、RubyGems等开源注册表，304+软件组件和73个Microsoft GitHub仓库受影响
- MCP协议攻击面：OX Security发现MCP协议的官方SDK在所有支持语言中均未对命令字符串进行有效验证
这些事件共同指向一个趋势：AI供应链正在成为系统性的攻击面，而非单点漏洞问题。
防御建议
- Flowise用户：立即升级至3.1.2+，检查多工作空间环境中是否存在未授权的跨工作空间资源访问
- ML pipeline运维：升级picklescan至1.0.4+，重新扫描已部署模型
- 模型加载安全：所有使用
torch.load()的代码，确保启用weights_only=True参数 - 依赖审计：对AI项目的
requirements.txt和模型依赖进行全面审查 - MCP协议使用：审查MCP Server的输入验证逻辑，限制命令执行范围
行业观察
AI安全正在从"保护AI不被攻击"演变为"保护整个AI供应链不被渗透"。当开发框架、安全工具、协议标准、模型仓库都在同一时期出现问题时，这已经不是个别厂商的责任，而是整个生态需要正视的系统性风险。
对于正在大规模引入AI应用的企业而言，现在需要认真思考一个问题：你的AI供应链中有多少环节是你真正信任的？