apt flaw CVE-2026-109518: what to do

Which apt version fixes CVE-2026-109518?

The apt flaw CVE-2026-109518 is closed by the package versions listed below, and apt-cache policy apt shows which version you have. Upgrade with -o Acquire::Retries=0 on the command, because the old apt downloads the new apt. APT (Advanced Package Tool) is the package manager on Debian and Ubuntu. A CVE (Common Vulnerabilities and Exposures) number is the public ID of one security flaw.

These are the Ubuntu versions from USN-8996-1, the Ubuntu Security Notice published on 4 November 2026. I read them on 5 November 2026.

• 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
• Ubuntu 20.04 LTS: 2.0.12+esm1 (needs Ubuntu Pro)
• Ubuntu 18.04 LTS: 1.6.19+esm1 (needs Ubuntu Pro)
• Ubuntu 16.04 LTS: 1.2.36+esm1 (needs Ubuntu Pro with the Legacy add-on)
• Ubuntu 14.04 LTS: 1.0.1ubuntu2.24+esm4 (needs Ubuntu Pro with the Legacy add-on)

These are the Debian versions from the Debian security tracker, read on the same day.

• Debian 13 (trixie): 3.0.4, from DSA-6607-1
• Debian 12 (bookworm): 2.6.2, from DLA-4880-1
• Debian forky and sid: 3.3.6

How do I check my apt version?

Refresh the package lists first, then ask apt what it has.

sudo apt update
apt-cache policy apt

Read two lines of the output. Installed: is the version on the server now. Candidate: is the version apt would install from your sources. A healthy result is an Installed: version equal to or higher than the fixed version for your release.

Version strings are hard to compare by eye, so let dpkg do it. Replace the last version with the fixed version for your release.

dpkg --compare-versions "$(dpkg-query -W -f='${Version}' apt)" ge 2.8.4ubuntu0.1 && echo patched || echo "not patched"

Canonical also gives a command that lists the installed packages built from the apt source:

apt list --installed '?source-package(^apt$)'

If Candidate: is lower than the fixed version, your sources do not offer the fix yet. The Version table: part of the output shows where each version comes from. Your mirror may not have the new package yet, or your sources may not include the security suite. On Ubuntu 20.04 and older, the fix is only in the Ubuntu Pro archives.

Is the upgrade of apt itself exposed?

Yes, unless you protect it. The flawed code is in apt's own download programs, such as /usr/lib/apt/methods/http, and these ship in the apt package. The new code does not run until the new package is installed, so the old code downloads the fix. I found no special case for apt's own package in the source. No advisory says this in these words. It follows from the file list and from the upstream fix, and it matches Canonical's advice to set Acquire::Retries to zero while installing the update.

How do I upgrade apt safely?

Canonical publishes two commands. This one is the recommended form, and it upgrades everything:

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

This one upgrades only the packages built from the apt source:

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

If your apt rejects the ?source-package pattern, use the first command. The -o flag sets a configuration option for that one command, so there is nothing to undo afterwards. With retries off, a failed download stops with an error and is not tried again. Run the command again if that happens.

Canonical wrote these commands for Ubuntu. -o and Acquire::Retries are general APT options, and Debian and Ubuntu share this code, so the same commands apply on Debian 12 and 13. The Debian advisories themselves name no mitigation.

Run apt-cache policy apt again. Installed: should now show the fixed version. The notice says "a standard system update will make all the necessary changes", and it names no reboot step.

Canonical says unattended-upgrades is on by default from Ubuntu 16.04 LTS and applies new security updates every 24 hours, so your server may already have the fix. Check the version instead of assuming it. An automatic run uses your normal configuration, so it does not get the -o option. If you are not sure the timer works, see how unattended-upgrades works on Ubuntu or why unattended-upgrades is not running on Debian.

What does an attacker need for this apt flaw?

USN-8996-1 credits Max Justicz with the discovery. It says APT handled hard links incorrectly when it met redirects and retried package downloads. A hard link is a second name for the same file on disk. The Ubuntu summary says APT "could be made to install unverified packages and run programs as an administrator".

The attacker must be on the path, which means they can change the HTTP traffic between your server and the archive. The CVE text includes a malicious mirror or proxy in this group. The attack needs two things to happen during a package install: apt must follow a redirect, and apt must retry a download. The apt announcement says transient HTTP errors trigger the retries.

The retry depends on your configuration. In apt's source, a transient error puts the file back in the queue only while Retries is not 0. So a non-zero Acquire::Retries is a required condition.

Why does a signed archive not stop this?

The signed Release file holds checksums, so apt can detect a changed package. The apt-secure man page describes this check. This flaw works around the check. The Debian advisory says "APT can merge two different package downloads after an HTTP redirect gives them the same URI", and that this lets an attacker replace a package after verification.

The upstream fix is titled "methods: Open target files exclusively". It makes the download programs open target files so that an existing link is not written through.

Is your Acquire::Retries value non-zero?

Do not assume the value. Read it.

apt-config dump | grep -i retries

If a line prints, that is the value your configuration sets. If nothing prints, this does not mean zero. It means no configuration file sets the option, so apt's built-in default applies. In apt's source that default is in the code (FindI("Acquire::Retries", 3)), and the default configuration setup does not set the key. The apt changelog shows that version 2.3.2 turned retries on by default, with a value of 3.

That gives this result per release:

• Ubuntu 22.04 LTS and newer, and Debian 12 and newer: affected in a default configuration.
• Ubuntu 14.04 to 20.04: affected only if Acquire::Retries is set to a non-zero value.

The apt announcement warns that many user scripts may have used this option on older releases. A script that passes -o Acquire::Retries=3 sets the value only for its own command, so apt-config dump cannot show it. Search your own scripts and CI (continuous integration) jobs for Acquire::Retries.

Do Acquire::Retries=0 or AllowRedirect=false close the path?

-o Acquire::Retries=0 does, as a temporary measure. Canonical says: "If this is set to 0, no downloads are retried and the vulnerability cannot be exploited." The source agrees, because the retry branch needs Owner->Retries != 0. It is a mitigation for the upgrade. The fix is the new package.

-o Acquire::http::AllowRedirect=false is not confirmed, so do not rely on it. The option is real. It is on by default, and setting it to false stops the HTTP method from following redirects. But neither Canonical nor the apt announcement names it as a mitigation. The upstream fix also changed how apt resumes a partial download, so the sources do not settle whether the flaw needs a redirect in every case. The setting is per method, and a separate https entry exists. Mirrors that redirect would also start to fail with an HTTP error. Use Acquire::Retries=0.

What do HTTPS sources protect against?

HTTPS protects you from an on-path attacker. Canonical says: "The use of TLS via HTTPS protects against this vulnerability." TLS (transport layer security) stops a third party from changing the traffic. apt's source also refuses a redirect from https to http, with the error Redirection from https to '...' is forbidden, so an attacker cannot use a redirect to move you back to plain HTTP.

HTTPS does not protect you from a malicious mirror. Canonical says "A malicious package mirror can similarly exploit the vulnerability". This next step is my reasoning, not a vendor sentence: the mirror is the other end of the TLS connection, so it can send the redirects and errors itself. Canonical also says that once you update the apt client, "compromised mirrors no longer pose a risk". This is why you should update even if your sources already use HTTPS.

See what your sources use:

grep -rhE '^(URIs:|deb )' /etc/apt/sources.list /etc/apt/sources.list.d/

Canonical gives this command to move the standard Ubuntu hosts to HTTPS:

sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
sudo apt update

If one of those file patterns matches nothing, sed reports that it cannot read that name and still changes the other files. Read the apt update output for errors, because Canonical warns that some community mirrors, including some country mirrors, do not support HTTPS. On Debian, the SourcesList wiki page shows both http:// and https:// examples for deb.debian.org, so check your own files.

What does the Ubuntu CVE page status mean?

I read Ubuntu's CVE page on 5 November 2026. It listed every Ubuntu release as fixed, with priority High and a CVSS (Common Vulnerability Scoring System) v4.0 score of 7.7. The tracker data was last updated at 20:50 UTC on 4 November. The page changes when the tracker changes, so a status you saw earlier, or a status in a scanner report, may not match what you read here. Decide from your Installed: line and the fixed version. To check a server for other open issues, see how to check your server for known CVEs.

What if my release is old?

Ubuntu 20.04 and 18.04 get the fix through Ubuntu Pro. Ubuntu 16.04 and 14.04 need Ubuntu Pro with the Legacy add-on. Ubuntu's Pro page says Pro is free for personal use on up to 5 physical machines, or 50 machines for official Ubuntu Community members. For the setup, see Ubuntu Pro on a server explained.

The Debian tracker does not list Debian 11 (bullseye) for this CVE, but a fixed package exists: Freexian's ELA-1880-1 lists 2.2.5 for bullseye. It is part of Extended LTS, a paid Freexian service with a private repository. The CVE text says releases older than Debian 12 are unaffected in a default configuration, so check Acquire::Retries as shown above. The longer answer is to move off that release, and the Debian 11 upgrade path covers it.

FAQ

Which apt version fixes CVE-2026-109518 on Ubuntu 24.04?

USN-8996-1 lists 2.8.4ubuntu0.1 for Ubuntu 24.04 LTS. Run apt-cache policy apt and compare the Installed: line with that version. For Debian 13 the fixed version is 3.0.4, and for Debian 12 it is 2.6.2.

Does Acquire::Retries=0 fix CVE-2026-109518?

It is a temporary mitigation, and the fix is the new apt package. Canonical says that with the value 0, no downloads are retried and the flaw cannot be exploited. Use it on the upgrade command: sudo apt update && sudo apt upgrade -o Acquire::Retries=0.

Is the apt upgrade itself exposed to this flaw?

Yes, unless you mitigate it. The old download programs in the installed apt package fetch the new package, so the fixed code cannot help until the install ends. Set -o Acquire::Retries=0 on the upgrade command, or use HTTPS sources from a mirror you trust.

Do HTTPS apt sources protect me from CVE-2026-109518?

They protect you from an on-path attacker, according to Canonical. They do not help if the mirror itself is malicious, because the mirror is the other end of the encrypted connection. Updating the apt client removes the risk from compromised mirrors, so update in both cases.

Does Ubuntu 20.04 need Ubuntu Pro for this fix?

Yes. USN-8996-1 lists 2.0.12+esm1 for Ubuntu 20.04 LTS as a fix available with Ubuntu Pro. In a default configuration, that release is affected only if Acquire::Retries is set to a non-zero value. Run apt-config dump | grep -i retries, and also search your own scripts for that option.