两万星开源项目被攻破：一个引号偷走全部AI密钥

4月24日，全球GitHub漏洞数据库刚录入一条新记录。36小时零7分钟后，第一批攻击流量就已经撞上了企业的LiteLLM网关。攻击者甚至懒得用扫描器——他们直接翻出了这个2.2万星项目的内部表结构，精准定位存放密钥的三张表。

LiteLLM是什么，为什么值得偷

LiteLLM是一个开源AI网关，GitHub星标超过2.2万。它的核心功能很简单：帮企业统一管理对OpenAI、Anthropic、AWS Bedrock等大模型服务的调用。

企业接入多个AI供应商时，需要处理不同的API格式、密钥管理和计费统计。LiteLLM充当中央代理，把所有这些复杂性收拢到一个入口。员工只需要向LiteLLM发请求，后端路由、负载均衡、成本追踪都由它自动处理。

正因为这个定位，LiteLLM的数据库里存着极具价值的东西：主API密钥、企业云凭证、虚拟密钥、环境配置。Sysdig威胁研究团队的原话是，一次成功入侵的"爆炸半径更接近大规模云账户泄露，而非典型的Web应用攻击"。

换句话说，攻破LiteLLM不等于攻破一个应用，等于拿到了企业整个AI基础设施的万能钥匙。

漏洞原理：一个引号绕过所有认证

漏洞编号CVE-2026-42208，存在于代理的验证流程中。具体来说，LiteLLM没有安全处理Authorization Bearer请求头。

攻击手法极其简单：在伪造的token里插入一个单引号，比如sk-litellm'。这个引号让攻击者跳出原本的数据库查询结构，在认证发生之前就执行任意SQL命令。

任何能访问代理端口的HTTP客户端都能发起攻击。不需要账号，不需要密码，不需要任何前置条件。

Sysdig团队检测到的攻击流量显示，入侵者没有使用噪音很大的自动化扫描工具。相反，他们展现出对LiteLLM内部结构的深度了解——直接瞄准三张特定表：LiteLLM_VerificationToken、litellm_credentials、litellm_config。

这三张表分别存储虚拟API密钥、供应商凭证和环境配置。攻击者甚至调整了payload的大小写，精确匹配数据库的实际schema。这种精细程度说明他们不是随机试探，而是有备而来。

所有攻击来自两个IP地址（65.111.27.132和65.111.25.67），属于同一自治系统。这是典型的协调化、目的明确的数据提取作业。

时间线：从公开到被利用，不到两天

4月24日，漏洞被录入全球GitHub安全公告数据库。

36小时7分钟后，首次利用尝试出现。

这个速度在漏洞利用时间轴上属于第一梯队。作为参照，2021年Log4j漏洞（Log4Shell）的首次大规模利用出现在公开后约48小时。LiteLLM这次更快。

差异可能在于目标价值。Log4j影响面极广但单点价值分散；LiteLLM部署量小得多，但每个实例都是密钥聚宝盆。攻击者显然做了成本收益计算：放弃广撒网，专注高价值目标。

受影响版本范围是1.81.16到1.83.6。维护团队已发布1.83.7修复版本，核心改动是正确加固数据库查询。

企业现在该做什么

官方建议分三层。

第一层，打补丁。运行受影响版本的企业必须立即升级到1.83.7。

第二层，做最坏的假设。由于攻击无需认证即可对任何暴露实例执行，管理员应默认面向互联网的脆弱服务器已被入侵。

第三层，全面轮换。所有虚拟API密钥、主密钥、存储的供应商凭证必须立即更换。同时监控上游云计费账户，查找异常API调用或未授权的AI token消耗。

日志审计方面，重点排查包含SQL关键词或sk-litellm'payload的可疑请求。

AI网关正在成为新的密钥仓库

这个案例暴露了一个正在形成的架构风险。

企业AI应用爆发式增长，但直接管理十几个不同供应商的API密钥、计费接口和权限策略，对大多数团队来说是不现实的。AI网关应运而生，把复杂性收敛到单一控制点。

这个设计选择有其合理性。但这也意味着，网关本身成为超级高价值目标——攻破一点，泄露一片。

传统安全思维中，数据库凭证泄露是严重事件，但通常只影响该数据库内的数据。AI网关的特殊性在于，它存储的凭证本身就是通往外部高价值资源的钥匙。PostgreSQL里的一行记录，可能直接对应AWS账户的完全访问权限或OpenAI企业级API的无限额度。

攻击者的时间投入也说明了这一点。他们没有用现成扫描器批量撒网，而是专门研究LiteLLM的代码结构，编写定制化payload，精准提取三类核心数据。这种"外科手术式"攻击的成本远高于自动化蠕虫，但单点回报也高得多。

从防御角度看，这提出了一个棘手的问题：如何给一个"必须暴露在网络边缘以提供服务"的系统，提供等同于内部核心数据库的保护级别？

LiteLLM的漏洞本身是个经典SQL注入——这类问题理论上早该灭绝。但它的存在位置（认证前处理逻辑）和攻击后果（直接泄露云凭证而非应用数据），让传统Web应用防火墙的防护模型显得不够用了。

安全团队可能需要重新评估AI网关的架构位置。把它简单视为"又一个API服务"会低估风险；把它与核心身份基础设施并列管理，又可能过度增加运维负担。平衡点在哪里，目前行业还没有标准答案。

维护团队在1.83.7中的修复方式是"正确保护数据库查询"——这暗示原始代码可能存在字符串拼接SQL或不当的参数化处理。对于一个2.2万星的项目，这种基础层面的疏忽值得社区反思：开源项目的安全审计资源，是否与其实际部署的价值密度匹配。

最后，攻击者选择的时机也值得关注。漏洞公开后36小时即启动精准打击，说明他们建立了对主流安全公告渠道的实时监控，并且具备快速武器化能力。对于企业安全运营而言，"补丁窗口期"正在以小时为单位收缩，传统的周级别更新节奏可能已经不再适用。

LiteLLM的命名有个巧思：Lite（轻量）+ LLM（大语言模型）。但这次事件证明，轻量的架构设计不等于轻量的安全责任。当一个项目成为企业AI基础设施的枢纽，它的每一行代码都承载着与重量相匹配的风险。