Ubuntu and Debian APT Flaw Could Let Attackers Bypass Package Verification and Run Code as Root

On November 4, 2026, Canonical released a fix for CVE-2026-109518, a vulnerability in APT, the tool Ubuntu and other Linux distributions use to download and install software. Fixed versions are also available for Debian. By abusing redirects and download retries, an attacker who can interfere with HTTP traffic, or a malicious package mirror, could trick a system into installing a package that has not passed verification. A successful attack could allow arbitrary code execution with root privileges.

The vulnerability was discovered by security researcher Max Justicz. According to Canonical's security advisory, it is rated "High" severity, with a CVSS 4.0 base score of 7.7. However, simply fetching packages over HTTP does not make an attack succeed. The traffic must be tampered with, a redirect and a download retry must occur, and the targeted .deb package must then be installed.

The cause was that APT did not handle hard links properly when processing downloaded files. As a result, verification of packages, which is normally protected by digital signatures and hash values, could be bypassed. Switching to HTTPS is an effective way to block attacks on the network path, but updating APT is necessary to eliminate the vulnerability itself. To install the fix safely, Canonical also describes a way to temporarily disable download retries during the update.

image

Ubuntu+1

How Reusing Hard Links Leads to a Verification Bypass

APT normally combines several checks to confirm that downloaded packages have not been tampered with. According to Ubuntu's official documentation, the digitally signed InRelease file records the hash of the Packages file, and the Packages file contains the hash of each individual .deb package. This chain of verification makes it possible to detect any change to a package's contents in transit. So even when packages are distributed over HTTP, APT does not unconditionally trust the files it fetches.

The flaw was not in this cryptographic verification scheme, but in the code that opens and writes the files APT downloads. The cause was the improper reuse of "hard links," which let multiple file names point to the same underlying file. Files joined by a hard link share the same data, so if you rewrite the contents through one file name, what the other name refers to changes as well.

According to an explanation by APT developer Julian Andres Klode, combining HTTP redirects with download retries after a temporary server error could, in some cases, allow an attacker to rewrite a file's contents through an existing hard link. Exploiting this, the attacker could replace the file's contents with data of their own after APT had verified it, causing an unverified .deb package to be installed. In other words, no digital signature private key or hash function was broken; the problem was that APT could not guarantee that the file it verified was the same as the file that was actually installed.

The fix can be seen in the change made to APT's source code. When opening the destination for a file fetched over HTTP, FileFd::Exclusive was added to prevent unintended rewrites through existing hard links. When a download is resumed, the existing file is opened read-only and the original link is removed, and a new destination file is created. The already-downloaded data is copied into it, and the file position is returned to the beginning in preparation for calculating the hash.

The purpose of this fix is to prevent changes to other files through the file APT has opened as a write destination. It does not change how package signatures or hashes are verified; instead, it ensures that the files being verified cannot be improperly rewritten through hard links. This prevents the installation of unverified packages by exploiting this vulnerability.

image

GitLab

The Attack Requires HTTP Traffic and Retries

To determine whether an environment is affected, you need to check the transport APT uses and its download retry settings. In addition to the ability to tamper with HTTP traffic, the attack requires APT to perform redirects and download retries. The number of retries is set by Acquire::Retries; when the value is 0, downloads are not retried, so the vulnerability cannot be exploited.

According to Canonical, on Debian 12 "bookworm" and Ubuntu 22.04 LTS "Jammy Jellyfish" and later, the default value of Acquire::Retries is 3. According to the APT developer's explanation, this default was introduced in APT 2.3.2. As a result, Ubuntu 22.04 LTS and later meet one of the conditions for the attack in their default configuration, while earlier releases normally have retries disabled.

That said, older releases are not necessarily safe. If an administrator has changed Acquire::Retries to a non-zero value in a configuration file or update script, older versions may also be affected. Conversely, even with retries enabled, the attack does not succeed unless the other conditions are met, such as interference with HTTP traffic or a malicious mirror, and actual installation of the package.

Because the vulnerability lies in the HTTP backend of the APT library, the scope of impact does not change between the command line and the GUI. In addition to apt, apt-get, and aptitude, Ubuntu's graphical software update tools, which use APT internally, are also affected. Snap, on the other hand, uses a package management mechanism separate from APT and is not affected by this vulnerability.

image

Ubuntu

The fixed versions for Ubuntu are summarized in security notice USN-8996-1, which Canonical published on November 4. Affected releases range from Ubuntu 26.10 back to 14.04 LTS, and a fixed APT version has been prepared for each. However, older LTS releases require Ubuntu Pro or an additional support contract, so you must check not only whether a fixed version exists but also whether you are actually in a position to receive the update.

For Debian as well, the fix status is published on the official security tracker. The fixed version is APT 2.6.2 for Debian 12 "bookworm" and 3.0.4 for Debian 13 "trixie." The development release "forky" and the unstable release "sid" are also fixed in 3.3.6.

image

Security Tracker

These versions indicate the APT version that includes the fix in each release. Because Ubuntu and Debian number their versions differently and backport fixes differently, you should not simply compare version numbers by size; instead, check against the fixed version for the release you are using. To check the versions of the packages installed from the APT source package, Canonical gives the following command.

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

On Ubuntu, automatic application of security updates through unattended-upgrades is enabled by default from 16.04 LTS onward. According to Canonical, if this feature is enabled, updates are applied within 24 hours of a fix being published. However, having an automatic update feature is not the same as having the fixed version actually installed. Updates can fail and settings can be changed, so it is important to check the versions of the installed packages.

Steps for Installing the Fix Safely

One thing to keep in mind when responding to this vulnerability is that what needs fixing is APT itself, which handles package downloads and installation. Because APT is being updated while the vulnerability is still present, you need to consider that an attack could succeed even during the process of installing the fixed version. Canonical's official explanation describes protecting communications with HTTPS and temporarily disabling download retries as mitigations.

Each measure plays a different role. HTTPS prevents tampering on the network path, and Acquire::Retries=0 stops the retries the attack needs. What actually fixes the vulnerability, however, is updating APT. Based on the fix commit and Canonical's explanation, the measures can be summarized as follows.

Using HTTPS prevents an attacker positioned on the network path from tampering with downloaded content. However, if the mirror that distributes the packages is itself malicious, HTTPS alone cannot prevent this problem. For that reason, Canonical recommends temporarily setting Acquire::Retries to 0 when installing the fixed version. This disables the retries the vulnerability requires, whether the attacker is on the network path or is a malicious mirror.

The command Canonical recommends for updating the entire system is as follows.

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

The first command, apt update, refreshes the package lists, and the following apt upgrade updates the installed packages. -o Acquire::Retries=0 applies to the latter apt upgrade and specifies that downloads should not be retried even if they fail. This setting is effective only while the command runs and does not permanently change APT's configuration files.

If updating the entire system is difficult, there is also a way to update only the APT-related packages first. The command Canonical gives is below.

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

This command updates the installed packages built from the APT source package. Because --only-upgrade is specified, it upgrades existing packages rather than adding new ones. With either method, after updating you should check the versions of the APT-related packages and confirm that the fixed version for your release has been installed.

If you switch to HTTPS to prevent tampering on the network path, also check APT's source settings. On Ubuntu, repository information is recorded in /etc/apt/sources.list and in the .sources and .list files in the /etc/apt/sources.list.d/ directory. Changing the http:// URLs in these settings to the corresponding https:// enables TLS protection of communications. However, some community mirrors do not support HTTPS, so after making the change you need to run apt update and confirm that the package lists can still be retrieved normally.

Switching to HTTPS is an effective mitigation against this vulnerability, but it is not a substitute for updating APT. Likewise, disabling retries is only a temporary measure for installing the fixed version safely. Ultimately, it is important to install the fixed version for the Ubuntu or Debian release you are using and to verify the versions of the APT-related packages.

This problem shows that even when package signatures and hash verification are designed correctly, flaws in the file handling before and after them can undermine security. Because a wide range of tools that use APT are affected, update status needs to be checked on both servers and desktops. Environments that use HTTP-based repositories and have download retries enabled, in particular, should prioritize applying the fixed version.