0. 这篇文章解决什么问题

很多团队在做 AI 应用、RAG 原型、数据分析工具、内部 dashboard 时,会先把 notebook、workflow runner、demo server 跑起来。

这类工具一开始常常被视为“临时环境”或“研发辅助工具”,但实际情况是:它们经常能访问 .env、云凭据、数据库连接串、模型 API Key、向量数据库 token、内部 API 和真实业务数据。

所以,AI / 数据工具上线前不能只检查“功能能不能跑”,还要检查下面这些问题:

  • 是否存在终端、WebSocket terminal、console、shell、notebook execution 等执行能力;
  • 执行能力是否真的经过认证和授权;
  • 服务是否绑定到公网、办公网或共享网络;
  • 工作目录里是否存在高价值凭据;
  • 日志是否足够支撑事后排查;
  • 一旦工具被控,攻击者能不能继续访问云账号、知识库、内部 API 或代码仓库。

Marimo pre-auth RCE 是一个很适合用来做检查样例的案例。

1. 案例背景:Marimo pre-auth RCE

Marimo 是一个开源 Python notebook 平台,可用于数据分析、交互式 notebook、Python app 和内部数据工具。它的使用场景天然靠近数据科学、机器学习、RAG 原型、内部 dashboard 和 AI 工具链。

这次漏洞的关键信息:

项目 内容
漏洞编号 CVE-2026-39987
Advisory GHSA-2679-6mx9-h9xc
影响版本 marimo <= 0.20.4
修复版本 0.23.0
漏洞类型 CWE-306: Missing Authentication for Critical Function
关键路径 /terminal/ws
风险能力 未认证访问终端 WebSocket,可能获得与 Marimo 进程相同权限的 shell

关键点不是“notebook 页面泄露一点内容”,而是“notebook 后面的终端入口没有被正确保护”。

2. 风险成立条件

不是所有 Marimo 实例都会自动变成公网 RCE 风险。风险通常来自多个条件叠加:

条件 风险解释
editable notebook / edit mode 工具处在可编辑、可执行的模式
terminal 功能可用 存在可交互的终端能力
服务绑定共享网络或公网 例如使用 --host 0.0.0.0 暴露给办公网、容器网络或公网
endpoint 缺少认证校验 /terminal/ws 没有像其他 WebSocket endpoint 一样完成认证检查
运行进程权限较高 进程可读取工作目录、环境变量、SSH 目录、云 SDK 配置或数据文件
工作目录存在凭据 .env、数据库密码、模型 API Key、云 Access Key 等

如果这些条件同时存在,攻击者拿到的就不是一个“页面访问权限”,而是一个可以继续读取环境和凭据的执行入口。

3. 攻击者为什么优先找 .env

Sysdig 的蜜罐观察显示,攻击者拿到入口后,并不是先做复杂持久化,而是很快转向 .env、SSH key、工作目录文件和云凭据。

这符合现实攻击收益:

目标 价值
.env 可能包含数据库连接串、API Key、云凭据、内部服务 secret
~/.ssh 可能用于访问其他主机、代码仓库或内部跳板
云 SDK 配置 可能访问对象存储、计算资源、日志服务、镜像仓库
向量数据库 token 可能读取企业知识库或 RAG 数据
模型 API Key 可能造成费用损失、数据泄露或被用于进一步探测
内部 webhook 可能触发自动化流程或进入企业协作系统

在 AI / 数据工具链里,服务器本身不一定是最终目标。攻击者真正想拿的是工具背后的权限。

4. 上线前检查清单

下面这份清单不只适用于 Marimo,也适用于 Jupyter、RAG 管理台、Langflow、RAGFlow、Dify、n8n、FastGPT、MCP server、内部 dashboard、workflow runner、临时 webhook 服务和 AI coding 环境。

4.1 执行能力检查

检查项 问题 风险
终端能力 是否提供 terminal、WebSocket terminal、shell、console、notebook execution? 一旦认证绕过,攻击者可能直接执行命令
WebSocket endpoint WebSocket 路由是否和 HTTP 路由使用同一套认证逻辑? 页面有登录不代表 WebSocket 有认证
edit / debug mode 是否存在 edit mode、debug mode、dev mode? 临时模式经常绕过正式权限控制
插件 / 扩展 是否加载第三方插件、工具调用、MCP server 或浏览器自动化能力? 插件可能扩大执行面和数据访问范围

4.2 暴露面检查

检查项 建议
绑定地址 避免将管理类工具直接绑定到 0.0.0.0 并暴露到公网
网络入口 用反向代理、VPN、零信任网关或访问控制限制来源
管理路径 terminal、admin、debug、import、export、connector 等路径应单独审计
临时环境 不要因为是 demo、测试、临时 notebook 就跳过资产登记

可以在网关、反向代理或访问日志里重点检索:

/terminal/ws websocket terminal console debug edit

注意:普通 HTTP 访问日志通常只能看到连接和路径,未必能看到 WebSocket 内部执行的命令。命令行为更可能出现在运行时审计、容器审计、EDR、蜜罐会话或主机日志里。

4.3 凭据与工作目录检查

检查项 建议
.env 不要让 notebook / demo server 的工作目录直接保存长期有效密钥
API Key 区分开发、测试、生产 key,避免共用高权限 key
云凭据 使用最小权限和短期凭据,避免把主账号或长期 AK 放进工具环境
SSH key 不要把可登录生产或跳板的 SSH key 放在可执行工具的可读目录
数据库连接串 限制来源、权限和可访问库表
向量数据库 token 需要区分读写权限、租户和知识库范围

上线前至少问一句:

如果这个工具被拿到 shell,攻击者能读到哪些密钥?这些密钥还能继续访问哪些系统?

4.4 运行权限检查

检查项 建议
进程用户 尽量避免以 root 运行 notebook / dashboard / workflow runner
容器权限 禁止不必要的 privileged、宿主机目录挂载和 Docker socket 挂载
文件权限 工作目录、日志目录、配置目录要做最小可读
云权限 工具使用的云角色只给完成任务所需的最小权限
横向访问 不要让一个 demo 工具天然能访问全部内部网段

很多 AI / 数据工具的问题不是“功能危险”,而是“它运行时拿到了过大的环境权限”。

4.5 日志与告警检查

日志类型 应关注什么
网关 / 反向代理日志 是否访问 /terminal/ws、admin、debug、import/export 等路径
应用日志 是否有终端会话创建、用户身份、来源 IP、会话时间
容器 / 主机日志 是否出现异常 shell、PTY、读取敏感文件、扫描目录等行为
云审计日志 是否有异常 AK 使用、跨区域访问、批量读对象存储、创建临时凭据
密钥使用日志 模型 API、数据库、向量库、对象存储是否出现异常调用

补丁之后不要只看版本号。只要工具曾经暴露过,就要回看日志,并判断是否需要轮换凭据。

5. 应急处置建议

如果你们正在使用 Marimo,或者存在类似 notebook / terminal / dashboard 暴露风险,可以按下面顺序处理。

5.1 Marimo 专项动作

  1. 升级到 0.23.0 或更高版本。
  2. 检查是否运行在 editable notebook / edit mode。
  3. 检查 terminal 功能是否开启。
  4. 检查服务是否绑定到 0.0.0.0,是否可被公网、办公网、共享网络访问。
  5. 如果暂时无法升级,先从网络层阻断 /terminal/ws,或禁用 terminal 功能。

5.2 通用排查动作

动作 说明
查入口 看是否有异常来源访问 terminal、WebSocket、debug、admin 路径
查命令 看运行时是否出现 pwd、whoami、ls、读取 .env、读取 ~/.ssh 等行为
查凭据 列出工具进程能读取的 key、token、连接串、SSH key
查云审计 看是否有异常对象存储访问、云 API 调用、数据库连接
轮换密钥 对可能暴露的 .env、API Key、云凭据、数据库密码、SSH key 做轮换
加入资产清单 把 notebook、RAG 管理台、workflow runner、MCP server 纳入正式资产管理

6. 可直接落地的 10 个问题

AI / 数据工具上线前,建议安全、研发、算法、数据团队一起过这 10 个问题:

  1. 这个工具是否提供终端、WebSocket terminal、console、shell、notebook execution 或远程命令执行能力?
  2. 这些能力是否在 endpoint 层做了认证,而不是只靠前端页面或反向代理假设?
  3. 是否存在 edit mode、debug mode、dev mode 下的权限绕过路径?
  4. 服务是否绑定到 0.0.0.0,是否可以从公网、办公网或共享网络访问?
  5. 工作目录里是否存在 .env、云凭据、SSH key、数据库连接串或模型 API key?
  6. 进程权限是否过高?容器是否以 root 运行?是否可以读取不该读取的目录?
  7. WebSocket、terminal、notebook execution 行为是否有可审计日志?
  8. 如果这个工具被控,攻击者能不能继续访问知识库、向量数据库、内部 API、代码仓库或云账号?
  9. 补丁之后是否轮换了凭据,还是只升级版本就结束?
  1. 这个工具是否已经进入资产清单,还是仍然被视为某个同事临时跑的实验环境?

7. 结论

Marimo 这次漏洞的价值不只在于它是一个 pre-auth RCE。

它更像一次提醒:AI / 数据工具往往不是传统意义上的核心业务系统,但它们离数据、凭据、模型 API、云权限、代码仓库和内部自动化非常近。

企业做 AI Agent、RAG、Notebook、内部 dashboard、MCP server 或 workflow runner 时,不能只问模型效果和功能流程,还要问:

这个工具背后的执行环境、调试入口、凭据管理、网络暴露面和日志留痕,能不能经得起一个真实攻击者连接进来后的前三分钟?

如果这个问题答不上来,就不应该急着把它接到企业知识库、内部 API、云账号和自动化流程上。

参考来源

原文

公众号原文:
https://mp.weixin.qq.com/s/htrOoj3R20KQ0lkhf3hZNg

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐