依赖
该标签下有 11 篇文章
Brotli 漏洞 CVE-2026-111497（Node2Shell）：如何检查 Node.js、Python 和 .NET，以及需要更新什么
2026年10月21日（美国时间），Google 发布了 Brotli 1.2.1、1.1.1 和 1.0.10，修复了官方 Brotli 库中的越界写入漏洞 CVE-2026-111497。受影响的是 Brotli 1.0.3–1.0.9、1.1.0 和 1.2.0。解压构造的 Brotli 数据可能破坏内存，导致崩溃、内存泄露，甚至可能导致任意代码执行。Google 在 CVSS v4.0 下将其评为 9.2。Node.js 于同一天发布了 22.23.4、24.22.1 和 26.12.1，10月22日 PyPI 软件包也在 brotli 1.2.1 和 brotlicffi 1.2.1.0 中得到修复。Microsoft 于10月25日（美国时间）发布了 .NET 8、9 和 10 的修复（8.0.33、9.0.22、10.0.14），Bun（1.4.4）和 Envoy 也发布了修复。日本计算机应急响应小组 JPCERT/CC 于10月26日发布警报，其中提到了 Node2Shell 和 HTTP2Shell 这两个别称。许多程序自带 Brotli 副本，因此更新操作系统的库并不能修复官方 Node.js 构建、来自 PyPI 的 Python wheel、容器镜像或单文件可执行程序中的副本。10月27日（美国时间），CISA 以存在主动利用的证据为由，将其加入已知被利用漏洞（KEV）目录，并要求美国联邦机构在11月10日前完成修复。CISA 未公布细节。一家威胁情报公司报告称观察到针对 Node.js 24.22.0 的利用流量，但该流量在该公司自己的测试中未能成功，Microsoft 仍将该漏洞标记为未被利用。新闻媒体报道称概念验证代码已经公开。本站结论：如果 Node.js、Bun、Python 或 .NET 服务会解压从外部收到的数据，请不要等待维护窗口，今天就更新，然后重新构建容器和可执行程序。 WordPress 和 PHP 网站：安全公司于11月2日解释称，这不是 WordPress 核心、插件或主题的缺陷，因此更新 WordPress 并不能修复它。WordPress 不自带 Brotli，而是使用操作系统的库，因此请更新操作系统的 libbrotli 软件包、重新构建容器，并在之后重启 PHP-FPM 或 Apache（重启为本站补充）。其中一家公司在实验室中通过 XML-RPC pingback 复现了代码执行，并称截至11月2日未发现有关 WordPress 网站实际被入侵的公开报告。
eMudhra（emSign）中间CA密钥泄露：Python用户需要为pip、certifi和uv做什么
2026年10月17日，有报告显示，印度证书颁发机构eMudhra的八个中间证书（其中六个用于TLS）的私钥生成过程存在严重缺陷，任何人都可能将其还原。eMudhra于10月18日吊销了全部八个证书，Chrome和Firefox则于10月17日通过各自的推送机制将其拦截。10月20日，Mozilla决定紧急移除其父根证书emSign ECC Root CA - G3的信任，Chrome将于10月27日（太平洋时间）移除。浏览器已受到保护，但浏览器之外的TLS客户端在更新各自的CA列表之前，可能会信任伪造证书。在Python中，pip始终加载其内置的certifi，因此即使操作系统证书存储已修复，旧版pip仍然存在风险。Python项目于10月20日发布通知（10月22日更新），要求用户至少升级到certifi 2026.10.19、pip 26.2.2、uv 0.13.4、sigstore 4.5.1、conda 26.9.4和pixi 0.82.1，并在不使用层缓存的情况下重建容器镜像。10月21日，他们发布了捆绑pip 26.2.2的Python 3.15.1、3.14.9和3.13.17。不会再为3.11或3.12发布带有更新pip的版本。这不是CPython中的代码执行漏洞：位于网络路径上的攻击者可能将访问PyPI、python.org等站点的连接重定向到伪造服务器。截至10月24日，尚未有利用此漏洞的公告。10月22日，eMudhra表示将退出全球SSL/TLS证书业务。本站的看法是：在所有环境中将pip升级到26.2.2或更高版本，将certifi升级到2026.10.19或更高版本，在不使用缓存的情况下重建Docker镜像，并提高锁文件中的certifi版本固定值。
TanStack、Nx Console 与 GitHub 的连锁入侵（2026年5月）：开发者需要检查什么
2026年5月11日，TanStack 的 Router/Start 仓库的发布流水线被滥用，向42个 npm 包、84个版本植入了窃取凭据的代码。一名 Nx 贡献者安装了其中一个包，GitHub CLI 令牌被盗；5月18日，被篡改的 Nx Console 扩展（v18.95.0）被发布。同一天，GitHub 表示一名员工的设备因被投毒的 VS Code 扩展而遭入侵，GitHub 内部仓库被外传。三起事件中，攻击都是通过合法的账户和分发渠道进行的，所以防御的关键是：确保仅凭一个被盗的发布凭据（令牌）无法发布新版本，并验证你配置的保护措施确实在生效。
Trivy 供应链攻击（2026年3月）：在 CI 中使用 Trivy 的人该做什么
2026年3月19日，由 Aqua Security 开发的开源漏洞扫描器 Trivy 发布了恶意的 v0.69.4，GitHub Actions 的 trivy-action（77个标签中的76个）和 setup-trivy（全部7个标签）被指向恶意提交。据 Aqua 称，恶意代码从 CI 运行器中收集密钥并发送出去；原因是在2月下旬开始的入侵中被拿走的凭据，由于3月1日的轮换没有一次性完成，攻击者得以继续使用。本站的看法：教训不只是“用提交 ID（SHA）而不是标签来固定 Action”。一个按 SHA 固定的 Action，仍可能按标签调用另一个组件，从而让恶意版本混入。泄露的凭据必须一次性全部替换，否则攻击者可以继续使用。扫描器要放在不持有部署密钥的作业中运行。
Node.js 中的原型污染：运行时不负责的部分，以及如何在自己的代码中防御
原型污染是指外部输入中的特殊键（通常经由递归合并）写进了 JavaScript 内置原型。结果有两种：你从未设置过的属性到处出现（破坏权限判断和选项检查），或者内置方法消失、应用在不相关的地方崩溃。最重要的是责任归属——Node.js 明确表示这不被视为 Node.js 核心的漏洞，防御应在应用和依赖层面实施。等更新是修不好的。
什么是 OpenSSL？负责 HTTPS 加密的库，以及如何保证它的安全
OpenSSL＝支撑 HTTPS（TLS/SSL）与加密的开源库。多数人从不直接编写它——而是通过 Web 服务器、操作系统或语言运行时继承而来。正因如此，一个 bug 的影响极其广泛（Heartbleed 就是经典案例）。防御之道：弄清你的技术栈使用的是哪个 OpenSSL、不要运行 EOL 版本、把底层库一并纳入 CVE 监控、并尽快打补丁。即便是本站签发的证书，其加密在底层也是经由 OpenSSL 家族的实现来运行的。
漏洞（CVE）处置实务：彻底修复，并持续监控复发
漏洞处置不是『修了』就完事。完成＝①扫描②修复③隔离/移交④监控四点齐备才算数。尤其在加上监控（每日变化检测）之前都算未完成——因为依赖明天又可能变得脆弱。修复内容哪怕100分，只要下一次部署就被覆盖，也等于0分。小团队靠自动变化检测和『local→push→deploy』这两条纪律就能保持安全。
osv-scanner 的安装与使用：自动找出依赖包里的 CVE
osv-scanner 是一款免费工具，扫描锁文件或容器以排查依赖中的 CVE。本文把安装、运行、CI 集成做成步骤，并理清它与 npm/pnpm audit、Dependabot 的取舍。本站的观点：哪个工具合适，取决于你的架构。多语言混用或不依赖 GitHub 就用 osv-scanner，单一 npm 用自带的 pnpm audit 就够了。
Log4Shell（CVE-2021-44228）——日志库漏洞，以及为何难以迅速确认自己是否在用
Log4j 的漏洞（CVSS 10.0）。核心问题在于经由间接依赖（传递性依赖），在不知不觉中正在使用它。日志输出这一被动处理成了攻击通道。SBOM 与依赖的机器化监控、迅速打补丁、对后续 CVE 的追踪，都是教训所在。
XZ Utils 后门（CVE-2024-3094）——受信任的共同维护者发起的供应链攻击
压缩库 xz 中被一名受信任的维护者植入了后门，这是一起供应链攻击。一名技术人员注意到登录变慢，在它进入稳定版之前发现了它。被瞄准的不是代码，而是『人与信任』。教训是：把依赖最小化、固定版本、提高可复现性、追查异常、支援维护者。
安全运维 Next.js：建立不在已公开CVE上掉队的机制
框架的最大风险是放任已公开的CVE。以实际运行的版本判定，用 Dependabot/osv-scanner 自动监控，尽快更新，并以最小权限运行，这四项做法是防守的关键。本站的看法：个人开发者通常缺的不是知识，而是让运维持续下去的方法；不漏看CVE的机制比速度更重要。