New-API 惊现“反向充值”漏洞？赶紧排查你的中转站计费逻辑

👋 大家好，今天不聊羊毛，聊聊一个让站长们“后背发凉”的技术瓜。

最近，圈子里非常流行的 New-API 项目（也就是很多大佬用来做中转、做二销的一站式解决方案）悄咪咪地修复了一个超级严重的 Bug。如果你正好在用这个项目搭中转站卖 API，或者自己挂着给团队用，那这事儿你必须得知道，否则你的账单可能会出现灵异现象——余额不仅没扣，反而越用越多！

别笑，这是真事。咱们今天就以此为题，扒一扒这个“反向充值”漏洞到底是个什么鬼，以及我们该怎么办。

🔴 什么是“计费回绕”？

事情起因是 QuantumNous/new-api 项目官方提交了两个紧急修复提交。简单来说，这个漏洞的核心在于：边界校验缺失导致的整数溢出（Integer Overflow）。

咱们都知道，计算机里的数字存放在内存里是有上限的。如果在一个有限的容器里硬塞进一个超过它能表示的最大值，比如在 32 位整数里塞进一个天文数字，它会因为“溢出”而从头开始计数，瞬间变成一个巨大的负数。

在 New-API 的旧版本逻辑里，计费系统计算 quota（配额）时，没有对用户可控的参数（比如某些超大的上下文长度、或者构造的超长 Token 参数）进行严格的边界限制。

于是出现了这一幕：

1. 用户（或者说攻击者）构造了一个包含超大数值的请求。
2. 系统拿来算钱：单价 × 超大参数。
3. 结果过大，整数溢出，计算结果变成了一个负数。
4. 系统傻乎乎地执行：当前余额 = 当前余额 - (负数)。
5. 数学告诉我们，减去负数等于加上正数。
6. 恭喜你，触发“反向充值”特效，账户余额蹭蹭往上涨！

对于站长来说，这简直就是噩梦。一旦被恶意利用，别人不仅能免费白嫖你的高阶模型额度，甚至能把你的账户余额刷成天文数字，搞崩你的财务逻辑和上游结算。

🛠️ 官方怎么修的？

既然问题发现了，修复方案也就比较直接了。官方主要做了两件事，大家升级的时候可以留意一下代码细节：

1. 增加了参数上限校验 这是最直接的“堵枪眼”办法。在参数进入核心计费逻辑之前，先设立一道关卡。凡是超过预设合理范围（比如单次请求 Token 数不能超过某个极大值）的参数，直接拒绝请求，报错返回。从源头掐断溢出的可能。

2. 引入饱和转换（Saturation Arithmetic） 这个是比较高级的处理。在涉及 quota 计算的核心乘法逻辑里，引入了防止回绕的机制。简单说，就是告诉程序：“如果算出来的数太大要溢出了，那就别溢出成负数了，直接给我定格在最大值。”

这样就避免了 Max + 1 = Min 的尴尬局面，保证扣除的额度永远是正数（或者是 0），最坏情况也就是这次请求不让你用了，绝对不会让你赚到钱。

官方还很细心地把其他可能绕过类型检查的入口都补齐了边界检查，防止有人通过其他接口传入超大数字来搞预扣费或结算破坏。

⚠️ 给站长的排查建议

不管你是用 New-API 自建的中转，还是用的类似的二次开发项目，赶紧按照下面这几步自查一下：

1. 立即升级版本 如果你的代码还是几天前的旧版，赶紧去拉取最新的提交。这次修复涉及到底层计费逻辑，属于安全更新，优先级拉满。

2. 检查日志中的异常扣费 去翻翻服务器日志，看看有没有出现过 quota 变成负数的情况，或者有没有那种请求参数大得离谱但竟然返回成功的记录。

3. 上游账单核对 虽然你自己本地显示的余额可能因为漏洞没扣，但是你调用的上游（比如 OpenAI 或 Azure）可是实打实扣了钱的。赶紧核对一下上下游账单是否平衡，别亏大了才发现。

4. 代码审计（如果是自研版） 如果你魔改过 New-API 的计费模块，检查一下自己的代码里有没有类似的乘法运算。记住一条铁律：凡是跟钱有关的计算，一定要做异常值和溢出保护！

💡 总结

这个漏洞虽然听起来有点“薅羊毛”的快感，但对于运营者来说就是纯纯的“核弹”。它再次提醒我们，在涉及金融、计费等敏感逻辑时，永远不要信任用户输入的任何参数。

New-API 这次反应还算挺快，修复也比较彻底。大家抓紧时间更新，守好咱们的余额小金库！

如果你觉得这篇内容有用，记得点个赞，避坑路上不迷路~