扫到一条挺别扭的漏洞：LMCache 的 CVE-2026-105192，CVSS 9.8，未授权 RCE。别扭的地方在于——公告挂出来的时候，没有修复版本。
LMCache 是干什么的先说一句，因为不少人是从"我好像在哪儿见过这个名字"开始的：它给大模型推理做 KV cache，把已经算过的注意力缓存下来，下次直接复用，省显存也省时间。它一般挂在推理服务和存储之间，本身是个常驻服务——也就是说，只要跑起来，它就在那儿听着。
影响版本：0.3.9 到 0.5.5，连 0.5.6 的 RC 和 dev 分支都算在里面。修复版本：截至公告日尚未发布，官方没给回补包，只能等上游；所以那几天能做的不是"打补丁"，而是别的。
一个 9.8、又没补丁的洞，能做什么？其实和"有补丁但一时升不上去"是同一套应对：
- 先缩小暴露面。 这种中间件十有八九只该在内网被调用。先确认它没监听在公网地址上；真要跨网，也走白名单，别裸奔。
- 前面加一道门。 挂个反代或加个认证，把"未授权"先变成"要授权"——洞还在，但够不到就用不上。
- 盯上游。 没补丁不等于永远没有，订阅它的 release，出了新版第一时间换。
- 盘依赖。 先搞清楚自家到底有没有在跑它、是哪个版本。很多"备查"的洞最后变成事故，都是查的时候才发现——"我们居然装了"。
自查先看有没有、是什么版本：
pip show lmcache 2>/dev/null | head -3
# 容器里更直接：
docker ps --format '{{.Image}}' | grep -i lmcache我把这条从"备查"里拎出来写，是因为它是个反面样本：平时总说"先打补丁"，但现实里总有那么一段窗口，补丁还不存在。那段时间拼的不是手速，是暴露面和纵深。
前阵子 GitLab 那个满分洞也是一样的道理——修复版本出来，第一件事是先确认自己在不在范围内，而不是等有人放了 PoC 才动。LMCache 这次连版本都还没得升，顺序得反过来：先确认暴露面，再等上游。官方的安全公告在 LMCache 仓库的 security advisories。
评论