作者 akihi（白帽攻防录讲师），某甲方网络安全工程师，合合 SRC 年度第一、腾讯 SRC 连续三年前十，单漏洞赏金 4w+，擅长 Web/App/PC 客户端漏洞挖掘。专注 API 安全、网关漏洞、微服务架构安全分析。本文基于公开 CVE 信息与技术原理深度复盘，供安全研究与防护参考。
一、漏洞时间线
2026 年 10 月，Apache 发布了 APISIX 的安全更新，修复了一个授权绕过漏洞 CVE-2026-94269。这个漏洞让攻击者能通过构造特殊编码的 URL 路径，绕过 API 网关的授权检查，直接访问受保护的后端服务。这是 API 网关安全领域的经典问题------当路由匹配和授权检查使用不同的路径规范化方式时，就会出现"路由匹配到宽松路由，但请求实际到达了受保护服务"的情况。
| 时间 | 事件 | 影响版本 |
|---|---|---|
| 2026-08-20 | APISIX 3.18.0 发布（引入 %2F 保留选项） | ------ |
| 2026-10-01 | NVD 收录 CVE | ------ |
| 2026-10-01 | Apache 发布安全公告 | APISIX 3.19.0 |
| 2026-10-02 | 安全社区公开技术分析 | ------ |
| 2026-10-05 | 各大安全媒体报道 | ------ |
这个漏洞最可怕的地方在于：它利用的是"非规范 URL 路径"------同一个路径，用不同的编码方式表示，网关和后端服务理解成了不同的东西。网关匹配到了一个不需要授权的宽松路由，但请求最终却到达了需要授权的受保护服务。在微服务架构中，API 网关是所有请求的入口------如果网关的授权检查被绕过，整个后端服务的安全防线就形同虚设。
二、攻击链全景
让我们先用一张流程图还原完整的攻击路径：
攻击者发现 API 网关路由配置有重叠
│
▼
第一步：环境探测
│ 攻击者做什么？
│ - 发现目标用了 Apache APISIX
│ - 分析路由配置
│ - 发现宽松路由和保护路由有重叠
│
│ 什么是路由重叠？
│ - 比如有一个 /api/* 的宽松路由
│ - 还有一个 /api/admin/* 的保护路由
│ - 两个路由的路径有重叠
│ - 如果配置不好就会出问题
▼
第二步：理解路径规范化差异
│ 关键问题在哪里？
│ - 网关路由匹配用一种路径规范化
│ - 后端服务用另一种路径规范化
│ - 同一个 URL 用不同编码
│ - 网关和后端理解成不同路径
│
│ 举个例子：
│ - 请求 /api/admin/data
│ - 编码成 /api%2fadmin/data
│ - 网关可能理解成 /api（宽松路由）
│ - 后端可能理解成 /api/admin/data（保护路由）
▼
第三步：构造恶意请求
│ 攻击者构造什么？
│ - 用 URL 编码特殊字符
│ - 让网关匹配宽松路由
│ - 让后端服务理解成保护路由
│
│ 怎么构造？
│ - 用 %2f 代替 /
│ - 用 %2e 代替 .
│ - 用其他编码方式混淆路径
│ - 让网关和后端理解不一致
▼
第四步：发送恶意请求
│ 攻击者发送请求：
│ - 请求路径是编码后的混淆路径
│ - 发给 API 网关
│ - 网关路由匹配
│
│ 网关怎么处理？
│ - 网关用自己的规范化方式解析路径
│ - 匹配到了宽松路由
│ - 宽松路由不需要授权
│ - 网关就放行了
│ - 没有做授权检查
▼
第五步：请求到达受保护服务
│ 网关把请求转发给后端：
│ - 后端服务收到请求
│ - 后端用自己的规范化方式解析路径
│ - 理解成了 /api/admin/data
│ - 这是受保护的接口
│
│ 问题在哪里？
│ - 网关已经放行，没有检查授权
│ - 后端服务以为网关已经检查过了
│ - 后端就直接处理请求了
│ - 攻击者就访问了受保护的接口
▼
攻击者绕过授权访问受保护服务
│
├─ 访问需要授权的接口
├─ 读取受保护的数据
├─ 操作受保护的资源
└─ 完全绕过网关的安全防线**关键结论：**这个漏洞的本质是"路径规范化不一致"------API 网关路由匹配和后端服务路径解析使用了不同的规范化方式，导致同一个请求被理解成不同的路径。在 API 安全中，路径规范化是最容易出问题的地方：URL 编码、特殊字符、路径遍历，这些都是经典的绕过手法。理解 URL 路径规范化、API 网关路由匹配、微服务授权模型，是做 API 安全的核心基本功。
三、API 网关与路径规范化原理
3.1 什么是 Apache APISIX
Apache APISIX 是一个云原生 API 网关：
| 组件 | 功能 |
|---|---|
| APISIX Gateway | API 网关 |
| 路由匹配 | 根据 URL 路径匹配后端服务 |
| 授权插件 | 认证、鉴权、限流等 |
| 上游服务 | 后端微服务 |
| 控制面 | 管理路由和配置 |
3.2 什么是路径规范化
路径规范化是把 URL 路径转换成标准形式的过程：
// 什么是路径规范化？
// URL 路径有很多种写法：
// - /api/user/info
// - /api/user/info/
// - /api//user/info
// - /api/./user/info
// - /api/user/../user/info
// - /api%2fuser/info
//
// 这些路径可能指向同一个资源
// 规范化就是把它们转换成标准形式
//
// 为什么会有问题？
// - 不同的系统可能用不同的规范化方式
// - 同一个路径在不同系统里可能理解成不同的东西
// - 这就是路径规范化不一致漏洞的根源
//
// 举个例子：
// - 路径 /api%2fuser/info
// - 网关可能把 %2f 当普通字符
// 理解成 /api%2fuser/info 一个路径段
// - 后端可能把 %2f 解码成 /
// 理解成 /api/user/info 两个路径段
// - 这就出问题了3.3 什么是路由重叠
路由重叠是 API 网关配置中的常见问题：
// 什么是路由重叠？
// 假设网关有两条路由：
//
// 路由 1（宽松）：
// - 路径：/api/*
// - 不需要授权
// - 转发到公开服务
//
// 路由 2（保护）：
// - 路径：/api/admin/*
// - 需要授权
// - 转发到管理后台
//
// 问题在哪里？
// - 两个路由的路径有重叠
// - /api/admin/* 也匹配 /api/*
// - 如果路由匹配顺序不对
// - 或者路径规范化有差异
// - 就会匹配到错误的路由
//
// 正常情况：
// - 请求 /api/admin/data
// - 应该匹配路由 2
// - 需要授权
//
// 漏洞情况：
// - 攻击者构造特殊编码的路径
// - 让网关匹配路由 1（宽松）
// - 但后端理解成 /api/admin/data
// - 就绕过了授权四、漏洞深度分析
4.1 漏洞根因：非规范 URL 路径
根据 NVD 和 Apache 安全公告，漏洞的根本原因是非规范 URL 路径：
// 有缺陷的逻辑（伪代码）
// API 网关处理请求：
// 1. 收到 HTTP 请求
// 2. 提取 URL 路径
// 3. 用自己的方式规范化路径
// 4. 匹配路由
// 5. 执行路由对应的插件（包括授权检查）
// 6. 把请求转发给后端
// 问题在哪里？
//
// 步骤 3 和步骤 6 之间：
// - 网关规范化后匹配路由
// - 转发时用原始路径或者另一种规范化
// - 后端服务用自己的方式规范化
// - 可能和网关的规范化不一致
//
// 结果是什么？
// - 网关匹配了路由 A（宽松，不需要授权）
// - 但后端理解成了路由 B（保护，需要授权）
// - 授权检查是在网关做的
// - 后端信任网关已经检查过了
// - 就直接处理请求了
// - 攻击者就绕过了授权4.2 %2F 编码的特殊问题
这个漏洞和 %2F 编码特别相关：
// 为什么 %2F 是关键？
// %2F 是 / 的 URL 编码：
// - 正常路径：/api/admin/data
// - 编码路径：/api%2fadmin/data
//
// 不同系统怎么处理？
//
// 有些系统：
// - 不把 %2f 解码成 /
// - 当成普通字符
// - /api%2fadmin/data 是一个路径段
//
// 有些系统：
// - 把 %2f 解码成 /
// - /api%2fadmin/data 变成 /api/admin/data
// - 是两个路径段
//
// 这就是问题所在：
// - 网关不把 %2f 当 /
// /api%2fadmin/data 匹配 /api/* 宽松路由
// - 后端把 %2f 当 /
// 理解成 /api/admin/data 保护路由
// - 就绕过了授权
//
// APISIX 3.18.0 甚至加了一个选项：
// - 可以保留 %2F 不被解码
// - 用于参数化路由匹配
// - 但这也加剧了路径规范化不一致的问题4.3 完整攻击链
从探测目标到完全访问受保护服务：
// 完整攻击步骤
// 前置条件：
// - 目标用了有漏洞的 Apache APISIX
// - 配置了宽松路由和保护路由的重叠
// - 网关和后端的路径规范化不一致
// 第一步：信息收集
// - 分析目标 API 网关
// - 确认用了 APISIX
// - 分析路由结构
// - 找到宽松路由和保护路由的重叠点
// 第二步：测试路径规范化
// - 发送各种编码的路径
// - 看网关和后端的响应差异
// - 确认路径规范化不一致
// 第三步：构造恶意请求
// - 用 %2f 编码特殊路径
// - 让网关匹配宽松路由
// - 让后端理解成保护路由
// 第四步：发送恶意请求
// - 把构造好的请求发给网关
// - 网关匹配到宽松路由
// - 跳过授权检查
// - 转发给后端
// 第五步：访问受保护服务
// - 后端理解成保护路由
// - 处理请求
// - 攻击者获得受保护的数据
// 第六步：横向移动
// - 用窃取的凭证
// - 访问更多内部服务
// - 进一步渗透4.4 影响范围
| 项目 | 详情 |
|---|---|
| CVE 编号 | CVE-2026-94269 |
| 漏洞类型 | 非规范 URL 路径授权绕过 |
| 影响产品 | Apache APISIX |
| 影响版本 | 2.14.1 - 3.18.0 |
| 利用条件 | 宽松路由和保护路由配置重叠 |
| 用户交互 | 不需要 |
| 漏洞根因 | 路径规范化不一致 |
| 影响 | 未授权访问受保护后端服务 |
| 修复版本 | APISIX 3.19.0 |
五、修复方案分析
Apache 在 2026 年 10 月修复了这个问题：
| 修复项 | 修复方式 |
|---|---|
| 路径规范化统一 | 路由匹配和转发用统一的规范化 |
| %2F 处理 | 正确处理编码的路径分隔符 |
| 路由匹配顺序 | 更精确的路由匹配 |
| 授权检查加强 | 授权检查基于最终路径 |
5.1 API 网关安全设计原则
// API 网关安全设计原则
// 1. 路径规范化统一
// 路由匹配和后端转发用同样的规范化方式
// 不要出现理解不一致
// 2. 授权检查前置
// 授权检查要在网关做
// 基于最终要访问的路径做检查
// 3. 路由配置审查
// 检查路由配置有没有重叠
// 避免宽松路由覆盖保护路由
// 4. 最小权限
// 路由配置遵循最小权限
// 不要用太宽泛的路由
// 5. 安全测试
// 定期测试路径绕过
// 检查各种编码方式5.2 API 网关安全检查清单
// API 网关安全检查清单
// 1. 路由配置
// 检查路由有没有重叠
// 宽松路由会不会覆盖保护路由
// 2. 路径规范化
// 检查网关和后端的规范化方式
// 有没有不一致的地方
// 3. 授权检查
// 确认授权检查基于正确的路径
// 不是基于错误的路由匹配
// 4. 编码处理
// 检查各种 URL 编码的处理
// %2f、%2e、%00 等特殊字符
// 5. 及时更新
// 及时更新网关版本
// 修复已知漏洞六、SRC 审计启示录
6.1 API 网关安全审计清单
在 SRC 挖洞过程中，针对 API 网关的审计清单：
| # | 检查项 | 检测方法 |
|---|---|---|
| 1 | 路由有没有重叠 | 分析路由配置，找宽松路由和保护路由 |
| 2 | 路径规范化有没有差异 | 测试各种编码路径的响应差异 |
| 3 | 授权检查能不能绕过 | 用编码路径尝试绕过授权 |
| 4 | %2f 等特殊编码有没有问题 | 测试 %2f、%2e 等编码的处理 |
| 5 | 路径遍历能不能打 | 测试 ../ 等路径遍历 |
6.2 常见 API 网关漏洞类型
// 常见的 API 网关漏洞
// 1. 路径规范化不一致
// 网关和后端理解成不同路径
// 绕过授权检查
// 2. 路由配置错误
// 宽松路由覆盖保护路由
// 未授权访问
// 3. 认证绕过
// JWT、OAuth 等认证机制有缺陷
// 绕过身份验证
// 4. 限流绕过
// 限流规则有问题
// 绕过限流限制
// 5. 配置泄露
// 网关管理接口暴露
// 泄露配置信息6.3 暴露面分级
| 暴露级别 | 情况 | 风险 |
|---|---|---|
| 严重 | 授权绕过 + 管理接口暴露 | 整个后端服务被控制 |
| 高 | 未授权访问敏感接口 | 敏感数据泄露 |
| 中 | 路径遍历访问有限制 | 部分数据泄露 |
| 低 | 信息泄露辅助攻击 | 降低攻击成本 |
七、防护建议
- 及时更新：升级到 Apache APISIX 3.19.0 或更高版本
- 路由审查：审查路由配置，避免宽松路由和保护路由重叠
- 路径规范化：确保网关和后端用统一的路径规范化方式
- 授权检查：授权检查要基于最终要访问的路径，不是错误的路由匹配
- 安全测试：定期测试路径绕过，检查各种编码方式
- 最小权限：路由配置遵循最小权限，不要用太宽泛的路由
八、总结
CVE-2026-94269 是 API 网关安全领域的经典问题------当路由匹配和授权检查使用不同的路径规范化方式时，授权绕过就成了必然。在微服务架构中，API 网关是所有请求的入口，也是安全防线的第一道。如果网关的授权检查被绕过，后面的所有服务都直接暴露在攻击者面前。在 API 安全领域，路径规范化是最容易出问题的地方------URL 编码、特殊字符、路径遍历，这些都是经典的绕过手法。在 SRC 挖洞实践中，API 网关是最常见的目标类型------一个授权绕过漏洞，往往能拿到最高等级的赏金。
