LMCache中的一个关键漏洞，作为开源软件加速大型语言模型（LLM）服务器（如vLLM），允许攻击者在不登录的情况下在缓存服务器上运行代码，并且没有可用的修复版本。
该漏洞存在于LMCache的多进程模式中，在该模式下，缓存作为独立服务器运行，LLM工作节点通过ZeroMQ消息库访问。向该服务器发送的单个网络消息可以以LMCache进程运行的用户身份运行命令。
只有当操作员将其设置为监听可路由地址，而不是默认使用的本地主机时，才能从另一台机器访问该服务器。JFrog于10月7日披露了该漏洞，并将其严重性评分定为9.8（满分10），属于关键范围，这是其对绑定到可路由地址的服务器的评级。
该漏洞被跟踪为CVE-2026-105192，影响从2025年10月发布的0.3.9版本到最新的稳定版本0.5.5，并且在0.5.6发布候选版本和开发分支中也存在。没有可用的修复版本。
服务器是否暴露取决于一个设置。默认情况下，多进程服务器仅在本地机器上监听，因此其他主机无法访问。当操作员使用可路由地址启动它时，它就可以被访问，这类似于多节点部署在机器之间共享缓存。
LMCache自己的示例Kubernetes部署以这种方式启动服务器，监听每个网络接口。运行在单个vLLM进程中的LMCache副本根本不打开端口。
多进程服务器为工作进程打开的ZeroMQ套接字用于注册和共享缓存数据，没有任何身份验证。一种类型的消息使用pickle解包，pickle是可以携带代码并在数据解码时运行的Python格式。服务器在仍然读取消息参数时解包它，而在检查消息类型之前，因此精心制作的消息可以运行发送者的代码。
该代码以LMCache进程的权限运行。根据JFrog的说法，在项目的官方容器镜像中，该进程以root身份运行。该漏洞是由JFrog安全研究团队的Yuval Moravchick发现的。
没有修补版本发布。在发布之前，JFrog建议操作员不要将多进程服务器分配可路由地址，并保持其端口在本地机器或受信任的集群网络上。限制谁可以访问该端口的防火墙降低了风险，但并未消除风险，因为任何仍然可以打开连接的主机都可以运行代码。
LMCache尚未发布该漏洞的安全公告。JFrog的公告没有为操作员提供确定服务器是否已经被攻击的方法。
其他报告和相关的vLLM修复
另外，一名GitHub用户在10月6日（CVE-2026-105192公开的前一天）提交了六个额外的LMCache安全报告。他们声称对不同租户的缓存数据以及几个无需登录即可执行命令的网络服务存在未经身份验证的访问。
这些报告来自一个账户，基于概念验证的主张，没有CVE，没有维护者的确认，也没有修复。其中一个指向一个默认的LMCache，该LMCache自那时起已发生变化：在0.5.5版本中监听每个网络接口的管理员HTTP服务器在0.5.6发布候选版本中仅在本地主机上监听。
与vLLM相关的一个漏洞已经修复。在2025年9月22日发布的0.30.0版本之前，携带格式错误的cache_salt值的单个请求可能会在使用LMCache多进程连接器的部署上崩溃引擎，这是一个被跟踪为CVE-2026-105756的拒绝服务漏洞。其评级为6.5，并不允许代码执行。
核心错误是将来自未经身份验证的网络套接字的数据传递给pickle，这是研究人员在2025年11月发现的其他AI推理框架中存在的相同错误，在一组他们称之为ShadowMQ的漏洞中。尚未确定LMCache的代码是否与这些项目共享相同的源。
觉得这篇文章有趣吗？请在Google News、Twitter和LinkedIn上关注我们，以阅读更多我们发布的独家内容。