APT Vulnerability CVE-2026-109518: How to Patch Debian and Ubuntu Servers and Containers

An APT vulnerability, CVE-2026-109518, lets an attacker slip an unverified package onto Debian and Ubuntu systems, where it runs as root. The attacker needs to be able to tamper with APT’s HTTP traffic. Debian and Ubuntu shipped fixed apt packages on November 4, 2026. Debian 12, Ubuntu 22.04 LTS and newer releases are exposed in their default setup.

Most CMS hosting for our readers runs on Debian or Ubuntu. That includes a VPS for WordPress or Drupal, a cloud VM, or a Docker image. This post covers what Ubuntu and Debian say about the APT vulnerability and the fixed version for each release. It shows how to install the fix without hitting the flaw while you do it. It also covers containers and images. Facts are as of November 10, 2026.

The short version: update apt on every Debian and Ubuntu machine. Set Acquire::Retries=0 for that one update so the fix cannot be swapped in transit. Then switch your package sources to HTTPS where your mirror supports it. Rebuild container images from fresh base images, because old images keep the old apt.

What the APT vulnerability does

Ubuntu’s CVE page describes an "on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy)" between APT and the archive server. That attacker can trick APT into installing an unverified, attacker-controlled package. Ubuntu says the result is remote code execution with root privileges.

The flaw comes from how APT reuses hard links when it follows redirects and retries a download. It only works when the Acquire::Retries setting is above zero. Ubuntu says the default of 3 applies starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS. Older releases are unaffected in a default setup.

Ubuntu rates it High, with a CVSS 4.0 score of 7.7. Max Justicz found and reported it, according to Ubuntu’s security notice USN-8996-1. Ubuntu’s and Debian’s pages do not report any exploitation.

Who is exposed to the APT vulnerability

The Ubuntu blog post on the fix adds detail. The bug sits in the HTTP code of APT’s library. That means every APT front end is affected: apt, apt-get, aptitude and Ubuntu’s graphical tools.

Three conditions limit the risk:

• An install has to happen. An attacker can exploit it "only if the target system attempts to install a .deb package," Ubuntu says. A server that is not installing or upgrading anything is not hit at that moment.
• The traffic has to be HTTP. HTTPS blocks the attack, Ubuntu says. Non-HTTP transports such as FTP are not affected.
• Retries have to be on. They are on by default in the releases listed above.

Snap installs are not affected, per Ubuntu. Debian derivatives that use the same APT code inherit the issue.

The attacker also needs a position in the path. That could be a compromised or malicious mirror, a proxy, or a network the server shares. For a VPS that pulls updates over plain HTTP, the mirror and every hop to it are in that path.

Fixed apt versions for Debian and Ubuntu

Here are the fixed versions from Ubuntu’s notice and Debian’s security tracker:

Debian’s security tracker lists the trixie fix under DSA-6607-1 and the bookworm fix under DLA-4880-1. The bookworm fix comes from the LTS team because Debian handed bookworm to its LTS team on July 12, 2026. Debian says bookworm LTS runs until June 30, 2028. Debian 11 (bullseye) LTS ended on August 31, 2026, and it is not exposed in a default setup anyway.

The chicken-and-egg problem: updating apt with apt

The fix for this APT vulnerability arrives through APT itself. While the new package downloads, the old, vulnerable code is still doing the work. If an attacker is already in the path, that one download is the moment to target.

Ubuntu’s answer is to turn retries off for the update. If Acquire::Retries "is set to 0, no downloads are retried and the vulnerability cannot be exploited," Ubuntu’s blog says. It also says this mitigation holds whether the threat is an on-path attacker or a malicious mirror.

Ubuntu gives this command to update only APT with retries off.

sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

Or, to apply all pending updates the same way:

sudo apt update && sudo apt upgrade -o Acquire::Retries=0

On Debian, the same option works with apt-get. For example: sudo apt-get update && sudo apt-get install -o Acquire::Retries=0 --only-upgrade apt. That command is our adaptation, not one Debian published.

How to check and update each server

Work through these steps on each Debian or Ubuntu machine.

1. Check the installed version. Ubuntu suggests apt list --installed '?source-package(^apt$)'. On Debian, dpkg-query -W apt gives the same answer. Compare the result to the table above.
2. Install the fix with retries off. Use the commands in the previous section.
3. Confirm the new version. Run the check again.
4. Check automatic updates. Ubuntu says unattended-upgrades, on by default since 16.04 LTS, applies these fixes within about 24 hours. Many servers are already patched. Confirm it rather than assume it.

Managed hosts and platform services usually patch the host for you. If you run your own VPS, the job is yours. Ask your host which you have if you are not sure.

Switch package sources to HTTPS

Ubuntu says HTTPS blocks the attack, because it needs to change HTTP traffic. Once the fix is in, Ubuntu calls TLS "only necessary as a future precaution" against this APT vulnerability. It is still a sound default for any server that installs software.

Ubuntu’s blog gives a sed command for this. It rewrites the Ubuntu archive, security and ports addresses in the sources files from http:// to https://. Run sudo apt update afterward to confirm it works. Ubuntu notes that some community and country mirrors do not support HTTPS.

On Debian, the same idea applies. If your mirror supports it, change http:// to https:// in the sources file, then run apt-get update. Our guide to HTTPS and TLS explains what the encrypted connection adds. APT’s signature checks still matter. This flaw shows they depend on the code that runs them.

Containers and images

Ubuntu’s pages do not cover containers, so the steps below are general practice.

Every Docker image built on Debian or Ubuntu carries its own copy of apt. A Dockerfile that runs apt-get install during the build is an install event. That is the moment the flaw needs. CI runners that install packages on every job are in the same position.

• Rebuild from fresh base images. Pull the latest debian or ubuntu base image and rebuild. A cached base layer can still hold the old apt.
• Check the version inside an image. Run docker run --rm IMAGE_NAME dpkg-query -W apt and compare it to the table.
• Add the safety option until bases are updated. Put -o Acquire::Retries=0 on apt-get lines in Dockerfiles.
• Check internal mirrors and caching proxies. If builds pull through an internal proxy over HTTP, that proxy sits in the path.

Running containers that never install packages are lower risk, since the flaw needs an install. They still deserve a rebuild at the next release. Our explainer on containers covers how images and layers work. Our recent post on the SSHole OpenSSH flaw covers patching Alpine-based images. The Node.js October security release post covers runtime images.

Why the package path matters

Package managers are part of your supply chain. Our posts on package registry security and the npm supply chain show attackers going after the route software takes to your servers. This APT vulnerability is the same lesson at the operating system level. Trust lists are another weak point, as our post on distrusted eMudhra certificates shows.

Frequently Asked Questions