APT verified the package. The signature checked out. And then an attacker swapped the file and ran code as root. That’s CVE-2026-109518, a newly patched flaw in the package manager that underpins nearly every Debian and Ubuntu system in production. If you’re running Debian 12 or Ubuntu 22.04 LTS or newer, your default configuration is vulnerable. The one-liner to fix it is below — but read the safe version first, because patching this carelessly can expose you during the patch itself.
What the Flaw Actually Does
The vulnerability lives in APT’s HTTP download retry logic. Here’s the attack in three steps.
First, the attacker — who needs to be on-path, meaning able to intercept traffic between your machine and the package mirror — answers APT’s download requests with redirects that point two different packages to the same URI. APT treats them as a single file and creates a hard link between them on disk.
Second, the attacker returns transient HTTP errors, triggering APT’s retry mechanism. This is the prerequisite: the attack only works when Acquire::Retries is non-zero. The default on Debian 12 and Ubuntu 22.04 and newer is 3.
Third — and this is the uncomfortable part — APT verifies the package signature correctly. The check passes. But the hard link opens a window between when verification completes and when the package is installed. The attacker replaces the file on disk through that link. What gets installed is not what APT verified. The result is arbitrary code execution as root.
This is a classic TOCTOU flaw (time-of-check, time-of-use). Researcher Max Justicz discovered the vulnerability and reported it to Canonical, which reserved the CVE on October 12, 2026. Patches shipped November 4 under Debian DSA-6607-1 and Ubuntu USN-8996-1. CVSS 4.0 score: 7.7 (High).
Who Is Affected
The vulnerability requires Acquire::Retries to be greater than zero. That setting has been 3 by default since apt 2.3.2, which shipped in Debian 12 and Ubuntu 22.04 LTS. Older releases default to zero retries and are not affected in a standard configuration.
- Debian 12 (bookworm) and Debian 13 (trixie)
- Ubuntu 22.04 LTS and all newer Ubuntu releases through 26.10
No confirmed exploitation in the wild has been reported as of November 7, 2026. That’s not a reason to wait. The attack vector is network-accessible, requires no special credentials, and a proof-of-concept audit repository is already public on GitHub.
How to Patch
The safe upgrade command passes -o Acquire::Retries=0 as a flag, which disables retries during the upgrade itself. This prevents the vulnerable APT binary from exploiting itself while patching:
sudo apt-get update && sudo apt-get upgrade -o Acquire::Retries=0To check whether you have the fixed version:
apt --versionCompare your version against the fixed releases:
| OS | Fixed APT Version |
|---|---|
| Debian 13 (trixie) | 3.0.4 |
| Debian 12 (bookworm) | 2.6.2 |
| Ubuntu 26.04 / 26.10 | 3.2.1ubuntu0.1 / 3.3.3ubuntu0.1 |
| Ubuntu 24.04 LTS | 2.8.4ubuntu0.1 |
| Ubuntu 22.04 LTS | 2.4.15ubuntu0.1 |
Container and CI/CD Builds Are Higher Risk
If your CI/CD pipeline runs apt-get install during Docker image builds, your risk is elevated. Build networks are shared, proxied, or routed through infrastructure that an attacker could position themselves in front of. A tampered package doesn’t stay on one machine — it ships inside the container image to every environment that pulls it.
AWS issued a security bulletin (2026-172-AWS) rated “Important” noting that customers running self-managed Ubuntu or Debian on EC2 are responsible for updating APT themselves, including instances launched from Ubuntu 22.04 AMIs. Until your base images rebuild with the patched APT, add -o Acquire::Retries=0 to your Dockerfile apt-get calls:
RUN apt-get update && apt-get install -o Acquire::Retries=0 -y your-packageWorkaround if You Can’t Patch Immediately
Create a drop-in APT config file to disable retries until the full patch is applied:
echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-no-retriesThis removes the retry behavior the attack requires. It’s a workaround, not a fix — remove the file once you’ve patched. The full technical writeup at The Hacker News has additional detail on the exploitation chain if you need to brief your security team.
