Guide

APT flaw CVE-2026-109518: patch your Debian and Ubuntu servers before the next apt install

By Aman Singh · Published · 8 min read

See all tracked CVEs →

On 4 November 2026, Debian, Ubuntu and APT's own developers published advisories for CVE-2026-109518: a flaw in apt, the package manager underneath almost every Debian and Ubuntu server. An attacker positioned on the network path between your server and its package mirror — a malicious mirror, a compromised proxy, or anyone who can tamper with the connection — can swap in an unverified, attacker-controlled package after apt has checked it, and get code execution as root.

Ubuntu rates it high priority (CVSS 4.0 base score 7.7) and APT's developers call it critical. The reassuring part: the fix ships inside apt itself, so patching is one command and needs no change to your mirrors or config. This guide shows who is exposed, how to check in two minutes, and the exact fixed version for your release.

Want your servers checked and patched for you? Security patching →

What the flaw actually is

When apt downloads a package, it verifies the archive's signatures before installing anything. CVE-2026-109518 is a way to defeat that ordering. The root cause, per the Debian tracker, is the reuse of hard links for downloaded files. An on-path attacker uses ordinary HTTP redirects and induced retries — triggered by temporary server errors or interrupted, resumed downloads — to get apt to install a file it did not actually verify. The result is an attacker-controlled package running its maintainer scripts as root during a normal apt install or apt upgrade.

Two conditions have to hold at once. First, the attacker needs a position on the network path: a malicious or compromised mirror, a proxy in front of apt, or control of the connection (public or shared networks, a hostile hosting network, DNS tampering). Second, apt has to retry failed downloads, which it does whenever Acquire::Retries is non-zero.

Are you affected?

The deciding factor is whether apt retries downloads, and whether an attacker could sit on your package traffic.

  • Debian 12 (bookworm), Debian 13 (trixie), Ubuntu 22.04 and newer: exposed in a default configuration. Acquire::Retries defaults to 3 on these releases, so the precondition is already met.
  • Debian 11, Ubuntu 20.04 and older: not exposed by default, because retries were off by default. But many setup scripts and container images enable Acquire::Retries for reliability, so check yours rather than assume.
  • CI runners, Docker builds and cloud-init scripts that run apt-get are in scope too — they install packages over the network, often with retries explicitly turned on for flaky networks.
  • Any server an attacker could get on-path to: VPS and dedicated boxes reached over networks you don't control, machines behind a shared or compromised proxy, and anything installing from a third-party mirror.

Check in two minutes

Print the three things that decide it: your release, your apt version, and whether retries are on. If apt is below the fixed version for your release and Acquire::Retries is non-zero, you are exposed.

Terminal
# 1. Which distribution and release
grep -E '^(NAME|VERSION)=' /etc/os-release

# 2. The apt version you are running
apt --version | head -n1

# 3. Is the retry setting the attack needs turned on?
#    (3 is the default on Debian 12+ and Ubuntu 22.04+)
apt-config dump | grep -i 'Acquire::Retries'
Example output (still vulnerable)
NAME="Ubuntu"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
apt 2.4.14 (amd64)        # below 2.4.15ubuntu0.1 -> still vulnerable
Acquire::Retries "3";     # non-zero -> the attack's precondition is met

Compare the apt version against the fixed version for your release in the table below. The version is the one that matters — not whether the number "looks recent", because distributions backport the fix into their own version scheme.

The fix

Because the bug is in apt itself, upgrading the apt package fixes it. You do not need to change mirrors, switch to HTTPS, or edit any config.

Terminal
sudo apt update
sudo apt install --only-upgrade apt

# Confirm you are at or above the fixed version for your release
apt --version | head -n1
DistributionFixed apt versionAdvisory
Debian 13 (trixie)3.0.4DSA-6607-1
Debian 12 (bookworm)2.6.2DLA-4880-1
Debian 11 (bullseye)2.2.5APT developers (post-LTS)
Ubuntu 26.103.3.3ubuntu0.1USN-8996-1
Ubuntu 26.04 LTS3.2.1ubuntu0.1USN-8996-1
Ubuntu 24.04 LTS2.8.4ubuntu0.1USN-8996-1
Ubuntu 22.04 LTS2.4.15ubuntu0.1USN-8996-1
Ubuntu 20.04 LTS and oldervia Ubuntu Pro (2.0.12+esm1 and earlier)USN-8996-1
  1. 1
    Update apt on every server with apt update then apt install --only-upgrade apt (or a full apt upgrade). Re-run apt --version to confirm it is at or above the fixed version for the release.
  2. 2
    Rebuild your container images. A running container keeps the old apt until the image is rebuilt from a patched base and redeployed — pulling alone changes nothing already running.
  3. 3
    Patch your CI and build images. Anywhere a pipeline runs apt-get install is a fresh download over the network on every run; update the base images those jobs use.
  4. 4
    Turn on automatic security updates where you can (unattended-upgrades on Debian/Ubuntu) so the next apt-level fix lands without a manual pass.

Does HTTPS protect me?

Not something you can count on here. The Debian and Ubuntu advisories describe the attack over HTTP and are silent on whether package sources reached over HTTPS mirrors are exposed. Neither says HTTPS is safe. So switching mirrors to HTTPS is sensible defence in depth, but it is not a substitute for the patch: update apt regardless of how your sources are configured.

Why it touches every app on the box

This is not a framework bug in your Node, PHP or Python code — it is in the layer underneath all of them. Every Debian or Ubuntu server installs and updates software through apt, so a Next.js app on a VPS, a PHP site on a cheap box, a Postgres server and a CI runner are all exposed through the same package manager. That makes it one of the highest-leverage patches of the month: one apt update per host closes it, but the host has to actually be touched.

If you have servers you set up once and rarely log into, this is the reminder they need patching at the OS level, not just at the app level — the same argument as any patching routine, made concrete.

Common questions

Am I affected by CVE-2026-109518?+
If you run Debian 12+ or Ubuntu 22.04+ and install packages over a network an attacker could sit on (a mirror, a proxy, shared or hostile networks), yes — Acquire::Retries defaults to 3 on those releases, which is the precondition. Debian 11, Ubuntu 20.04 and older are exposed only if retries were turned on, which many scripts and container images do.
How do I fix it?+
The fix is in apt itself. Run sudo apt update && sudo apt install --only-upgrade apt, then confirm apt --version is at or above the fixed version for your release. You do not need to change mirrors or config. Rebuild container and CI images so they pick up the patched apt too.
Does using HTTPS mirrors protect me?+
The advisories describe the attack over HTTP and do not state whether HTTPS sources are exposed, so don't rely on HTTPS as a mitigation. It's reasonable defence in depth, but patch apt regardless.
Which apt version fixes it?+
Debian 12 bookworm 2.6.2, Debian 13 trixie 3.0.4, Debian 11 bullseye 2.2.5 (published by APT's developers after Debian 11 LTS ended). Ubuntu 22.04 2.4.15ubuntu0.1, 24.04 2.8.4ubuntu0.1, 26.04 3.2.1ubuntu0.1, 26.10 3.3.3ubuntu0.1; 20.04 and older through Ubuntu Pro.
Can I just disable retries instead of patching?+
Setting Acquire::Retries to 0 removes the precondition the attack needs, but it is not an official mitigation and it makes package installs fail on flaky mirrors. Use it only as a short stopgap; updating apt is the real fix.
How serious is it?+
Ubuntu rates it high priority with a CVSS 4.0 base score of 7.7, and APT's own developers call it critical. Successful exploitation runs attacker code as root. It does require an attacker on your network path and package installs to be happening.

Want your servers checked and patched for you?

I audit which of your Debian and Ubuntu boxes are exposed, update apt cleanly across hosts, containers and CI, and verify the fixed version on each live server. See security patching or bug fixing and debugging. This is one of several recent critical fixes.

Sources

Next steps

Keep reading

Need a hand with this?

Tell me what you are working on. Free scoping call, fixed quote within 48 hours.

Book a call

← All guides