严重的 SandboxJS 逃逸缺陷允许在受影响的应用程序中执行主机代码

SandboxJS 中的一个严重漏洞可以允许攻击者控制的 JavaScript 逃离沙箱并在主机系统上执行代码。该缺陷被追踪为 CVE-2026-43898，影响 npm 包 @nariv/sandboxjs 直至版本 0.9.5。

该问题的 CVSS 3.1 得分为 10.0，这是可能的最高评级。GitHub 的公告称该缺陷允许沙箱代码恢复内部运行时回调、使用伪造值、到达真实主机 Function 构造函数，并在沙箱外运行任意 JavaScript。

如果应用程序使用 SandboxJS 执行不受信任或用户提交的 JavaScript，则它们面临的风险最大。其中包括在线代码工具、自动化平台、服务器端脚本功能、插件系统以及任何依赖 SandboxJS 作为安全边界的产品。

CVE-2026-43898 有何影响

CVE-2026-43898 影响@nariv/sandboxjs，这是一个通过 npm 提供的 JavaScript 沙箱库。易受攻击的版本包括 0.9.6 之前的所有版本。

补丁版本为0.9.6。使用该库的开发人员应立即更新，并在应用补丁之前检查受影响的版本是否运行了任何不受信任的 JavaScript。

GitHub 在以下位置发布了该通报：GHSA-g8f2-4f4f-5jqw。该漏洞由研究人员 Macabely 报告，并被归类为 CWE-94（代码生成控制不当）。

该漏洞位于通过 prop.ts 中的 addOps 注册的属性访问逻辑中。受影响的版本允许沙盒代码访问敏感函数属性，例如调用者、被调用者和参数。

在 CommonJS 构建中，此行为允许沙盒代码读取 Function.caller 并泄漏名为 LispType.Call 的特权内部回调。该回调通常属于 SandboxJS 运行时，不应该对不受信任的代码可用。

一旦泄漏，可以使用攻击者控制的虚假上下文和对象值来调用回调。这为攻击者提供了恢复被阻止的主机静态信息并最终到达主机 Function 构造函数的路径。

为什么宿主 Function 构造函数很重要

宿主 Function 构造函数在这种情况下是危险的，因为它允许 JavaScript 代码在宿主环境中创建和运行新代码。如果沙盒脚本可以访问它，则沙盒将不再提供有意义的隔离。

概念验证GitHub 公告通过执行系统展示了风险通过 Node.js 内置功能执行命令。这表明攻击可以从沙盒 JavaScript 转移到应用程序进程内的主机级命令执行。

确切的影响取决于易受攻击的应用程序的运行方式。如果 Node.js 进程有权访问文件、环境变量、云凭据、内部 API 或数据库连接，则成功的攻击者也可能获得对这些资源的访问权限。

• 攻击者可以逃离 SandboxJS 边界。
• 恶意脚本可以在宿主进程中执行 JavaScript。
• 运行用户提交的代码的应用程序面临的风险最高。
• 主机进程可用的秘密可能会被暴露。
• 攻击者可能会根据进程权限修改数据或中断服务。

为什么CVSS评分是10.0

该通报为 CVE-2026-43898 提供了 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H 的 CVSS 向量。这意味着漏洞利用可以在易受攻击的应用程序设计中通过网络发生，攻击复杂性低，不需要特权，并且不需要用户交互。

范围被标记为已更改，因为利用跨越了沙盒代码和主机环境之间的预期边界。机密性、完整性和可用性影响评级都很高。

这并不意味着 npm 软件包在安装后会自动攻击系统。这意味着任何将易受攻击的沙箱暴露给攻击者控制的 JavaScript 的应用程序都可以成为完整主机进程代码执行的路径。

哪些应用程序面临最高风险

风险最高的应用程序是将 SandboxJS 视为不受信任的 JavaScript 的安全边界的应用程序。这包括用户可以提交脚本、公式、插件、自动化、模板或代码片段的服务。

内部工具也可以暴露。如果低权限用户可以提交通过 SandboxJS 运行的 JavaScript，工作流自动化平台、管理面板、测试系统或开发人员实用程序仍可能成为严重风险。

面向公众的服务应该得到最快的关注。如果未经身份验证的用户可以向易受攻击的 SandboxJS 运行时提供 JavaScript，则应用程序可能会在没有凭据的情况下暴露于远程代码执行。

开发商现在应该做什么

开发人员应将@nariv/sandboxjs升级到0.9.6或更高版本。团队还应该重建部署，刷新锁定文件，并确认生产系统不再加载易受攻击的版本。

更新包是第一步，但团队还应该检查日志中是否有可疑的脚本执行。任何通过受影响版本处理不受信任 JavaScript 的系统都应被视为潜在暴露的系统。

如果易受攻击的应用程序处理机密、环境变量、API 令牌、云凭据、数据库密码或用户数据，团队应检查 Node.js 进程是否可以访问这些机密，并在适当的情况下轮换敏感凭据。

1. 检查 package.json 和锁定文件中的 @nariv/sandboxjs。
2. 将软件包升级到0.9.6或更高版本。
3. 重建并重新部署受影响的应用程序。
4. 搜索日志以查找可疑提交的 JavaScript 或意外的子进程执行。
5. 检查主机进程是否有权访问敏感凭据。
6. 如果不能排除利用的可能性，则轮换暴露的秘密。
7. 如果无法立即进行修补，请暂时禁用不受信任的脚本执行。

无法立即更新的开发人员应停止通过受影响的 SandboxJS 版本运行不受信任的 JavaScript。这是最安全的临时措施，因为该缺陷破坏了库的核心隔离承诺。

团队还应该减少托管沙箱的进程的权限。该进程不应以 root 或管理员身份运行，也不应具有广泛的文件系统、网络或凭据访问权限。

沙盒库应该位于分层控件内。 JavaScript 沙箱不应该是不受信任的代码和敏感基础设施之间的唯一障碍。

• 在部署补丁之前禁用公共脚本执行。
• 以尽可能低的权限运行服务。
• 将执行转移到单独的容器或隔离的工作线程中。
• 限制沙箱主机的出站网络访问。
• 从进程中删除不必要的环境变量和机密。
• 对 child_process、进程访问和异常命令执行应用监控。

为什么这是关于 JavaScript 沙箱风险的提醒

JavaScript 沙箱很困难，因为该语言包含许多反射和动态功能。小的暴露错误可能会创建从受限代码到宿主对象、构造函数、原型或内部回调的路径。

SandboxJS 之前也有过几个2026 年沙箱逃逸建议。这一历史并不意味着开发人员必须避开每个沙箱库，但它确实表明了为什么团队应该避免依赖一个库作为唯一的安全边界。

对于高风险工作负载，更安全的设计可在操作系统或容器级别隔离不受信任的执行。这样，JavaScript 沙箱逃逸不会立即成为广泛的主机妥协。

FAQ