🟠 高危 | CVE-2026-65604 — Skipper contains an incomplete fix for CVE-2026-50...
🟠 【深度分析】高危安全漏洞：CVE-2026-65604
CVSS 评分: 高危（8.8）🟠 状态: Received 发布时间: 2026-07-23
🔍 技术细节速览
| 字段 | 值 |
|---|---|
| CVE ID | CVE-2026-65604 |
| CVSS 评分 | 8.8 🟠 |
| 严重程度 | 高危 |
| CVSS 向量 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X |
| CWE 分类 | CWE-20 |
| 发布时间 | 2026-07-23 |
| 最后更新 | 2026-07-24 |
| 状态 | Received |
| 数据来源 | disclosure@vulncheck.com |
好的，以下是根据您提供的 NVD 数据生成的深度安全分析文章。
CVSS 评分：8.8（高危）
CVSS 向量（v4.0）：AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N
关键解读： 攻击者可远程、低复杂度、无需任何权限与用户交互即可利用。漏洞直接导致机密性高损失（VC:H），完整性低损失（VI:L），无需特殊条件或时间窗口。
漏洞概述
CVE-2026-65604 是 Skipper HTTP 路由/代理组件中因输入验证不完善导致的访问控制绕过漏洞。该漏洞源于对先前 CVE-2026-50197 的不完整修复：当请求体（request body）大小超过 Skipper 配置的 maxBodyBytes 限制时，Skipper 仍将完整的原始载荷转发给上游服务，而 Open Policy Agent（OPA）策略评估引擎收到的却是空解析体（parsed_body）。这使得依赖请求体内容做“拒绝-即阻断”（deny-on-presence）的 Rego 策略完全失效，攻击者可以绕过授权检查，执行本应被禁止的操作。
目前官方尚未发布修复版本，仅于 v0.27.26 中新增了文档说明（非代码修复），风险较高。
受影响组件与版本
| 组件 | 受影响版本范围 |
|---|---|
| Skipper | ≤ v0.27.26（含此版本） |
| OPA 集成模块 | 所有使用 maxBodyBytes 限制且依赖 parsed_body 进行策略评估的版本 |
注意： 任何使用 Skipper 作为反向代理并启用 OPA 授权（特别是基于请求体内容拒绝策略）的部署均受影响。即使配置了
maxBodyBytes，攻击者仍能通过发送超大请求体绕过 OPA 检查。
漏洞原理分析
1. 背景：Skipper + OPA 的请求授权流程
Skipper 作为 HTTP 代理，可集成 OPA 进行请求级授权。典型流程如下：
- 客户端发送 HTTP POST/PUT 请求（含 JSON/XML 等 body）。
- Skipper 根据
maxBodyBytes配置限制 body 大小；若 body 超出限制，Skipper 不再解析 body 内容（parsed_body置空或丢弃），但为了不影响上游服务，仍将原始 body 转发给后端。 - 同时 Skipper 调用 OPA 策略引擎，传入请求属性（包括
parsed_body——此时为空）进行决策。 - OPA 根据 Rego 规则判断是否允许请求。若规则基于 body 中特定字段（如
{"action": "delete"}）拒绝请求，则由于收到的parsed_body为空，该条件不成立，策略默认放行。
2. 漏洞成因
CVE-2026-65604 本质是 CVE-2026-50197 的不完整修复。原始漏洞可能是绕过 OPA 策略的其他方式，修复后引入了新的绕过路径：当 body 大小超过 maxBodyBytes 时，解析模块与转发模块行为不一致。
- 解析模块：因超限放弃解析，
parsed_body= nil。 - 转发模块：未做截断或丢弃，直接将原始 body 发送至上游。
这导致 OPA 评估结果与实际执行动作“脱钩”。攻击者只需构造一个超大 body（例如填充无意义数据使总大小 > maxBodyBytes），就能让 OPA 认为请求 body 为空，从而绕过任何基于 body 内容的 deny 规则。
3. 攻击向量
- 前提条件：Skipper 配置了
maxBodyBytes且启用了基于parsed_body的 OPA 拒绝策略。 - 攻击方式：发送一个远超
maxBodyBytes的 HTTP 请求（如 POST /api/resource），body 中包含恶意操作指令（如{"cmd": "delete_all"}）。 - 效果：OPA 因
parsed_body为空未检测到拒绝条件，请求被允许；上游服务器收到完整 body 并执行恶意操作。
影响评估
| 评估维度 | 分析结果 |
|---|---|
| 攻击复杂度 (AC:L) | 低——只需发送超大 HTTP 请求，无需特殊工具或前提条件。 |
| 攻击向量 (AV:N) | 网络——可远程利用。 |
| 权限要求 (PR:N) | 无——无需认证或会话。 |
| 用户交互 (UI:N) | 无——无需受害者操作。 |
| 机密性影响 (VC:H) | 高——利用后攻击者可读取、删除或修改受保护资源。 |
| 完整性影响 (VI:L) | 低——攻击可破坏部分数据或配置，但通常无法完全控制系统。 |
| 可用性影响 (VA:N) | 无——不直接导致服务崩溃。 |
| 利用难度 | 极低——仅需构造 body 大小超过阈值即可触发。即使不知道具体策略，也可通过枚举绕过。 |
潜在后果：
- 绕过租户隔离、权限校验，执行未授权操作（如删除数据库记录、修改配置、越权获取数据）。
- 若上游服务对 body 无大小限制，且依赖 OPA 作为唯一安全层，则整个授权体系失效。
修复建议
官方状态
截至报告发布日（2026-07-23），Skipper 官方未提供补丁。v0.27.26 仅增加了文档指导，提醒用户注意此行为风险，但未修改代码逻辑。
推荐措施
1. 立即缓解（可选方案）
- 禁用
maxBodyBytes或将其调至足够大（非常危险，仅适用于可信任网络环境）。 - 在 OPA 策略中增加附加校验：除
parsed_body外，同时检查request.body原始数据（若 Skipper 提供该字段）。某些版本可通过input.request.http.body获取原始 body 的 base64 编码，但需注意超大 body 的内存占用。 - 在应用层（上游服务）实施独立的 body 大小校验和内容过滤，作为防御纵深。
2. 临时缓解（推荐）
- 使用反向代理前置（如 Nginx、Envoy） 在到达 Skipper 之前对 body 大小进行强制限制，拒绝超标请求。这样 OPA 永远不会见到超大请求，从而避免此绕过。
client_max_body_size 1m; # 根据业务设置合理阈值 - 修改 OPA 策略逻辑，不使用
parsed_body做唯一判断依据，而是结合其他请求属性（如 URL、方法、Header）做决策。对于仅靠 body 内容拒绝的规则，可考虑将这些规则移至上游服务内部。
3. 长期方案
- 关注 Skipper 项目更新，等待官方修复（预计会统一解析与转发行为，如超出
maxBodyBytes时直接拒绝请求而不再转发）。 - 参与社区讨论，推动 CVE-2026-65604 的完整修复。
参考资料
| 来源 | 链接 |
|---|---|
| NVD 官方页面（CVE-2026-65604） | https://nvd.nist.gov/vuln/detail/CVE-2026-65604 |
| 相关 CWE（输入验证不当） | https://cwe.mitre.org/data/definitions/20.html |
| CVE-2026-50197（原漏洞） | NVD 暂未收录，可关注 Skipper 官方安全公告 |
| Skipper 项目主页 | https://github.com/zalando/skipper |
| OPA 官方文档 | https://www.openpolicyagent.org/docs/latest/ |
| VulnCheck 披露 | 来源：disclosure@vulncheck.com |
免责声明： 本文基于 NVD 公开数据分析撰写，部分技术细节为合理推断，实际漏洞原理请以官方补丁附带的变更日志为准。建议用户尽快评估自身受影响的范围，并实施上述缓解措施。