给卫星发指令的图形界面，居然能被一个"没有认证、没有跨站防护、还把服务口开满全网"的漏洞，变成一个任何人都能当场点火的遥控器。2026 年 8 月，Cycode 安全研究员 Yuval Elbar 披露了针对 NASA/JPL 开源框架 AMMOS Instrument Toolkit（AIT）的浏览器端操作员控制台 AIT-GUI 的一串严重漏洞，漏洞链 GHSA-p9r8-2q67-fp86 的 CVSS v3.1 评分高达 9.4（严重级），影响着 2.5.1 及更早版本，修复版本 2.5.2 已于 8 月 12 日发布；与之相关的 CVE-2026-60112 更是拿到 CVSS 9.8，指向通过无凭据会话遥控 AIT 指令总线。它的危害不是"泄露一点数据"，而是对航天器指令总线的未授权控制——在卫星测控这个语境里，这几乎等同于把地面段交了出去。
一、AIT-GUI 是什么：给航天器"发号施令"的浏览器控制台
先弄清楚被点名的组件是什么。AIT-GUI 是 NASA/JPL 开源 AMMOS Instrument Toolkit（AIT）框架自带的浏览器端操作员控制台，建立在其核心库 AIT Core 之上。它的职责相当硬核：对航天器及科学仪器进行实时遥测监控、通过 Web 界面发送指令（commanding）、执行序列脚本（sequences）与服务器端脚本，并参与任务操作、事件报告、系统日志等地面操作。换句话说，它不是一个"看看遥测数据的只读面板"，而是操作员手里可以直接向航天器下命令、跑任务序列的关键控制界面。这种工具一旦失守，影响的就不再是某台服务器，而是整个任务操作的完整性。
二、四个致命缺陷：没有一个算得上"复杂"
Cycode 披露的漏洞链由四个问题叠加而成，几乎每一条都是教科书式的 Web 安全反面教材，但组合起来却格外致命。
第一，服务器的 host 配置形同虚设。代码读取了配置里的 host 值（默认是 localhost），但随后直接把它丢掉，WSGI 服务器被硬编码成绑定到 0.0.0.0——也就是说，哪怕操作员为了安全把控制台设置为"仅本机可访问"，服务实际上仍监听在所有网络接口上，API 对整个可达网络敞开，默认端口是 8080。
第二，所有状态变更端点都没有认证、授权，也没有 CSRF 防护。没有登录要求、没有会话检查、没有 CSRF Token、没有 CORS 限制。更糟的是，这些端点接受的是 application/x-www-form-urlencoded 格式的 POST——这种请求在浏览器里属于 CORS 的"simple"请求，不需要 preflight 就能跨源提交。
第三，POST /cmd 把任意命令原封不动地转发给指令总线。它接收一个 command 参数，解析后直接通过 send() 转发给底层指令总线，没有任何验证。攻击者只需要一个最简单的 HTTP POST，就能向指令总线投喂任意命令。
第四，POST /seq 与 POST /script/run 存在路径穿越：seqfile 参数被直接拼接到 SEQRoot，只用一个 os.path.isfile() 检查文件存在与否，却从不限制路径范围。攻击者可以用 ../../../../ 一路闯出目标目录之外，把任意文件交给 ait-seq-send 子进程去执行；/script/run 同理，可以读取甚至执行 ScriptRoot 之外的脚本。
三、最阴险的放大：即使不暴露端口，浏览器也能当帮凶
这四个缺陷里最值得警惕的，是那条"无需直接网络暴露"的成链路径。就算运行环境做了防火墙隔离、服务端口根本不对公网开放，攻击者依然可以通过浏览器 CSRF 来驱动：诱导操作员打开一个恶意网页，该网页自动向 127.0.0.1:8080 提交跨源 POST 请求，从而触发命令发送或脚本执行——整个过程不需要任何用户交互，不需要认证，也不需要预检请求。对一个地面测控操作员来说，"打开了一个看起来正常的网页"和"向卫星发出了一条不该有的指令"之间，被这条漏洞链直接拉通了。
这也再次说明了 OT / 关键基础设施场景下浏览器接入面的特殊性：在普通 Web 应用里，缺 CSRF 或认证往往只是账户风险；而在航天器地面控制语境里，同一个低级缺陷可能直接作用于任务操作和硬件控制链路。安全基线不该因为"这工具不连外网"就放水，因为浏览器这条入口恰恰天然带着"跨域"这个放大器。
四、产业意义：开源地面段，成了供应链上需要盯防的一环
这起事件的意义不止于修补一个具体的开源项目。它把三个趋势摆到了台前。
其一，地面段安全必须按关键基础设施的标准来对待。AIT-GUI 的教训是：即便系统不面向互联网，只要存在浏览器访问入口，就可能被远程驱动；而且因为直接连着航天器指令总线，其影响从"数据泄露"跃升为"对测控操作完整性的未授权干涉"。
其二，开源地面系统的供应链压力正在显现。AIT 是 NASA/JPL 开源 AMMOS 工具链的一部分，被广泛用于构建地面数据系统、遥测监控和指令控制。一个上游框架的认证缺失，会沿供应链传导进下游各类任务团队与地面基础设施中——谁来为这些开源组件的安全基线负责，是摆在整个太空生态面前的一道新考题。
其三，认证、授权与 CSRF 防护从来都不该是"可选加固项"。Cycode 在其公开文章中也建议，在部署修复版本后应审查命令与序列历史，评估补丁前是否存在异常的指令调用——这类"事后复查"正说明，类似低门槛漏洞一旦被利用，往往是静默且难以追溯的。
面对一台接收着航天指令、却把监听口开满全网、又毫无防护的控制台，最专业的回应不是抱怨攻击者，而是承认一个现实：在航天器地面控制这类高价值链路上，"我以为它足够安全"从来都不是安全。每一个"默认就是可信"的配置，都该像对待那道 0.0.0.0 的硬编码一样，被重新放回审计台上。
参考：NASA-AMMOS 在 GitHub 发布的 GHSA-p9r8-2q67-fp86 安全公告、Cycode 关于"NASA 地面站门没上锁"的漏洞分析、NVD 对 CVE-2026-60112 的记录、The Hacker News 与 Security Affairs 对 NASA AIT-GUI 高危漏洞的报道。