浏览器打开 IP:11434/api/tags 就能看到模型列表，说明 Ollama 对公网裸奔。它默认无认证，而 CVE-2024-37032 让这件事从白嫖模型升级成接管机器。
只要在浏览器里打开 http://你的IP:11434/api/tags，就能直接看到这台机器上有哪些模型——这就是典型的 Ollama 未授权访问。它默认没有认证，而 CVE-2024-37032 让这件事从「模型被白嫖」升级成「整台机器被接管」。
这篇给出原理、3 条自查命令和加固清单，不提供利用代码。
怀疑 11434 暴露
│
▼
curl <目标IP>:11434/api/tags
│
┌────┴─────┐
返回模型列表 超时 / 401
│ │
已暴露 安全
│
ollama --version + ss -ltnp | grep 11434
│
├─ 低于 0.1.34 → 升级
└─ 监听 0.0.0.0 → 改 127.0.0.1
↓
反代认证 + 防火墙兜底
两条默认值决定了风险
| 部署方式 | 默认监听 | 风险 |
|---|---|---|
| Linux 直接安装 | 127.0.0.1:11434 | 低，本机可访问 |
| Docker 容器 | 0.0.0.0:11434，容器内 root | 高，公网可直接打 |
Wiz 研究团队扫描公网时发现超过 1000 个暴露的 Ollama 实例，其中包含私有模型。这不是理论风险。
受影响版本：低于 0.1.34。
这个洞是怎么形成的
Ollama 有一个 /api/pull 接口，用来从模型仓库拉取模型。默认从官方仓库拉，但也允许指定私有仓库。
问题出在拉取时对清单文件（manifest）的校验上。
清单里每一层都有一个 digest 字段，本应是 64 位十六进制的 SHA256 值。Ollama 用这个值拼出文件在磁盘上的存放路径：
/root/.ollama/models/blobs/sha256-<digest>
漏洞版本没有校验 digest 的格式。攻击者在自己控制的仓库里放一份清单，把 digest 写成 ../../../../../../etc/ld.so.preload 这样的路径，服务端拼路径时就会跳出模型目录，写到系统任意位置。
ld.so.preload 是动态链接器的预加载配置：里面列出的共享库，会在每个新进程启动时被加载。所以完整链条是：
- 通过路径穿越，把一个恶意
.so文件写到磁盘 - 再通过同一手法改写
/etc/ld.so.preload，指向这个.so - 调用
/api/chat，服务端派生新进程，恶意库被加载
**最终效果是远程代码执行。**Docker 部署下服务以 root 运行，所以直接是 root 权限。
Wiz 在 2024 年 5 月 5 日报告，Ollama 当天提交修复，5 月 8 日发布 0.1.34，6 月 24 日公开细节。
3 条命令查自己有没有中招
第一条：看版本
ollama --version
预期输出类似 ollama version is 0.1.34。
判读：低于 0.1.34 就要升级。看不到版本号说明命令不在 PATH 里，或者这是个纯客户端。
Docker 部署用这条：
docker exec <容器名> ollama --version
第二条：看监听地址
ss -ltnp | grep 11434
预期输出：
LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:* users:(("ollama",pid=1234,fd=3))
判读看第二列：
127.0.0.1:11434→ 只监听本机，外网打不进来0.0.0.0:11434或*:11434→ 对所有网卡开放，需要立刻处理
第三条：从外网验证是否真的暴露
在另一台机器上执行：
curl -s --max-time 5 http://<目标IP>:11434/api/tags
预期结果：
- 超时或连接被拒 → 没有暴露
- 返回一段 JSON，里面有
models列表 → 已暴露，任何人看到的内容和你一样
这条最值得做，因为配置文件写的和实际生效的经常不一致。
加固：四层，从便宜到彻底
第一层：能升级就升级
curl -fsSL https://ollama.com/install.sh | sh
预期：脚本跑完，ollama --version 显示新版本。
0.1.34 修的是路径穿越本身。但如果版本已经比较新，仍要继续看下面几层——认证缺失不是漏洞，是设计，官方文档明确说要靠反向代理补。
第二层：只监听本机
systemd 部署，改服务配置：
systemctl edit ollama
在打开的编辑器里写：
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
保存后：
systemctl daemon-reload
systemctl restart ollama
预期：重启后 ss -ltnp | grep 11434 显示 127.0.0.1。
注意：这一改，局域网里其他机器也访问不到了。本来就是要给局域网用的话，改成内网网卡地址，不要用 0.0.0.0。
第三层：前面挂一层带认证的反向代理
Nginx 加 Basic Auth 或接入现有 SSO。核心是：外部请求必须带凭据才能到 11434。
第四层：防火墙兜底
ss -ltnp | grep 11434
只放开确实需要访问的来源 IP。云服务器同时检查安全组——很多人 Nginx 配好了，安全组还开着 0.0.0.0/0。
怎么确认加固生效
按顺序验收，三条都过才算完：
ss -ltnp | grep 11434不再出现0.0.0.0- 从外网
curl http://<IP>:11434/api/tags超时或 401 - 本机
curl http://127.0.0.1:11434/api/tags正常返回模型列表
第 3 条不能少。只做到「外网打不开」但自己也不能用，那是配错了。
为什么这类问题反复出现
推理服务这一类工具，设计目标都是「让开发者三分钟跑起来」，所以默认值是方便优先：不开认证、绑所有网卡、容器里给 root。
问题在于，很多人把它当生产服务部署，默认值却还留在开发模式。
同类问题不只在 Ollama 出现过。Wiz 此前在 Hugging Face、Replicate 上发现过类似风险，TorchServe 和 Ray 也出过可远程利用的洞。共同点不是某个 CVE，是这些工具默认不设防。
所以自查的重点不该只盯版本号，还要看：这东西到底该不该暴露在公网上。
先看版本，再看监听地址
ollama --version 低于 0.1.34 的，先升级；ss -ltnp 里是 0.0.0.0 的，先改监听。两条都做完，再谈模型效果。
漏洞细节与时间线引自 Wiz Research 公开披露（CVE-2024-37032，代号 Probllama）。本文只讲原理、自查与加固，不含利用代码。
