同一天，三个智能体应用被点名
10 月 27 日这天的安全公告里，有三条都指向同一个品类：智能体应用本身。把它们并排放在一起看，会发现一件有点尴尬的事——没有一条跟模型有关。
其一是 CVE-2026-110474，CVSS 4.0 得分 8.7，出在 CreditNirvana 的智能体客服中心应用上。问题是一把静态接口密钥被硬编码进了前端 JavaScript，任何未认证的人都能把它抠出来，然后直接调接口把通话录音和转写文本拉走。这条是经 CERT-In 通道披露的。
其二是 CVE-2026-116339，CVSS 3.1 得分 7.3，出在讯飞 astron-agent 1.1.2 及更早版本。它的 DDL 白名单处理器用的是一份不完整的黑名单，公开的验证代码靠在语句里塞注释就能蒙混过去。披露方的记录里写着：厂商未对披露作出回应。
其三是 CVE-2026-116516，得分 6.5，Mattermost 的 Agents 插件。认证用户让它去总结一份特制过的 Zoom 聊天记录，插件直接崩溃，编号 MMSA-2026-00723。
把智能体的名字遮掉再看
遮掉产品名，这三份公告和十年前的 Web 应用公告没什么两样：密钥写在前端、输入校验靠黑名单、异常输入导致崩溃。全是老题型，也全有成熟的解法——密钥放后端或保险库、校验改成白名单、输入做长度与结构约束。
差别在后果。一个普通的 Web 应用被打了，影响面基本止于它自己的数据；而智能体应用通常同时握着两样东西：一堆跨系统的凭据，和直接执行动作的权限。同样是前端密钥泄露，背后连着的可能是完整的通话录音库；同样是一次校验绕过，换来的可能是建表改表的权限。缺陷的成因没变，失守半径变了。
这也是为什么「把编码智能体当特权软件来管」这类建议在近几个月反复出现。很多企业的治理清单里，智能体还被归在「效率工具」那一栏，而它实际能碰到的东西已经和运维账号差不多。
更值得注意的是披露节奏的参差
三起事件的处置状态并不齐整：一件走国家级漏洞协调通道、有公开编号；一件已有公开验证代码但厂商未回应披露；一件由厂商自行编号并给出修复版本。这种参差本身就是信息——它说明智能体应用还没有形成统一的披露与修复惯例，而这类应用的部署速度比这个惯例的成型速度快。
还有一处需要留白：公开摘要里没有给出受影响实例的数量、是否有在野利用的证据、以及各厂商的完整修复时间线。这些细节目前官方及行业暂未披露更多，后续将持续跟进迭代动态。读者要评估自身风险，仍应以厂商公告与官方 CVE 记录为准。
把这三起与同周另外两类披露放在一起看会更清楚：一类是执行沙箱的默认配置问题，一类是工具协议层的路径遍历。三者指向同一件事——智能体系统的薄弱点正在从「模型会不会做坏事」转向「它跑在什么上面、读到什么、被谁配的」。模型侧的对齐讨论吸引了大部分注意力，而真正被攻破的地方往往在更下面一层。