11 月 4 日，Debian、Ubuntu 与 APT 开发者三方同时发布公告，披露包管理器 APT 的一个缺陷 CVE-2026-109518：能够改动软件包下载流量的攻击者，可以把一个已经通过校验的包替换成自己的包，最终以 root 权限执行代码。Ubuntu 给出 CVSS 4.0 评分 7.7、优先级 high；APT 开发者直接定性为 critical。
事件概述
攻击前提是「能改 HTTP 流量」——恶意镜像站、透明代理、ARP 欺骗、上游 CDN 被拿下，都算在内。真正让它从理论变成现实的是 APT 的重试机制：从 Debian 12 与 Ubuntu 22.04 起，Acquire::Retries 默认开启，下载失败会自动重试。攻击者只要用 HTTP 重定向或者普通的临时性服务器错误把下载打断，就能让 APT 重新发起请求，并在重试的那一次把包换掉。
漏洞由 Max Justicz 报告。三份公告都没有描述在野利用，也没有给出「暂时无法升级」时的替代方案。这一点值得注意：这类补丁管理链路本身的漏洞，一旦出现利用，受影响的是所有在打补丁的机器。
技术细节
公开公告没有展开到代码级，但攻击成立的条件很清楚：在重试路径上，下载内容与校验结果之间的绑定关系可以被外部打乱。攻击者不需要伪造签名——签名本身是有效的，被换掉的是「哪个包对应哪次请求」。
这解释了为什么它被定为 critical：整套 APT 安全模型的基础就是「签名有效即可信」，而这条漏洞让一个签名有效的包出现在它不该出现的位置。对运维来说，这意味着「源是官方源、签名校验通过」不再自动等于「装的东西是对的」。
影响面也比想象的大。Ubuntu 明确表示，基于 Debian 与 Ubuntu 的衍生发行版同样受影响，只是没有点名。默认暴露的版本是 Debian 12 及以后、Ubuntu 22.04 及以后；Debian 11 与 Ubuntu 20.04 默认不带重试，但只要有人手工打开过 Acquire::Retries——大量自动化脚本和 Dockerfile 都这么干——同样中招。
修复进度
Debian 已发布修复版 APT。Ubuntu 在 11 月 4 日 14:25 UTC 向安全仓库推送了四个版本的构建：
- Ubuntu 26.10：
3.3.3ubuntu0.1 - Ubuntu 26.04 LTS：
3.2.1ubuntu0.1 - Ubuntu 24.04 LTS：
2.8.4ubuntu0.1 - Ubuntu 22.04 LTS：
2.4.15ubuntu0.1
但到 15:46 UTC，Ubuntu 追踪的八个版本（14.04 LTS 至 26.10）在漏洞页上仍全部标记为 affected，说明修复包的推送与状态更新并不同步，升级完最好自己核一次版本号。Debian 这边，testing 分支在 11 月 4 日 14:58 UTC 还停在有问题的 3.3.5；Debian 11 的长期支持已于 8 月 31 日结束，APT 开发者另外提供了 2.2.5。
修复建议
- 先升级 APT 本身：
apt-get update && apt-get install --only-upgrade apt，再用apt --version核对版本 - 暂时无法升级的机器，把重试关掉：把
Acquire::Retries "0";写进/etc/apt/apt.conf.d/99no-retry。这是关掉攻击窗口，不是修漏洞 - 软件源尽量走 HTTPS。公告只描述了 HTTP 场景、没说明 HTTPS 源是否受影响，但走 TLS 至少把「谁能改流量」这个前提去掉了一多半
- 使用第三方镜像或内网代理的环境要重点排查：查
/var/log/apt/term.log与history.log里同一软件包在短时间内被重复下载的记录 - 如果某台机器曾在可疑网络环境下执行过
apt upgrade，把那次升级安装的包列出来复核，必要时重装
最后一条经验：把「补丁通道本身」纳入威胁模型。这次是 APT，下次可能是镜像同步脚本、内部 Yum 源或者容器基础镜像。凡是能往生产环境塞代码的通道，都值得单独做一次完整性设计。