企业官网建设流程全解析

2026 年 10 月 12 日，Kong Gateway 的一个 SQL 注入漏洞公开：CVE-2026-1907，CVSS v4.0 评分 7.5（High），影响 Kong Enterprise Gateway 与开源版 Kong Gateway。

漏洞的位置很具体：混合模式（Hybrid Mode）下集群通信逻辑。攻击方式是通过向控制面（Control Plane，CP）发送特制的 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 官方文档为最终依据。信创环境下的风险分析为基于通用工程经验的推断，不代表任何具体项目的实际情况。产品能力描述仅引用其官方产品资料所载内容。

互动：你们的网关迁移项目做完之后，有没有重新盘过一次「哪些来源可以连上控制面」？还是沿用了迁移前的假设？