2026 年 10 月 12 日Kong Gateway 的一个 SQL 注入漏洞公开CVE-2026-1907CVSS v4.0 评分 7.5High影响 Kong Enterprise Gateway 与开源版 Kong Gateway。漏洞的位置很具体混合模式Hybrid Mode下集群通信逻辑。攻击方式是通过向控制面Control PlaneCP发送特制的 RPC 请求导致未授权的数据库访问。利用条件写得也很清楚需要能访问控制面的 clustering 端口并且持有一个有效的客户端证书和私钥。修复方案是 Kong Gateway 3.13.0.2。这三行信息合起来是一个很典型的架构缺陷样本。一、漏洞的利用链先把它画出来四步里第一步和第二步都是「合法」的——持有证书、发送 RPC在协议层面都通得过。真正出问题的只有第三步集群通信逻辑把请求内容拼进了 SQL。这就是为什么它的 CVSS 是 7.5 而不是 9.8它要求攻击者先有一个被信任的位置。但这个「先有」恰恰是混合模式设计的必然结果——混合模式里的数据面节点本来就需要连到控制面上。换句话说控制面的 clustering 端口不是「意外的暴露面」而是「设计上必须开的门」。漏洞的严重性正来自这里要防它不能靠「不开放端口」只能靠「进门的人不能乱来」。二、混合模式的信任假设要理解这个洞得先理解混合模式的架构意图。混合模式把网关拆成两层控制面管配置、数据面跑流量。好处很直接——数据面可以部署在多处多个机房、多云、边缘但它们都从同一个控制面拉配置所以配置是一致的、可统一管理的。这个架构里有一个隐含假设能连上控制面 clustering 端口的节点都是可信的数据面节点。这个假设在两种情况下会失效失效情况一证书管理不严。漏洞要求「有效客户端证书和私钥」。如果证书签发范围过宽、私钥分发到了不该到的地方、或者旧节点下线后证书没吊销那么这个前提就被满足了。失效情况二网络分区不彻底。clustering 端口通常是内网端口。但如果运维把控制面部署在了边界区域、或者内网分段不严那么「能连上」这个条件的门槛其实很低。核心问题在这里架构设计把「身份可信」当成了「输入可信」。一个节点有合法证书只说明它是谁不说明它发来的每个请求都是良性的。把前者的验证结果当成后者的保证就是这类漏洞的通用成因。三、这类问题在信创环境下的对应风险把视角转到国内的信创改造场景。API 网关是几乎所有信创项目的必换件而「控制面 数据面分离」也是国产网关常见形态。所以上面那个信任假设在改造项目里有三个容易被放大的地方放大点一证书体系重建过程中的过渡期。信创改造往往要重建 PKI改用国密算法、换 CA。过渡期内新旧证书并存签发与吊销的规则容易出现空档。这个窗口期恰好对应上面说的「失效情况一」。放大点二多机房数据的网络分段。金融、能源类客户的数据面常分布在生产网、测试网、多个机房。分段规则在改造期间会被反复调整。每次调整都是一次「clustering 端口可达范围」的重新定义而这件事通常不在变更评审的重点里。放大点三迁移工具带来的额外凭据。国产网关普遍提供「一键迁移现有 Nginx 配置」之类的工具这类工具通常需要较高权限来读取源配置。迁移期的临时高权限凭据如果没有在迁移完成后收回就是一条长期存在的路径。四、可落地的四条收敛动作从上面的分析能直接导出四条第一把 clustering 端口当作最高敏感资产来管。判定标准这个端口的可达来源清单能不能列举出来并且每一项都有负责人如果答案是「就是内网」那等于没有清单。第二证书矩阵化而不是「发出去就行」。每个数据面节点一张证书证书里绑定节点身份禁用共享证书。吊销流程要与节点下线流程绑定——下线节点时必须吊销证书这件事要写进运维 SOP而不是靠人记。第三控制面对数据面请求做输入校验而不是只做身份校验。这条是根治。身份的验证结果不能替代输入的验证。具体做法是所有进入数据库层的字符串都走参数化控制面对数据面发来的配置内容做结构与长度校验。第四升级时先盘点版本分布。3.13.0.2 是修复版本。混合部署环境下「升级」通常不是一次动作而是数据面节点的滚动升级。滚动期间的版本混合状态本身就是一个需要评估的风险窗口。五、常见误区误区一「需要证书所以不严重」。证书不是稀缺资源。在多节点混合部署里证书是批量签发的。批量签发意味着批量风险。误区二把混合模式和单体模式的风险混为一谈。混合模式引入了额外的一条通信边CP↔DP这条边在单体模式下不存在。架构复杂度增加的地方就是漏洞容易堆积的地方。误区三以为改成 HTTPS 就安全了。这个洞在传输层之后——请求已经被正确解密、身份已经被正确验证问题出在业务逻辑怎么处理这个请求。传输加密防不了注入。误区四只关注 CVE 本身不检查同类模式。Kong 是这次的样本。任何「控制面 数据面分离」的网关只要控制面对数据面发来的内容做了非参数化的处理结构上就是同构的。检查的方法应该复用而不是等下一个 CVE。六、结语与适用边界这个洞最值得记的一句话是它不需要攻击者突破任何一道门只需要他站在门里面。把视角放回国内落地API 网关在信创项目里往往是流量的唯一入口权限也最高。它的安全假设一旦错了影响范围是全局的。所以在这类项目里网关这一层需要的不只是「替换成功」而是迁移之后的凭据矩阵、端口清单、以及版本分布都有一份能被查证的记录。金蝶天燕 Apusic 这条线上ALB 承担的是流量入口与七层代理的职责兼容 Nginx 配置并支持一键迁移现有 Nginx 服务、多协议代理覆盖 HTTP/HTTPS/FastCGI/WebSocket/gRPC/Dubbo/MQTT、安全策略含 IP 黑白名单与限速限并发、提供 RESTful 外部 API 与 alb-cli 命令行工具AAS 承担应用侧承载内置智能运维管控与国密安全能力、防御慢攻击、SQL 注入与跨站脚本。迁移类项目里它们要解决的实际问题是——替换之后原有的暴露面清单能不能被准确重建而不是替换动作本身。适用边界本文漏洞信息CVE 编号、CVSS 分值、影响范围、修复版本以 NVD 记录与厂商安全公告为准具体修复方案以 Kong 官方文档为最终依据。信创环境下的风险分析为基于通用工程经验的推断不代表任何具体项目的实际情况。产品能力描述仅引用其官方产品资料所载内容。互动你们的网关迁移项目做完之后有没有重新盘过一次「哪些来源可以连上控制面」还是沿用了迁移前的假设