关于 nltk 的 8 条安全公告——它是安装最广泛的 Python NLP 包之一，也是大型机器学习工具链中广泛存在的传递依赖——于 9 月 2 日 发布。真正重要的两条并不是崩溃漏洞。
一个存在、已文档化、却关闭着的安全控制
CVE-2026-62388 涉及 pathsec，这是 NLTK 作为修复措施加入的模块，用于应对此前的 pickle 执行和路径遍历问题。它从一个默认值为 false 的环境变量中读取执行开关，而且所有检查逻辑的写法都是：当执行开关关闭时，发出警告并允许执行继续。该公告中的概念验证显示，验证函数被调用、发出警告，然后仍然继续执行。任何在最初的 pickle 漏洞出现后升级、并以为自己已经受到保护的人，其实并没有——除非他们也设置了该环境变量。
一个你无法打补丁的漏洞
CVE-2026-81726 涵盖使用调用方可控模型路径、通过内置文件打开函数访问文件的模型工件 API，即使在执行开关打开的情况下也会绕过沙箱 。其受影响范围为 截至并包括 3.10.3 的版本，而其已修补版本字段写的是 None。截至发稿时，3.10.3 仍是 PyPI 上的当前版本。没有可升级到的版本。
常见表述哪里说错了
“8 个新的 NLTK 漏洞，立即升级”把风险排序两次都说反了。这 8 个中的大多数其实已经在 7 月和 8 月发布的版本中修复；这些公告只是补上进度，所以这批漏洞并不是同时出现的新暴露。而且，升级也解决不了真正仍然开放的那个——最新发布的版本本身就在受影响范围内。还有一个更隐蔽的陷阱：执行开关漏洞的标题严重性是一个 CVSS 4.0 分数，并未公布 3.1 向量，因此把它与其他公告中的 3.1 分数放在一起引用，比较的是不同量表；平台也将其标为高危而非严重。
当天的共同模式
NLTK 的禁用执行开关，以及其在解析失败时会正常返回的 DNS 检查，与同一天发布的 agent-harness 护栏公告属于同一种失败形态：一个控制措施对“我无法检查”的回答是“继续”。2026 年这波 AI 供应链漏洞，更多暴露的不是内存破坏，而是那些随包发布却不起作用，或者在失败时直接放行的安全层。