一、漏洞简介
CLIProxyAPI 存在一处内部接口未授权访问漏洞。在特定部署场景下，外部攻击者无需提供有效 API Key，即可直接调用 /v1internal:method 相关接口，进而造成模型能力被匿名滥用、资源消耗异常、上游 provider 配额与费用损失等安全风险。
该问题的核心原因包括：
/v1internal:method路由未纳入统一认证中间件保护；- 接口访问控制依赖
RemoteAddr == 127.0.0.1的本地来源判断； - 当服务部署于同机反向代理场景（如 nginx 与 CLIProxyAPI 位于同一台主机）时，公网请求被代理转发后，后端可能将请求来源识别为本机地址，从而导致鉴权绕过。
根据公开披露信息，该漏洞在常见的 nginx 同机反代 部署方式下可被触发。Issue #2445 中的评论给出了影响说明、PoC、测试记录、受影响配置场景和临时缓解方案。(github.com)
二、风险等级与评分
- 风险等级：高危
- CVSS v3.1（建议评分）：8.6 / 10.0
- 建议向量：
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
评分说明
该漏洞可通过网络远程利用，攻击复杂度低，不需要身份认证，也不需要用户交互。成功利用后，攻击者可直接调用模型相关内部接口，造成未授权资源消耗、服务滥用、上游计费损失，并可能触发进一步的内部转发能力调用。
这里的 CVSS 评分属于基于公开技术细节和典型部署影响的建议评分，用于安全通告和应急响应优先级参考。
三、漏洞简介
CLIProxyAPI 的 POST /v1internal:method 接口用于处理 Gemini CLI 相关内部调用。公开披露显示，该接口未像 /v1/* 与 /v1beta/* 一样接入统一鉴权中间件，而是通过请求来源地址是否为 127.0.0.1 来判定是否允许访问。
这一设计在“服务仅本地访问、无反向代理暴露”的理想条件下看似可行，但在同机反向代理部署场景中会失效：
外部攻击者请求先到 nginx，再由 nginx 转发到本机上的 CLIProxyAPI，后端看到的连接来源可能为本地回环地址，因此原本 intended 的“仅本机可访问”限制被绕过。
一旦后端已配置可用模型 provider，攻击者即可无需 API Key 直接调用内部模型接口，形成未授权调用与资源盗刷风险。(github.com)
四、漏洞影响产品
- 产品名称：CLIProxyAPI
- 项目仓库：
router-for-me/CLIProxyAPI - 受影响接口：
POST /v1internal:method- 可被利用的典型路径包括：
/v1internal:generateContent/v1internal:streamGenerateContent
五、版本信息
受影响版本
- 低于
v6.9.12的版本
修复版本
v6.9.12及以上版本
修复说明
公开信息显示，v6.9.12 的 release 已包含与该问题相关的安全修复说明，提交信息为：
adb580bfeat(security): add configuration to toggle Gemini CLI endpoint access
这表明项目已在 v6.9.12 中引入针对 Gemini CLI 端点访问控制的安全修复或缓解能力。(github.com)
修复版本表格
| 项目 | 信息 |
|---|---|
| 受影响产品 | CLIProxyAPI |
| 受影响版本 | < v6.9.12 |
| 修复版本 | >= v6.9.12 |
| 相关修复提交 | adb580b |
| 提交说明 | feat(security): add configuration to toggle Gemini CLI endpoint access |
六、受影响配置场景
该漏洞能否成功利用，与部署方式高度相关。
1. 高风险场景
以下场景存在较高风险：
- 使用 nginx 反向代理
- nginx 与 CLIProxyAPI 部署在同一台主机
- nginx 将外部请求转发至本机
127.0.0.1:<port>或等效本地监听地址 - 未在代理层显式拦截
/v1internal*路径 - 后端已配置可用的 provider 或模型调用能力
在上述条件下，外部请求经 nginx 转发后，后端应用可能将反代请求来源识别为 127.0.0.1，从而绕过“仅本机访问”的限制。
2. 低风险或不易利用场景
以下场景中通常较难直接利用：
- 服务未经过同机反向代理，而是直接暴露后端端口；
- nginx 与后端位于不同主机，后端看到的来源地址不再是
127.0.0.1； - 网关、WAF、Ingress 或反向代理层已主动拦截
/v1internal*； - 虽然接口可访问，但后端未配置可用 provider，因此调用无法真正执行。
七、漏洞成因分析
1. 路由未接入统一鉴权
公开披露指出，/v1internal:method 路由是直接注册在根引擎上的，没有像 /v1/* 和 /v1beta/* 一样使用统一认证中间件 AuthMiddleware 进行保护。
存在问题的注册方式示例如下：
// No AuthMiddleware — unlike /v1/* and /v1beta/* route groups
s.engine.POST("/v1internal:method", geminiCLIHandlers.CLIHandler)而正常受保护的路由则类似于：
v1 := s.engine.Group("/v1")
v1.Use(AuthMiddleware(s.accessManager))
v1beta := s.engine.Group("/v1beta")
v1beta.Use(AuthMiddleware(s.accessManager))这意味着 /v1internal:method 与正式 API 路由相比，缺失同等级别的身份认证保护。(github.com)
2. 依赖 RemoteAddr 的本地来源判断不可靠
评论中进一步指出，处理逻辑会检查 c.Request.RemoteAddr 是否为 127.0.0.1。这一方式在存在反向代理时并不可靠。
在 nginx 与应用同机部署时，真实公网客户端请求虽然来自外部，但经过 nginx 转发后，后端应用建立连接的对端实际上是本机上的 nginx 进程，因此看到的来源地址可能为 127.0.0.1。
这样一来，接口会错误地将外部请求判定为“本地请求”，从而允许继续访问。(github.com)
3. 根本原因总结
该漏洞本质上属于以下几类安全问题的组合：
- 内部接口缺失统一认证；
- 以来源地址代替身份认证；
- 错误信任反向代理后的网络边界；
- 内部接口在公网部署中被意外暴露。
八、漏洞复现
以下 PoC 仅用于授权测试、自查与应急验证，请勿用于未授权目标。
1. 复现条件
满足以下条件时，通常可以复现：
- 目标运行受影响版本的 CLIProxyAPI；
- 部署在 nginx 同机反向代理场景；
/v1internal*未在网关或代理层被拦截；- 后端已配置可用 provider。
2. 测试 PoC
无需 API Key，直接调用内部接口：
curl -X POST "https://<your-domain>/v1internal:streamGenerateContent" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.4",
"request": {
"contents": [{"role": "user", "parts": [{"text": "Say hi"}]}],
"generationConfig": {"maxOutputTokens": 10}
}
}'如果目标存在漏洞，可能直接返回模型输出，说明攻击者无需认证即可调用模型能力。(github.com)
3. 对照测试
正常受保护的接口在无有效 API Key 时应返回鉴权失败，例如：
curl -X POST "https://<your-domain>/v1/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer fake-key" \
-d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "hi"}]}'预期结果：
{"error":"Invalid API key"}如果普通接口返回 401 或鉴权错误，而 /v1internal:* 却可以返回正常模型结果，则基本可以确认存在未授权访问风险。(github.com)
没有反代的版本版本会提示：CLI reply only allow local access
v6.9.12 版本修复后会提示： Gemini CLI endpoint is disabled
九、测试记录
根据公开披露的测试结果，研究者对 5 个公网实例进行了验证：
| 实例 | 部署方式 | 是否绕过 IP 检查 | 模型调用结果 |
|---|---|---|---|
| Instance A | nginx 同机反代 | 是 | 成功，返回模型输出 |
| Instance B | nginx 同机反代 | 是 | 失败，无 provider 配置 |
| Instance C | nginx 同机反代 | 是 | 失败，无 provider 配置 |
| Instance D | 直接暴露，无反代 | 否 | 返回 403 |
| Instance E | nginx 异机反代 | 否 | 返回 403 |
测试结论
- 5 个样本中有 3 个 可以绕过本地来源校验；
- 至少 1 个实例 已达到完全可利用状态，可直接匿名调用模型；
- 是否造成实际资源盗刷，与目标实例是否配置可用 provider 密切相关。(github.com)
十、漏洞影响
该漏洞可能带来以下影响：
1. 未授权调用模型接口
攻击者无需提供有效 API Key，即可访问内部模型接口并发起调用。
2. 资源盗刷与费用损失
若后端对接了计费型模型或上游 provider，攻击者可以持续发起请求，造成：
- 额度消耗；
- 计费增长；
- provider 配额异常下降；
- 服务资源被第三方占用。
3. 服务被匿名滥用
攻击者可将受害实例作为匿名代理调用点，用于：
- 大量生成式请求；
- 流式输出请求；
- 批量模型调用；
- 规避其自身账号或 API Key 管控。
4. 潜在的更大内部攻击面
公开披露指出，除已验证的 /v1internal:generateContent、/v1internal:streamGenerateContent 外，其他 /v1internal:* 分支还可能直接转发至 cloudcode-pa.googleapis.com。这意味着其风险不止于简单的模型文本调用，还可能涉及额外的内部转发能力暴露。(github.com)
十一、如何修复
1. 立即升级到安全版本
建议受影响用户尽快升级到 v6.9.12 或更高版本。
该版本已公开说明包含与 Gemini CLI 端点访问控制相关的安全修复。(github.com)
2. 代码层修复建议
若暂时无法升级，可参考披露建议，对 /v1internal:method 路由增加统一鉴权中间件：
// Before (vulnerable)
s.engine.POST("/v1internal:method", geminiCLIHandlers.CLIHandler)
// After (fixed)
s.engine.POST("/v1internal:method", AuthMiddleware(s.accessManager), geminiCLIHandlers.CLIHandler)3. 修复原则
除直接补丁外，还建议遵循以下安全原则：
- 内部接口默认不应直接暴露到公网；
- 不要仅依赖
RemoteAddr判断“是否可信”； - 不要将“来自本机”视为“已经认证”；
- 若必须保留内部接口，应采用独立认证、访问白名单、内网监听或更严格的信任边界控制；
- 对所有
internal、admin、debug、management类路由进行统一审计。
4. 架构层加固建议
建议进一步采取以下措施：
- 将内部接口绑定到仅本地或内网可达的监听地址；
- 在反向代理层显式拒绝访问内部路径；
- 对反代后的真实客户端身份进行明确校验，而非仅使用 TCP 对端地址；
- 针对敏感接口引入单独令牌、mTLS 或管理平面专用入口。
十二、临时防御措施
如果暂时无法升级到修复版本，可优先采取以下缓解措施：
1. 在 nginx 层封禁 /v1internal*
location ~ ^/v1internal {
return 403;
}这是公开披露中明确建议的临时缓解方式，可直接阻断外部访问。(github.com)
2. 缩小暴露面
- 禁止公网直接访问内部接口；
- 检查 CDN、LB、Ingress、WAF 是否会将
/v1internal*转发到后端； - 仅保留必要对外 API，显式拒绝 internal 路径；
- 如果可能，将相关接口迁移到仅本地监听或管理平面专用端口。
3. 审计访问日志与账单
建议重点排查以下内容：
- 是否存在
/v1internal:generateContent、/v1internal:streamGenerateContent的公网访问日志； - 是否存在无认证头、伪造认证头或异常 User-Agent 的请求；
- 是否存在 provider 配额异常下降；
- 是否存在调用量、并发量、流式输出请求异常上升；
- 是否存在账单突增、令牌消耗异常等现象。
4. 必要时轮换凭据并临时停用 provider
虽然该漏洞不一定意味着密钥泄露，但若已发现异常调用，仍建议：
- 排查 provider 使用记录；
- 临时停用受影响实例的相关 provider；
- 视情况轮换认证凭据和上游配置；
- 在完成升级与验证后再恢复服务。
十三、自查方法
建议管理员按以下步骤自查：
- 确认当前版本是否低于
v6.9.12； - 检查是否启用了
/v1internal:method； - 检查该路由是否未使用统一鉴权中间件；
- 检查部署是否属于 nginx 与后端同机的反向代理模式；
- 从公网以无 API Key方式请求
/v1internal:streamGenerateContent； - 若接口返回模型结果而非鉴权失败，则说明存在风险；
- 进一步排查历史访问日志与 provider 消耗记录。
十四、时间线
| 时间 | 事件 |
|---|---|
| 2026-04-01 | Issue #2445 中已有用户反馈存在相关现象 |
| 2026-04-02 | 评论 #4174720882 公开披露漏洞成因、PoC、测试记录、影响场景及缓解建议 |
| 后续 | 项目发布 v6.9.12，release 说明包含 Gemini CLI 端点访问控制相关安全修复 |
| 当前 | 建议所有受影响用户尽快升级并排查历史访问情况 |
时间线中的 issue 评论与 release 信息均可从项目公开仓库信息中获得。(github.com)
十五、致谢
感谢安全研究人员 Dismantle0488 在 Issue #2445 的评论 #4174720882 中公开披露该问题的技术细节、影响说明、复现方式、测试结果以及缓解建议，为受影响用户及时处置风险提供了重要参考。(github.com)
同时也感谢项目维护者对相关问题进行处理和发布修复版本。
十六、参考信息
- 项目 Issue：
router-for-me/CLIProxyAPI#2445 - 关键披露评论：
#4174720882 - 修复版本：
v6.9.12 - 相关修复提交：
adb580b
