只开localhost，本地AI就安全吗？

摘要 网页、跨域、本地接口：127.0.0.1 挡住了外部机器，却不一定挡得住浏览器。 黑粉科技 · 2026-09-09

很多本地 AI 工具安装完都会说一句：服务只监听 127.0.0.1，不会暴露到公网，所以安全。前半句通常是真的，后半句却少了一个主角——浏览器。

你访问的网页运行在自己的电脑里，它发往 localhost 的请求，也从自己的电脑出发。路由器没有被穿透，公网端口没有打开，可本地服务仍然可能收到请求。此时决定网页能做什么的，不只是监听地址，还包括 CORS、认证、CSRF、防火墙，以及本地接口本身拥有多大权限。

localhost 是网络可达范围，不是完整的信任边界。

🎯 ▍为什么 AI 工具特别容易踩这条线

厂商为什么现在做本地 Web 服务？因为浏览器界面开发快、跨平台，模型下载、文件读取、工具执行都能共用一套 API，最容易抢到桌面 Agent 的入口。问题是，开发效率带来的收益归厂商和开发者，权限失控的代价却可能落在用户的数据与机器上。

这不代表本地 Web 技术有原罪。真正的利益结构在于：产品越快上线越早受益，认证、权限拆分和更新维护却是看不见的成本；如果发布节奏只奖励新功能，不奖励安全边界，没人主动买单的那部分就最容易被拖到以后。

🔍 ▍一个低危漏洞，为什么能走到本机代码执行

微软 WinML CLI 的官方安全公告 CVE-2026-84452，描述的正是这条链。早在本地开发服务器普及之后，浏览器访问 localhost 就不是新问题；变化在于今天的 AI 接口权力更大。

受影响版本错误地允许跨域访问，于是用户只要打开恶意网页，页面脚本就可能与 localhost 接口交互；如果该接口又能触发高权限操作，结果可以走到远程代码执行。

这里必须把严重度写准确：GitHub 官方给它的等级是 Low，不是 High 或 Critical。它通常需要用户先运行本地服务、再访问恶意网页等条件。

但“评级低”和“机制不值得警惕”不是一回事——AI 工具越来越爱把下载模型、读取文件、执行命令、打开浏览器都塞进同一个本地 API，权限一旦叠起来，后果就会放大。

公告写明 WinML CLI <0.4.0 受影响，0.4.0 修复。它在 8月28日公开、9月2日更新。这个例子最有价值的地方，不是某个产品“翻车”，而是把本地 AI 常见的误区照亮了：一个看似只服务自己的 Web API，也必须按照真正的网络服务来做权限设计。

⚡ ▍我做了一个隔离实验：不用模型，也能看清攻击路径

为了不碰任何真实 AI 服务，我临时启动了三个隔离端口：18777 是故意允许跨域的假 API，18778 是移除跨域许可的假 API，18779 只负责显示测试网页。两边都只返回一段合成 JSON，不读文件、不执行命令、不接模型。

结果非常直观。测试网页访问 18777 时，浏览器拿到 HTTP 200，也能把 JSON 内容显示出来；同一个网页访问 18778 时，浏览器同源策略阻止了脚本读取响应。差别不是“一个端口在本机、一个端口在公网”，而是服务有没有对这个网页来源开放读取权限。

实验结束后，三个临时服务都已停止，端口也已关闭。本文不提供可直接攻击真实产品的利用代码，因为理解机制不需要把攻击脚本包装成教程。

💰 ▍CORS 能挡读取，但它不是万能防火墙

刚才的第二组结果很容易被误读成“关掉 CORS 就安全”。上一次 Web 安全圈讨论 CSRF 时就反复提醒过：浏览器阻止读取，不等于请求一定没有发出。某些简单请求仍可能到达服务；如果一个接口用 GET 就能删除文件，或者写操作没有认证和 CSRF 防护，攻击者未必需要看见返回值。

因此安全设计要一层层叠：CORS 只允许明确的可信 Origin；写操作必须认证；token 要短期、最小权限；检查 Origin 或 Referer；高风险动作二次确认；真正执行 shell、读任意文件或访问云元数据的能力，最好与普通生成接口拆成不同进程和权限。

🧩 ▍vLLM 的两份公告，暴露的是另外两条边界

近期 vLLM 还有两份值得本地部署用户注意的官方公告。CVE-2026-73560 是中危、CVSS 6.5，涉及 SSRF 与文件读取，受影响版本 <0.26.0，0.26.0 起修复。它提醒我们：服务器替用户抓取 URL、加载多媒体或模板时，必须限制协议、地址范围与本地文件访问。

CVE-2026-73558 是跨用户数据泄漏，中危、CVSS 5.3。公告元数据写着受影响 <0.21.0，却把修复版本标为 >=0.27.0，中间存在明显的版本说明间隙。保守做法是至少升级到 0.27.0，并继续看官方后续说明，而不是替公告脑补“0.21 到 0.26 一定安全”。

🚀 ▍你现在可以做的五件事

• 先查版本并升级：WinML CLI 至少 0.4.0；vLLM 按对应公告升级，跨用户泄漏项保守采用至少 0.27.0。
• 检查监听地址：127.0.0.1 之外，尤其是 0.0.0.0 和局域网 IP，必须有防火墙与认证。
• 检查浏览器边界：不要给 CORS 填 *；只允许真正需要的 Origin，并对写操作增加 CSRF 防护。
• 缩小本地 API 权限：生成接口不该天然拥有任意 shell、任意文件与系统钥匙串能力。
• 把更新变成流程：依赖锁定、公告订阅、版本盘点和最小化回归测试，要与模型更新同等重要。

我对当前命令环境做了只读检查，没有发现 winml-cli 命令，也没有在当前 Python 环境发现 vllm 包。但这不是整台机器、所有虚拟环境、Docker 或局域网设备的安全证明。

为了不打断正在进行的 LocalBrain 测试，本轮也没有检查它的进程、端口或配置，更没有把这些公告直接套到 LocalBrain 上。

🧠 ▍本地优先，不等于安全问题自动消失

本地 AI 仍然值得做：数据少出门、延迟低、离线可用，都是实实在在的优势。历史上浏览器插件和桌面自动化也经历过一次从“方便脚本”到“高权限软件”的转变；今天模型开始拥有工具、文件、浏览器和系统操作能力，同样从“一个权重文件”变成了“一个高权限服务”。隐私优势越大，权限设计反而越不能含糊。

真正可靠的说法不是“我只开 localhost，所以没事”，而是：我限制了谁能访问，限制了它能做什么，所有高风险动作都要认证和确认，而且组件保持在已修复版本。127.0.0.1 是第一道门，不是整栋房子的锁。

摘要：一句话记住这篇 外部机器通常不能直连 localhost，但浏览器中的网页可以从本机发起请求；CORS 决定网页能否读取跨域响应，却不能替代认证、CSRF 防护和最小权限。官方公告要按原始严重度和版本边界写；本次实测完全隔离，没有访问任何真实 AI 服务，临时端口已关闭。

建议 官方安全公告 WinML CLI / CVE-2026-84452：项目仓库：microsoft/winml-cli vLLM SSRF / CVE-2026-73560：项目仓库：vllm-project/vllm vLLM 数据泄漏 / CVE-2026-73558：项目仓库：vllm-project/vllm