New-API 高危漏洞暴露 AI 中转站生态隐患：从充值伪造到代理层安全失守

在大模型应用快速扩张的当下，“AI 中转站”类项目正成为开发者连接多模型服务的重要基础设施。然而，开源项目 New-API 近期曝出的高危漏洞，再次为这一生态敲响警钟：一旦代理层失守，风险将直接传导至计费体系与资源滥用层面。

据披露，该漏洞允许攻击者伪造任意金额的充值请求，绕过正常支付逻辑。这类问题不仅影响单一站点的经济模型，更可能波及整个基于 API 转发的 AI 服务链路。

漏洞本质：计费链路中的信任断点

New-API 作为一个典型的 AI 中转站项目，其核心职责包括：

• 聚合多个大模型 API（如 OpenAI、Claude、Gemini 等）
• 提供统一的调用入口（如 POST /v1/chat/completions）
• 实现用户鉴权、配额控制与计费结算
• 支持余额充值与调用扣费

本次漏洞的关键问题，在于充值逻辑缺乏有效校验，导致攻击者可以构造请求直接修改账户余额。这意味着：

• 资金系统未正确验证支付回调或签名
• 后端对“充值成功”状态的信任来源存在缺陷
• 业务逻辑与安全校验未形成闭环

从架构角度看，这是典型的“业务层信任边界错误”，而非底层模型或推理系统问题。

为什么 AI 中转站更容易成为攻击面？

相比传统 Web 应用，AI 中转站具有一些独特特征，使其更容易成为高价值攻击目标：

1. 计费与调用强绑定

模型调用直接消耗成本（token 计费），一旦余额可被伪造，攻击者可以无限调用高价模型资源。

2. 多上游依赖

中转站通常代理多个模型厂商 API，一旦被滥用，真实费用由站长承担，形成“成本放大器”。

3. 开源项目快速部署

New-API 等项目降低了搭建门槛，但也意味着：

• 部署者安全经验参差不齐
• 默认配置可能不具备生产级安全策略
• 更新滞后导致漏洞暴露窗口变长

4. 缺乏成熟风控体系

相比支付平台或云厂商，多数 AI 中转站缺少：

• 异常充值检测
• 调用行为风控
• 限流与审计机制

已修复，但风险未结束

目前该漏洞已在 v0.12.10 版本中修复。对于已部署 New-API 的开发者或站长而言，升级只是第一步，更关键的是事后审计与风险控制：

• 检查近期充值订单，重点关注异常金额或非正常来源请求
• 核对余额变动日志，排查是否存在“无支付凭证”的充值记录
• 审计 API 调用量，识别是否存在异常高频或突增行为
• 回溯访问日志，定位可能的攻击入口

如果仅升级而不审计，很可能遗漏已经发生的资源滥用或经济损失。

技术反思：AI 基础设施正在进入“安全敏感期”

New-API 漏洞的出现，并非孤立事件，而是 AI 工程体系发展阶段的缩影。

随着大模型从实验走向生产，AI 基础设施逐渐呈现出以下特征：

• 服务化程度提升：统一 API 层成为核心入口
• 资源成本显性化：每次调用都对应真实支出
• 代理架构普及：中转层成为关键控制点

这也意味着，安全问题从传统的“数据泄露”，扩展到“资源滥用”和“经济攻击”。

给开发者的实践建议

从工程角度看，类似问题可以通过以下方式降低风险：

强化支付与充值链路

• 所有充值必须基于可信支付回调（如签名验证）
• 避免客户端直接控制充值结果
• 引入订单状态机（pending → paid → credited）

引入多层校验机制

• 服务端校验金额、订单号与用户绑定关系
• 对关键操作增加幂等性检查

构建基础风控能力

• 设置调用频率限制（rate limiting）
• 对异常余额增长触发告警
• 引入简单的行为分析（如突发高消费）

做好日志与审计

• 保留完整充值与调用日志
• 支持按用户/时间维度回溯

结语：AI 工具链的“最后一公里”，往往是最脆弱的一环

在大模型能力不断提升的同时，围绕其构建的工具链与基础设施，正在成为新的风险集中区。New-API 的这次漏洞，提醒开发者关注一个现实问题：真正决定系统可靠性的，往往不是模型本身，而是围绕它的工程实现细节。

当 AI 从“调用接口”走向“承载业务”，安全与稳定性不再是附加项，而是系统设计的前提。