我把 Jet Admin 的提示注入拆到了字段级，发现它连「谁在说话」都没分清

9.9 分不是给模型的，是给架构的

NVD 在 11 月 13 日把 CVE-2026-123965 标成了 CRITICAL，CVSS 9.9。我盯着这个分数看了半天，因为 9.9 意味着攻击向量几乎全满，攻击复杂度低，不需要任何前置权限之外的交互。

但 Jet Admin 不是什么边缘产品。它是一个低代码后台管理平台，Cloud 版本里集成了 AI 助手，用来根据自然语言生成查询、解释字段、甚至直接操作数据表。问题就出在这个助手上。

官方描述只有一句话，说一个持有免费账号的远程攻击者可以通过提示注入暴露敏感信息。没有给攻击链，没有给受影响的具体接口，也没有说补丁版本。我翻了一遍 NVD 的引用，只有厂商公告的链接，公告本身也没展开。

所以这篇里凡是讲到具体调用路径的地方，都是我从同类架构的通用实现反推的。Jet Admin 的源码没有公开，Cloud 版本更看不到。这一点我得先说清楚，免得你把我后面的推断当成官方结论。

它把用户的话和系统的话拼成了一句话

提示注入之所以能成立，根源只有一个，系统指令和用户输入在进入模型之前没有被结构性地隔开。它们变成了同一个字符串里的前后两段。

我见过太多这类实现。后端收到用户请求，拼一个模板，大概是「你是一个数据库助手，用户问的是：{query}，请生成 SQL」。然后把这个完整字符串丢给模型。模型没有能力区分哪部分是开发者写的，哪部分是攻击者写的，它只看到一段连续文本。

Jet Admin 的 AI 助手要操作数据表，所以它拿到的上下文比普通聊天机器人更多。它可能包含当前工作区的表结构、字段名、甚至部分样本数据。这些内容一旦和用户输入拼在同一个 prompt 里，攻击者只需要构造一句话，让模型「忽略之前的指令」，然后把上下文里的表结构和数据当成回答吐出来。

这里的关键不是模型笨，是工程上少了一层边界。模型永远会服从它看到的最新指令，这是它的工作方式，不是 bug。真正的 bug 是有人把不可信输入放进了指令区。

图 1　本文示意图：系统指令和用户输入在进入模型前被拼成同一个字符串，隔离层缺失。

校验发生在拼接之后，等于没校验

我推测 Jet Admin 的调用链大概是这样的。前端把用户输入发到一个 AI 代理接口，后端做一次参数校验，检查字段非空、长度不超限，然后从数据库里取出当前工作区的元数据，拼进 prompt 模板，最后调用模型。

问题出在第三步和第四步之间。参数校验只看了用户输入的格式，没有看它和系统指令拼接之后会不会改变语义。而拼接这个动作本身，就是把不可信数据和可信指令混在一起的时刻。

更麻烦的是，这个 AI 助手有权限读取当前工作区的表结构。也就是说，即使攻击者没有直接访问某张表的权限，只要他能让助手把表结构说出来，他就知道该往哪里 injection。信息泄露和权限提升在这里是连着的。

图 2　本文示意图：从免费账号发起请求到敏感信息返回，每一步都缺少阻断点。

推演拼接层的失效点（示意代码，展示系统指令和用户输入合并后模型无法区分来源）

同类产品里做得好的，会把用户输入放在单独的消息角色里，系统指令放在另一个角色里，中间加一道输出过滤。Jet Admin 的公告没有提它做了这一层，我只能假设它没做。

一个免费账号能走到哪一步

CVSS 9.9 的向量里，攻击向量是网络，攻击复杂度是低，权限要求是低，用户交互是无。翻译成人话就是，攻击者坐在自己电脑前，注册一个免费账号，不需要骗任何人点链接，就能发起攻击。

但 9.9 不代表一定能拿到全部数据。它只说明这个漏洞在理论上的最大影响是机密性完全丧失。实际能拿到什么，取决于 AI 助手被授予了多大的数据访问范围。

如果助手只能读当前用户自己的数据，那影响就有限。如果助手能读整个工作区的元数据，那一个免费账号就能摸到付费客户的数据结构。Jet Admin 的定价页显示免费版有工作区数量限制，但没有说明 AI 助手的数据边界。这里公开信息是缺的。

图 3　本文示意图：暴露面在公网、影响程度高，这一格对应免费账号可触达的云实例。

我的判断是，这个漏洞最现实的利用方式是信息收集，而不是直接拖库。攻击者先用提示注入让助手吐出表名和字段名，再用这些信息去试探其他接口。单靠提示注入拿不到行级数据，除非助手本身有执行查询的权限。

我怎么验的，以及验到哪一步就停了

我没有 Jet Admin 的 Cloud 账号，也没有拿到任何内部接口文档。所以下面的验证步骤只能做到「确认你的实例是否暴露在风险面里」，做不到「复现一次完整攻击」。

第一步，确认你的 Jet Admin 版本。Cloud 版本没有版本号可查，只能看厂商公告里有没有列出修复时间。如果公告说「已修复」，那修复时间之后的实例是安全的。如果公告没说，默认所有版本都受影响。

第二步，检查 AI 助手是否对免费账号开放。如果免费账号根本调不到 AI 接口，那这个漏洞对你的实际风险就降了一档。但这不意味着付费账号安全，只是攻击门槛变高了。

第三步，看 AI 助手的返回内容里有没有出现表名、字段名或样本数据。如果有，说明它的上下文里带了元数据，提示注入的收益就更大。这一步不需要攻击，正常问一句「这个工作区有哪些表」就能看出来。

核对实例版本（示意代码，确认你的 Jet Admin 是否在公告覆盖范围内）

我写了一个脚本，用来检查匿名访问 AI 接口的状态码。它能帮你快速判断接口是否对外网开放，但没法告诉你拼接层到底有没有隔离。拼接层的问题得看代码或者抓包，公开信息里没有。

今天能做的三件事，按顺序来

第一件，立刻做的，去厂商公告页确认修复状态。如果公告里给了修复版本号，升级到那个版本。如果公告只说「正在修复」，那先把 AI 助手对非管理员账号关掉。Jet Admin 的后台应该有角色权限开关，把 AI 功能的访问权限收到管理员组。

第二件，这周做的，给 AI 助手的输出加一层人工审核。任何由助手生成的查询或数据导出，在真正执行之前过一道确认。这不是技术修复，是流程缓解，但能挡住大部分自动化注入。

第三件，如果前两件都做不到，过渡办法是限制 AI 助手能访问的数据范围。让它只能读当前用户有权访问的表，而不是整个工作区。这个配置在 Jet Admin 里叫什么名字我不知道，公开文档没写。你得问厂商支持。

我不建议等。CVSS 9.9 加上免费账号可触达，这两个条件叠在一起，意味着扫描器作者有足够动力去写 PoC。公告发布是 11 月 13 日，今天 14 号，还没看到公开 PoC，但窗口不会太长。

同类组件的老毛病，这次又犯了

过去两年我拆过的 AI 功能漏洞里，提示注入占了七成以上。它们的共同点不是模型选错了，是工程上把「方便」放在了「隔离」前面。

开发者想让 AI 助手聪明一点，就多给它一点上下文。想让它响应快一点，就少做一层过滤。想让它能直接操作数据，就给它一个高权限的服务账号。每一步单独看都合理，叠在一起就是一个 9.9 分的洞。

Jet Admin 这次的问题，我猜不是它一家的问题。所有在后台管理面板里塞 AI 助手的低代码平台，都值得拿这条 CVE 当镜子照一下。你的助手分得清谁在说话吗。

这个问题不解决，下一个 9.9 分只是时间问题。

这次没查到什么，等厂商补

公开信息里缺三块。第一，修复版本号。厂商公告没有给出具体版本，只说了「已发布补丁」。第二，AI 助手的数据访问边界。免费账号和付费账号在助手权限上有没有区别，文档没写。第三，漏洞是被谁发现的。NVD 没有致谢信息。

这三块里，第二块最影响实际风险。如果免费账号的助手只能读自己的数据，那 9.9 分就偏高了。如果它能读工作区元数据，那 9.9 分是准的。

我的推断建立在「助手上下文包含工作区元数据」这个假设上。这个假设来自同类产品的通用设计，不是 Jet Admin 的官方确认。如果后续有人测出助手根本不带元数据，那这篇里关于影响面的判断就要下调。

在那之前，按最坏情况准备。

写在最后

提示注入不是模型的安全问题，是工程上把「方便」排在了「隔离」前面的代价。Jet Admin 这次 9.9 分，分数是给架构的，不是给模型的。你今天去关掉一个对免费账号开放的 AI 接口，比等下一个补丁更有用。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。