AI 帮你生成接口，攻击者生成命令

一份 OpenAPI 文档，本该是给 AI 看的『接口说明书』，现在却可能成为操作系统命令的载体。

Progress 于 2026 年 10 月 6 日发布安全公告，披露其 DataDirect Autonomous REST Connector AI Model Generator Agent（早期预览版）存在一个关键级命令注入漏洞，编号 CVE-2026-91140。攻击者只需构造一份特制的 OpenAPI 或 Swagger 文档，就能在运行受影响 Agent 的环境中执行任意操作系统命令。

这不是又一起『AI 幻觉导致事故』的花边新闻，而是一个信号：AI 工具链正在把经典漏洞类型，原封不动地搬进新的信任边界里。

🔍 一份文档，如何变成攻击载荷

先看场景。一家企业的开发团队想快速对接某个第三方 REST API，于是使用 Progress 的 AI Model Generator Agent：把目标服务的 Swagger 文档喂进去，让 Agent 自动生成连接器模型，省去手写映射的时间。

问题就出在这个『喂』的动作上。CVE-2026-91140 的核心机理是：Agent 在解析 OpenAPI/Swagger 文档的过程中，对文档内容缺乏足够的过滤与转义，攻击者可以在文档字段中夹带命令注入载荷，最终在 Agent 所在的宿主环境里执行任意操作系统命令。

完整攻击链路并不复杂：

把关键信息拉成一张表，看得更清楚：

产业层面的判断是：输入即攻击面的老逻辑没有变，变的是输入的形态。 过去攻击面是 HTTP 参数、文件上传，现在一份『看起来无害的接口描述文档』也成了不可信输入。凡是直接消费外部内容的解析器，无论上游是不是大模型，都该按处理不可信数据的最高标准对待。

🧩 AI Agent 为什么是块新的软骨头

金山句式说：信任边界移动到哪，漏洞就长到哪。

传统 Web 应用的安全建设，花了二十年把『不可信输入』的清单列得足够长：参数、Header、Cookie、文件、第三方回调。而 AI Agent 的出现，一夜之间往这张清单里塞进了一堆新成员——提示词、检索到的文档、工具返回结果、外挂知识库，以及本文的主角：用来描述外部系统的 OpenAPI/Swagger 文档。

这些输入有两个共同特点：一是来源天然不可信，往往直接来自外部网络或第三方系统；二是消费它们的解析链路普遍年轻，没经过大规模攻击的洗礼。AI Model Generator Agent 恰好把这两个特点叠满了——它吃的就是外部接口文档，干的又是『按文档内容生成可执行逻辑』这种高权限活儿。

更值得警惕的是权限问题。传统应用即便被注入，攻击者拿到的往往是一个受限的 Web 进程上下文；而开发场景里的 Agent，为了读写文件、调用工具链、生成代码，通常运行在权限宽松的宿主环境。命令注入一旦得手，攻击者面对的不是一个沙箱里的沙箱，而是一台几乎不设防的开发机。

把 AI 工具链的攻击面摊开看，明面上的只是冰山一角：

多位在企业集成一线做安全评审的工程师私下有个共识：安全团队对 AI 应用的审查，大多停留在『模型会不会泄密』这一层，而 Agent 背后那台跑着解析器和工具链的机器，往往根本不在资产清单里。看不见的资产，是最先失守的资产。

🏭 厂商视角：连接器生意与预览版的代价

把镜头拉回 Progress 这家公司。它靠 DataDirect 系列数据连接器起家，核心生意就是帮企业打通各种数据库、SaaS 和 API——这是个典型的『企业集成』市场，客户付费买的就是稳定、兼容、省心。

AI 浪潮来了以后，集成厂商的应对路径高度一致：把大模型能力塞进传统产品线，让 AI 自动生成连接器、自动做字段映射、自动写适配代码。Autonomous REST Connector 的 AI Model Generator Agent 就是这个思路的产物——用 AI 把『对接一个新 API』的成本压到最低。

但这次事件暴露了这条路的一个结构性矛盾：AI 功能的迭代速度，和企业软件客户要求的安全确定性，天然打架。 Early Access Release 的本质，是让愿意尝鲜的客户提前承担测试成本，换取更早获得新能力。安全测试的深度、模糊测试的覆盖、漏洞响应流程的成熟度，在预览版阶段往往都是打了折扣的——这次的命令注入漏洞恰恰出现在 EA 版本上，很难说是巧合。

对 Progress 来说，这也不是无关痛痒的小事。这家厂商此前已因 MOVEit 文件传输产品的大规模数据泄露事件被行业反复审视，客户对其『安全交付能力』的信任本就处在修复期。关键级漏洞再次出现在自家产品线上，无论组件新旧，都会被采购方记一笔。

放在整个产业里看，这件事的定位可以用一张四象限图说清——AI Agent 类组件正处在『技术门槛不低、但安全成熟度与商业价值错位』的尴尬位置：

AI Model Generator Agent 这类组件，技术含量高、迭代快，但安全成熟度还在起步线附近。产业逻辑很直白：新贵组件的商业溢价，有一大块其实是用安全债务预支的。

🛡️ 防御侧：给 Agent 上锁的正确姿势

聊完机理和格局，回到最实际的问题：企业该怎么防？

第一条原则：把喂给 Agent 的一切内容，按攻击载荷处理。 OpenAPI/Swagger 文档、第三方接口描述、Agent 下载的配置文件，本质都是不可信输入。接入前应经过校验与清洗，避免解析链路直接消费未经审查的外部文档。对本次漏洞而言，最直接的缓解手段就是遵循厂商公告升级，并在升级前暂停在可信环境中运行受影响的 EA 版 Agent。

第二条：给 Agent 的宿主环境做最小权限改造。 开发场景里的 Agent 不应该拥有完整的宿主机权限——独立的低权限账号、文件系统与网络的访问白名单、禁止直接派生系统 Shell，这些传统加固手段在 Agent 时代不是过时了，而是更关键了。命令注入的危害大小，最终取决于拿到 Shell 之后能摸到什么。

第三条：把 AI 组件纳入供应链安全管理。 很多企业的资产清单里有 AI 应用，却没有 AI 应用背后那只 Agent、那个解析器库的版本记录。给 AI 工具链建立组件台账、跟进厂商安全公告，应该成为和跟踪开源依赖同等级别的常规动作——尤其是 Early Access 这类本身就带着『未充分测试』标签的版本。

落地时可以按下面的痛点逐条对照：

一句话总结防御逻辑：AI Agent 不是新型生物，它是一段跑在贵机器上的旧代码——用老办法管它，就够了。

小结

CVE-2026-91140 的技术细节并不炫技，甚至有点『复古』——命令注入这种上世纪就被人摸透的漏洞类型，在 2026 年的 AI Agent 身上原样复现。这恰恰是本次事件最有价值的部分：AI 改变的是输入的形态和执行的权限，没有改变漏洞的基本法。对厂商，预览版的快速迭代需要配得上关键级定级的安全测试；对企业，是时候把那只藏在开发机上的 Agent 拉进资产清单、按上最小权限了。下一份『特制文档』到达之前，锁要自己先上好。