CVE

十月十四日两条智能体框架安全消息同步上线。Tenable 容器安全插件收录 CVE-2026-107289：pydantic-ai 与 pydantic-ai-slim 在 IPv6 环境下存在 SSRF（CWE-918），相关问题在 1.107.6 和 2.44.0 修复，CWE 同时标注 CWE-1289。同日 TechGig 报道安全研究者在微软开源智能体框架 Semantic Kernel 里发现两个 CVE 拼成的「致命三连」：CVE-2026-26030 允许攻击者通过搜索插件默认过滤器追加任意代码，CVE-2026-25592 允许两步链把恶意脚本写到 Windows 启动目录，达成持久化 RCE。MCP 也被点名是标准化攻击面。 pydantic-ai 的 IPv6 SSRF 是什么坑？ SSRF 是工具调用 HTTP 请求时没校验目标地址，让 agent 去打内网。pydantic-ai 的问题在 IPv6 环境下才触发——很可能是它的地址白名单只覆盖了 IPv4 私网段（10/8、172.16/12、192.168/16），却漏了 IPv6 的 ULA 段（fc00::/7）和 link-local（fe80::/10）。攻击者把工具 URL 指到一个 IPv6 内网地址，白名单检查失效，请求就打进去了。这种「协议族补丁没打全」的洞在 agent 框架里非常普遍。 Semantic Kernel 的 RCE 链怎么拼？ 第一步 CVE-2026-26030：搜索插件默认有一个过滤器参数，攻击者通过提示词注入把过滤器改写成代码片段，插件在执行时把这段代码拼进了执行上下文。第二步 CVE-2026-25592：利用第一步拿到的代码执行能力，把一个 PowerShell 或 batch 脚本写到用户的 Windows Startup 目录，下次登录自动运行。这就是「致命三连」——提示词注入、插件过滤器拼接、启动目录持久化——三步从一个聊天消息到整机接管。 ...

NVD 十月十四日收录 CVE-2026-108586：1MCP Agent（@1mcp/agent）0.20.0 到 0.39.0 存在授权错误。攻击者持有一个单标签的 OAuth token，本应只能访问带该标签的工具；但高级标签过滤器支持取反表达式 not ，攻击者可以发「not 已授权标签」这样的过滤器，列出并调用后端 MCP 服务器上所有不在授权范围内的工具。NVD 把这个归为 incorrect authorization（CWE-863）。 取反表达式为什么会变成越权通道？ 授权模型的设计是：token 授予了标签 A，客户端只能请求 tag=A 的工具。但过滤器语法支持 not A，语义是「所有不带 A 的工具」。服务端在解析过滤器时，把 not A 当成一个合法查询条件去执行，而不是在授权层拒绝。这是典型的「查询条件 vs 授权条件」混淆——服务端把过滤器当成数据查询，却忘记了授权范围是「只能在 A 里查」，不是「可以在全表里查 not A」。 攻击影响有多大？ MCP 服务器通常把数据库、文件系统、内部 API 都暴露成工具。一个本该只读客户标签的 token，通过 not 过滤器可以列出所有内部工具、调用管理员接口、读别的租户数据。这不是读少了，是直接越权到全量工具。NVD 描述里明确写了「list and invoke tools on backend MCP servers outside their granted scopes」。 修复和教训是什么？ 升级到 0.39.0 之后版本。对所有实现 tag-based 授权的团队，教训是：过滤器表达式在授权层必须先求授权范围的交集，而不是直接下推到数据层。任何支持 not、or、通配符的过滤语法，都是越权重灾区——默认拒绝，而不是默认放行。 还要补一个设计层面的教训。基于标签的授权模型本身是好设计——它让权限粒度到工具级。但只要过滤器语法支持否定、集合运算，授权层就不能简单信任客户端传来的过滤条件。正确做法是：服务端先把 token 允许的标签集合算出来，然后把客户端的过滤器跟这个集合求交集，而不是让过滤器直接作用于全表。所有做 MCP 网关、agent 平台的团队，都应该立刻审计自己的标签过滤实现。这个洞的 CVSS 还在评估，但从「越权调用任意后端工具」看，至少是高危。 ...

NVD 十月十四日收录 CVE-2026-107292：to_web() 和 clai 这两个本地 Web 开发聊天服务器不校验 HTTP Host 头。攻击者架设一个恶意网站，诱导开发者访问；该网站用 DNS 重绑定把域名解析到 127.0.0.1，浏览器就把这个恶意页面对本地 loopback 上跑的 agent 服务器发的请求当成同源请求。恶意页面可以读取 agent 服务的 UI，并提交聊天请求——这些请求带着本地进程的权限和凭证执行 agent 工具，导致数据泄露或副作用。NVD 特别注明：绑定到 localhost、Origin 检查、CSRF token 都挡不住这种同源 DNS 重绑定。 DNS 重绑定为什么这么难防？ 浏览器的同源策略是按域名判断的，不是按 IP。一个恶意域名 evil.com 第一次解析到攻击者服务器，返回一段 JS；JS 触发第二次 DNS 查询，把 evil.com 重解析到 127.0.0.1。此后浏览器认为 evil.com 跟本地 agent 服务器「同域」，因为域名没变。Host 头检查能挡一部分——服务器看到 Host 是 evil.com 而不是 localhost 就拒绝——但 to_web 和 clai 没做这个检查，于是请求被正常处理。 为什么绑 localhost 不够？ 开发者以为绑 127.0.0.1 外网打不进来就安全了。但 DNS 重绑定是从浏览器内部发起的，流量不经过外网防火墙，直接在本机 loopback 上走。浏览器作为受害者的「代理」，把恶意请求送到了本地服务。CSRF token 也没用，因为恶意页面已经能同源读取 agent UI，token 可以从页面上抓出来。Origin 检查同样失效，因为 Origin 是 evil.com，但浏览器把请求发去了 127.0.0.1——这正是重绑定的核心。 ...

NVD 于十月十四日收录 CVE-2026-108600：open-multi-agent（@open-multi-agent/core）1.5.0 到 1.21.2 版本的 file_write 工具沙箱存在链接跟随漏洞。攻击者可以在工作区里放一个悬空符号链接，再通过提示词注入引导 agent 把内容写到这个符号链接指向的任意路径——只要 agent 进程有写权限的地方都能落盘。 悬空符号链接为什么能绕过沙箱？ 绝大多数 agent 沙箱的保护逻辑是「校验目标路径是否在工作区根目录之下」。file_write 收到一个路径，先做字符串前缀检查，看着是在 workspace 里就放行。但如果这个路径本身是个 symlink，操作系统在 open() 时会顺着链接走到真实目标。校验发生在符号链接解析之前，攻击者就绕过了前缀检查。这是经典的 TOCTOU（检查时间与使用时间不一致）竞态在 agent 沙箱上的翻版。 攻击链的完整路径是什么？ 第一步，攻击者通过任何能让 agent 在工作区写文件的途径（比如一个恶意网页、一份被污染的文档）放一个 symlink，指向 /root/.ssh/authorized_keys 或 Windows 启动目录。第二步，用提示词注入让 agent 把攻击者控制的内容「写」到这个 symlink 路径。第三步，agent 进程的权限就是落盘权限——如果 agent 以 root 跑，攻击者就拿到了一个持久化后门。NVD 描述里明确写了「prompt injection to write attacker-influenced content anywhere the agent process can write」。 修复方案是什么？ 升级到 1.21.2 之后的版本。正确的沙箱实现要在 open 时用 O_NOFOLLOW 或 fstat 比对真实路径与工作区根，不能只做字符串前缀检查。对所有自研 agent 框架的团队，这是一个审计清单：你的 file_write、file_edit、shell 工具，有没有 follow symlink？ ...