Rust内存安全也失守：CVSS 10.0漏洞九天连爆，沙箱是最后防线

从Rust zip漏洞看RCE的现实威胁

安全报告我看过太多，大部分在讲理论。但这一次不一样。你的上传服务，以root身份运行，解压了一个攻击者上传的文件。一分钟后，机器上多了一个新程序，照样以root运行，你甚至不知道它在那。一次精心构造的上传，攻击者就离远程代码执行（RCE）一步之遥。原文这就是平台工程团队的日常。这不是电影里的攻击场面。现实里的生产环境，就是这个样子。我见过太多团队在漏洞爆发时手忙脚乱，扫描器报了一堆，但边界没有建立起来。原文

Rust给了我们内存安全，但这一条不够。RUSTSEC-2026-0367，一个被公开的Rust zip crate漏洞，在开发者尽力修补的情况下，还是被发布到了生产环境。原文zip是Rust生态里打开.zip文件用得最多的库之一，这让它成了平台工程团队面对#vulnpocalypse的绝佳样本。原文

九天后，同一个crate披露了第二个更严重的漏洞，CVE-2026-115905，远程代码执行，CVSS 10.0，满分。原文修复已经发布，升级到zip 9.0.5。原文但这是一周里一个库的一个bug。依赖树里还有大量遗留代码，还有你急着上线的AI平台。原文

我不认为扫描能解决这个问题。你没法扫描掉漏洞。正确的策略是把所有代码都当作可能易受攻击，然后构建能承受妥协的系统，限制爆炸半径，主动对抗攻击者的战术，比如RCE、横向移动、living off the land。原文这不悲观。安全成本应该从"猜中攻击者意图"转移到"让攻击者无路可走"。原文

沙箱设计：deny-by-default与capability-driven的技术路径

那什么能拦住？一个安全、默认拒绝（deny-by-default）的沙箱。思路朴素，你无法执行你根本没有的东西。不要预测漏洞代码会做什么。从第一性原理出发，给所有代码构建架构性的安全。原文AI可以加速修复，但聪明的平台工程师在问不同的问题，怎么把所有的代码都当作不可信，然后在应用周围建立架构性的安全？原文这就是这个案例真正重要的地方。漏洞会来，修复会来，但架构性的安全不会自己出现。原文

这个沙箱建立在三个原则上。承受妥协，限制爆炸半径，主动对抗攻击者战术。原文这三个原则对应着具体的攻击路径。RCE是入口，横向移动是扩散，living off the land则藏在暗处。沙箱要在每一条路径上设卡。原文

Hacker News上的讨论给了另一个视角。有评论者说，Rust zip的CVE是安全、能力驱动（capability-driven）Wasm沙箱的绝佳案例。博客是长篇，链接的GitHub仓库里有完整代码和演示。HN这和原文方向一致，原文侧重deny-by-default，HN强调capability-driven，两个角度交叉验证了同一个方案。对比

还有个数学上的事。Rice's theorem告诉我们，无法预先知道任意程序对任意输入会做什么。原文Docker的默认seccomp配置只阻塞大约300多个系统调用里的44个，所以任何镜像都可以跑。原文预测做不到，边界可以构建。这就是deny-by-default的底气，不猜攻击者会干什么，先把自己能用的东西收起来。原文

量化数据与交叉验证：两漏洞时间线、CVSS与升级版本

把两个漏洞放在时间线上，看得更清楚。第一个，RUSTSEC-2026-0367，在Rust zip crate里被公开，尽管开发者尽了最大努力，它还是上了生产。原文九天后，CVE-2026-115905披露，严重程度远超第一例，RCE，CVSS 10.0。原文这九天里，很多组织的CI管道一直在失败，漏洞被发现的速度比修复快。原文

修复已经在zip 9.0.5里发布，今天就应该升级。原文但记住，这是一周里一个库的一个bug。你的依赖树里还有大量遗留代码，还有AI平台的漏洞。原文这个案例只是平台工程团队面对#vulnpocalypse的一个样本。原文

如果你想落地，HN讨论里提到的GitHub仓库有完整代码和演示，可以直接拿去。HN我不知道你的具体情况，但我知道扫描器不会救你。把代码当作不可信，用deny-by-default的沙箱围住它，这是我从这个案例里拿走的东西。原文root运行的解压服务，广泛使用的库，CVSS 10.0，这些数字背后是每天都在发生的现实。边界建起来，攻击者才真的无路可走。原文

原文：

Stopping Remote Code Execution with Sandboxes · 来源：Hacker News

参考来源：

• HN 评论区讨论 (item 50291354)

作者：itfan123 值班编辑 · 发布于 2026年10月30日