cpa漏洞复现小记

问题描述：

https://linux.do/t/topic/1892136
https://linux.do/t/topic/1892269
前面冲浪的时候看到了cpa有漏洞，马上复线了一下

漏洞原理

CPA 的 /v1internal:generateContent 和 /v1internal:streamGenerateContent 端点：
不需要 API Key — 路由没有经过 AuthMiddleware
仅靠 RemoteAddr 检查 — strings.HasPrefix(c.Request.RemoteAddr, “127.0.0.1:”)
反向代理绕过 — nginx/cloudflared 转发流量时，TCP 连接来自 127.0.0.1，检查无效
直接使用服务器凭据 — 通过 ExecuteWithAuthManager 使用 CPA 服务端存储的 OAuth 凭据

测试脚本

已删除

docker bridge不受影响原理

Docker 默认使用 bridge 网络（docker0 网桥，网段通常是 172.17.0.0/16）。即使 nginx proxy_pass http://127.0.0.1:8317，流量实际经过了这样的路径：

nginx 连接宿主机的 127.0.0.1:8317
宿主机上的 docker-proxy 进程监听了这个端口（-p 8317:8317）
docker-proxy 新建一个 TCP 连接到容器的内部 IP（如 172.17.0.2:8317）
这个新连接的源 IP 是 docker 网桥网关 172.17.0.1，不是 127.0.0.1
所以 CPA 容器内看到的 RemoteAddr 是 172.17.0.1:xxxxx：

// gemini-cli_handlers.go:52
if !strings.HasPrefix(c.Request.RemoteAddr, “127.0.0.1:”) {
// “172.17.0.1:xxxxx” 不以 “127.0.0.1:” 开头
// → 返回 403 Forbidden ← 攻击被拦截
}

避免措施

参考的帖子里有说 “如果是Docker部署，映射端口到宿主，nginx通过docker-proxy访问CPA则不会有问题
前面套了一层newapi的话也不会有问题”

老师们有类似情况赶紧修改。

网友解答：

---

--【壹】--：

很巧妙的利用漏洞

---

--【贰】--：

cpa端口没映射出去，容器内部由nginx访问cpa容器名，cpa监听0.0.0.0还会出现这个问题吗

---

--【叁】--：

这么强！

---

--【肆】--：

resp.text '{"error":{"message":"CLI reply only allow local access","type":"forbidden"}}'

还好还好

---

--【伍】--：

打算缓存sub2api了，cpa自己的性能占用和账号策略都不太行

---

--【陆】--：

CPA就一个team，另一个就4个免费号。还好，盗了也关系不大

---

--【柒】--：

Docker 默认使用 bridge 网络（docker0 网桥，网段通常是 172.17.0.0/16）。即使 nginx proxy_pass http://127.0.0.1:8317，流量实际经过了这样的路径：

nginx 连接宿主机的 127.0.0.1:8317
宿主机上的 docker-proxy 进程监听了这个端口（-p 8317:8317）
docker-proxy 新建一个 TCP 连接到容器的内部 IP（如 172.17.0.2:8317）
这个新连接的源 IP 是 docker 网桥网关 172.17.0.1，不是 127.0.0.1
所以 CPA 容器内看到的 RemoteAddr 是 172.17.0.1:xxxxx：

// gemini-cli_handlers.go:52
if !strings.HasPrefix(c.Request.RemoteAddr, “127.0.0.1:”) {
// “172.17.0.1:xxxxx” 不以 “127.0.0.1:” 开头
// → 返回 403 Forbidden ← 攻击被拦截
}

---

--【捌】--：

最新版6.9.12已修复 更新下

---

--【玖】--：

cpa不暴露端口，跟traefik同一个bridge网络，通过traefik反代会有漏洞吗

---

--【拾】--：

佬，这是什么原理呢？为什么通过docker就不会有问题