APT vulnerability CVE-2026-109518 in Debian and Ubuntu: affected versions, fix and hardening

Have Linux servers patched and package sources secured? WZ-IT handles patching and hardening in Linux server management from EUR 149.90 net per month for the first server and assesses new vulnerabilities in CVE monitoring. Book an intro call

On 4 November 2026, Debian and Ubuntu released security updates for the APT package manager. CVE-2026-109518 concerns the HTTP download of packages: an attacker who can manipulate the HTTP traffic between a system and its package archive, for example through a malicious mirror or proxy, can make the client install an unverified package. The package’s scripts run as root during installation. Canonical rates the flaw CVSS 4.0 7.7 (High), the APT team calls it “critical”.

APT here is the package manager apt, not a threat group. All programs that use the APT library are affected: apt, apt-get, aptitude and graphical front ends (Ubuntu). This article lists the fixed versions per distribution, the conditions for an attack, the check commands for admins and the order in which APT can be updated safely. That includes Proxmox VE. All information is as of 9 November 2026.

Table of contents

1. The vulnerability at a glance
2. How a verified package can be swapped
3. When a system is exposed
4. Fixed versions for Debian
5. Fixed versions for Ubuntu
6. Proxmox VE and other Debian-based systems
7. Checking: APT version, package sources and retries
8. Patching: the right order
9. Hardening: switch package sources to HTTPS
10. Check automatic updates and images
11. Exploit status and assessment
12. Common misconceptions
13. Status and methodology
14. Our approach at WZ-IT
15. Further guides

The vulnerability at a glance

Sources: CVE record, Debian Security Tracker, Ubuntu, Ubuntu blog, APT announcement, fix commit.

On the metrics (CVSS 4.0 specification): AT:P means that specific conditions must exist on the target system; according to the vendors these include Acquire::Retries other than 0 and manipulable HTTP traffic. UI:P means passive, involuntary interaction: the package installation triggers the attack without anyone deliberately intervening. No login and no privileges are needed (PR:N), and the impact on the attacked system is high for all three protection goals.

How a verified package can be swapped

The signature scheme of an archive normally prevents package tampering even with HTTP transport (Ubuntu). With CVE-2026-109518 the attack hits a different spot, namely the file handling of the download. The sources describe it in different words:

What the descriptions have in common is the chain of redirect, transient error, retry of the download and hard link. The integration test that comes with the fix downloads a file onto a hard link to a victim file, onto a hard link to a partially downloaded file (resume, HTTP status 206) and onto a symlink, and checks each time that the victim file stays unchanged.

How exactly the wordings “replaced after verification” and “fails signature verification” relate to each other is not clear from the public sources. We have found no technical write-up by the discoverer up to 9 November 2026. Our assessment: in practice this changes nothing. Signature verification alone does not protect against this flaw, and the fix lies in APT’s file handling.

Background: in 2019 the same researcher reported a similar class of bug with CVE-2019-3462, at that time in APT’s handling of HTTP redirects. In his 2019 write-up the workaround was to disable redirects during the update. For CVE-2026-109518 the vendors name Acquire::Retries=0 and HTTPS instead.

When a system is exposed

The flaw is not an attack “from the internet on every server”. The attacker needs a position in the path of the packages.

The default value of Acquire::Retries has been 3 since APT 2.3.2 (APT changelog: “Enable the Acquire::Retries option by default, set to 3”). It applies from Debian 12 and Ubuntu 22.04. Older releases are not affected in their default configuration (Debian tracker).

What this means in typical environments:

• Servers with default sources over HTTP: The attacker has to sit in the data path. Our assessment: that could be a compromised router, a shared network segment or a network operator. The more third-party networks the packages cross without HTTPS, the easier that position is to reach.
• Mirrors and proxies: The CVE record explicitly names malicious mirrors and proxies. Our assessment: internal mirrors (for example aptly, Artifactory), caching proxies (for example apt-cacher-ng, Squid) and corporate proxies are part of the data path; we have not checked the products individually. Whoever addresses them over HTTP leaves the stretch between client and intermediary unprotected, and a compromised mirror can exploit the flaw directly.
• Malicious mirror over HTTPS: Ubuntu names HTTPS only against the attack in the data path. Against a malicious mirror Ubuntu names Acquire::Retries=0 and the update.
• Containers and templates: An image or VM template based on Debian or Ubuntu can contain an older APT version, namely the one installed when it was built; images without a package manager contain none. Our assessment: as long as the base image is not updated and the build does not update APT as its first step, apt-get in the build runs with the old version.
• Older releases: As soon as someone has set Acquire::Retries to a value other than 0 in a script, a CI configuration or an Ansible role and the other requirements are met, the flaw applies there too. The APT team points out that many user scripts may have used the option on older releases.

Fixed versions for Debian

Sources: Debian Security Tracker, Freexian ELTS tracker. On 9 November 2026 the package indexes of security.debian.org (amd64 and arm64) listed APT 3.0.4 for trixie-security and APT 2.6.2 for bookworm-security. The table gives the fixed versions according to the tracker, not a statement on availability for every architecture.

The CVE record and the Debian Security Tracker name APT 3.3.6 as the fix in the development branch (unstable); stable releases get 3.0.4 and 2.6.2. The APT team provides fixes for the branches 1.2.y to 3.2.y: 1.2.36, 1.4.12, 1.6.19, 1.8.2.4, 2.0.12, 2.2.5, 2.4.15, 2.6.2, 2.8.4, 3.0.4 and 3.2.1 (APT announcement).

Debian 11 ended its regular LTS phase on 31 August 2026 (Debian). The fix (APT 2.2.5, ELA-1880-1) is provided by Freexian through its commercial Extended LTS offering (ELTS); ELTS is a service run by Freexian and is not part of the Debian project (Freexian FAQ). The dates for all distributions are in the guide Linux end of life.

Fixed versions for Ubuntu

Sources: USN-8996-1, Ubuntu CVE page. On 9 November 2026 the amd64 package indexes of security.ubuntu.com listed exactly these versions in the security suites of jammy, noble and resolute.

Ubuntu 22.04 and newer are affected by default (if the other requirements are met). Older releases are affected only if Acquire::Retries is set to a value other than 0 (Ubuntu blog).

Proxmox VE and other Debian-based systems

Proxmox VE uses APT like any Debian system (Proxmox, Package Repositories). The fix therefore comes from the Debian repositories: the amd64 package indexes of pve-no-subscription for trixie and bookworm that we checked contain no apt package (own check on 9 November 2026).

Four points matter for Proxmox hosts:

• Sources: The Proxmox documentation for Proxmox VE 9 lists the Debian base repositories with http://deb.debian.org/debian/ and http://security.debian.org/debian-security/, the no-subscription repository with http://download.proxmox.com/debian/pve. The enterprise repository uses https://enterprise.proxmox.com/debian/pve. A host with these default sources and the default Acquire::Retries 3 meets the requirements HTTP and retries on the host; all that is missing is an attacker in the data path (or a controlled mirror) and a running package installation.
• HTTPS: On 9 November 2026, deb.debian.org and security.debian.org served their release files over HTTPS. For download.proxmox.com, the certificate did not cover the host name in our check (certificate for enterprise.proxmox.com), so HTTPS is not readily possible there. For hosts with the no-subscription repository, the update remains the decisive step.
• Update path: Proxmox recommends apt update and apt full-upgrade or the web interface; a plain apt upgrade can lead to a partially upgraded or broken package state (Proxmox, Host System Administration). Proxmox VE checks for updates daily and notifies the user root@pam by email if mail delivery of the host is set up (Proxmox, Package Repositories); updates are installed through the web interface or the command line.
• Guests: A guest running Debian or Ubuntu, whether VM or LXC container, has its own APT, provided it is installed there. Updating the host changes nothing about APT in the guests.

We found no Proxmox notice on CVE-2026-109518 up to 9 November 2026. The CVE record also names derived distributions; there, the installed APT version and the state of the respective vendor are what counts. Support for operations is available on the pages Proxmox consulting and operations and Managed Proxmox.

Checking: APT version, package sources and retries

1. Installed APT version and comparison with the fixed version

dpkg -l apt
dpkg-query -W -f='${Package} ${Version}\n' apt
apt-cache policy apt

Installed must be at least the fixed version of the distribution. Candidate shows the available version after apt update. The comparison can be scripted (set fixed per release from the tables):

fixed=3.0.4   # trixie; bookworm: 2.6.2, noble: 2.8.4ubuntu0.1, jammy: 2.4.15ubuntu0.1
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' apt)" ge "$fixed" && echo "fixed version reached" || echo "fixed version not reached"

The comparison only checks the version number of the apt package against the fixed version of its own release branch. If the query fails or the system comes from a different branch (derived distribution, backport), the result is not meaningful; the distribution’s tracker entry then applies. On Ubuntu, Canonical additionally names apt list --installed '?source-package(^apt$)', which also shows the packages belonging to the source package.

2. Find package sources using HTTP (classic .list files and deb822 .sources files)

grep -rniE --include='*.list' --include='*.sources' \
  '^[[:space:]]*(deb|deb-src)[[:space:]]+(\[[^]]*\][[:space:]]+)?(mirror\+)?http://|^[[:space:]]*URIs:.*(mirror\+)?http://|^[[:space:]]+(mirror\+)?http://' \
  /etc/apt/sources.list /etc/apt/sources.list.d/

The expression finds lines in the one-line format (also with options in square brackets), URIs: lines in the deb822 format (also with several addresses) and continuation lines that start with an address. It reads only *.list and *.sources files, and commented-out lines are ignored. This is a first visual check, not a complete inventory: source blocks with Enabled: no also appear in the output. In addition, apt-cache policy shows the sources in the package cache; its state corresponds to the last apt update:

apt-cache policy | grep -E '^ +[0-9]+ http://'

3. Retries, proxy and redirects

apt-config dump | grep -iE 'retries|proxy|allowredirect'
grep -rniE 'retries|proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d/ 2>/dev/null

apt-config dump shows the effective configuration, including some values that APT sets itself at startup. Acquire::Retries is not one of them: if the entry is missing from the output, the built-in default 3 applies on releases from Debian 12 and Ubuntu 22.04, while on older releases a missing entry means no retries. This follows from the APT source code in version 3.0.4, which reads the value with FindI("Acquire::Retries", 3) whenever a download item is created, without writing it into the configuration. A proxy entry (Acquire::http::Proxy) with an address points to an intermediary in the data path. The value DIRECT switches the proxy off, and host-specific settings (Acquire::http::Proxy::<host>) can change it for individual hosts (apt-transport-http(1)).

4. Has APT already been updated?

zcat -f /var/log/apt/history.log* | awk '
  /^Start-Date:/ { d = $0; c = "" }
  /^Commandline:/ { c = $0 }
  /^Upgrade:/ && / apt:[a-z0-9]+ \(/ { print d; if (c != "") print c; print $0; print "" }'

For each upgrade of the apt package, the output shows the time (Start-Date), the logged call (Commandline, if present) and the Upgrade line with old and new version, including from rotated logs. An entry with Commandline: /usr/bin/unattended-upgrade shows that unattended-upgrade performed the upgrade. Whether the call came from the timer or was started by hand is shown by comparing the time with the journal of the apt-daily* services. Whether the fix is complete is shown by the installed version (command 1).

Patching: the right order

The problem with the order: APT downloads its own fix using the vulnerable version. Ubuntu recommends switching off download retries for the update and, where possible, enabling HTTPS beforehand. Against an attacker in the data path, TLS in place before installing ensures, according to Ubuntu, that there is no point in time at which the attacker could still exploit the flaw; against a malicious mirror, Ubuntu names switching off retries during the update (Ubuntu blog).

Step 1: Take inventory. APT version, distribution and package sources of all servers, plus container base images and templates (section Checking).

Step 2: Switch HTTP sources to HTTPS where possible (next section). Sources that do not offer HTTPS stay on HTTP; steps 3 and 4 apply to them.

Step 3: Secure automatic runs before APT is updated. Our recommendation: create a configuration file before the update, so that the preceding apt update and the unattended-upgrades run also work without retries.

echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518-retries

Whether the value is effective is shown by apt-config dump | grep -i retries. Later configuration files in /etc/apt/apt.conf.d/, the main file /etc/apt/apt.conf and command-line options can override it (reading order according to apt.conf(5)).

Step 4: Update APT with retries switched off. The command for the whole system comes from Ubuntu and also works on Debian:

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

The option -o Acquire::Retries=0 applies only to the call it is attached to, here apt upgrade, not to the preceding apt update; apt update uses the configured setting, which with the file from step 3 is 0.

If not all packages should be updated, Canonical names the targeted call for all packages of the source package apt, which includes the associated libraries:

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

If the installed APT version does not know the selector, the full update remains. On Proxmox hosts, the Proxmox recommendation apt full-upgrade applies instead of apt upgrade; the targeted call with the selector is the first step there, and the full update follows in the maintenance window.

Step 5: Verify and record the result. Check the version with the comparison from the Checking section and document it per host.

Step 6: Remove temporary settings. Delete the file from step 3 again. The setting that applied without the file then applies again: the default or a value from another configuration file. apt-config dump | grep -i retries shows whether a value is set there.

sudo rm /etc/apt/apt.conf.d/99-cve-2026-109518-retries

Step 7: Update images and templates. Replace base images with updated versions or update APT as the first build step, for example:

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

If APT in the base image does not know the selector, the build aborts with an error message; use apt-get -o Acquire::Retries=0 upgrade -y in that case.

The advisories contain no indicators of compromise. The update closes the flaw but does not undo an exploitation that has already happened. Our assessment: on servers that downloaded packages over insecure networks before the update, a look into /var/log/apt/history.log for unplanned installations is worthwhile.

Hardening: switch package sources to HTTPS

Ubuntu recommends TLS as a mitigating measure before the update and, after the update, as a precaution. According to Ubuntu, the signature scheme remains the stronger protection because it verifies end to end and not only the transport (Ubuntu blog). TLS protects the connection to the respective server, that is against an attacker in the data path; it does not protect against a malicious mirror. APT follows redirects from http to https but refuses redirects from https to http (according to the APT source code in version 3.0.4; the same rule applies in 2.6.2). An HTTPS source therefore cannot be downgraded to HTTP via a redirect.

For the official Debian archives, deb.debian.org and security.debian.org served their release files over HTTPS on 9 November 2026. Backing up the configuration, switching and testing:

sudo cp -a /etc/apt /root/apt-backup-$(date +%F)
sudo find /etc/apt -maxdepth 2 -type f \( -name '*.list' -o -name '*.sources' \) \
  -exec sed -Ei 's!http://(deb|security)\.debian\.org([/[:space:]]|$)!https://\1.debian.org\2!g' {} +
sudo apt update

The command changes one-line files (.list) and deb822 files (.sources) alike, but only the hosts deb.debian.org and security.debian.org; other host names (including ones that merely start with these names) and addresses with a port stay unchanged. On Ubuntu, Canonical uses this command, which switches the official Ubuntu archives and their country mirrors (de.archive.ubuntu.com):

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

This expression does not check the end of the host name; a host name that starts with one of the names given (for example archive.ubuntu.com.example.net) would be switched as well. Afterwards apt update must run without errors. According to Ubuntu, some community mirrors, including country-specific ones, do not offer HTTPS. In that case the mirror stays on HTTP, or the source moves to an official mirror. Own mirrors and caching proxies should provide HTTPS to clients or be reachable only from a trusted network segment; that is our assessment.

Check automatic updates and images

unattended-upgrades. Ubuntu states that unattended-upgrades has been enabled by default there since Ubuntu 16.04 and applies security updates every 24 hours; with the service enabled, the fixes for this flaw are applied automatically within 24 hours of becoming available (Ubuntu blog). That describes the normal case, not a guarantee: held or excluded packages, sources that are not allowed, a powered-off system or a failed run prevent the installation. On Debian the package can be missing or disabled; it is enabled with dpkg-reconfigure unattended-upgrades (Debian Wiki). The state can be checked:

dpkg-query -W unattended-upgrades
apt-config dump | grep -E 'APT::Periodic'
systemctl list-timers 'apt-daily*'
apt-mark showhold

APT::Periodic::Unattended-Upgrade "1" and APT::Periodic::Update-Package-Lists "1" are the prerequisite for the daily run, and the value 0 switches the respective action off (Ubuntu documentation). The two values alone do not prove that the automation works: systemctl list-timers shows when the timers last ran and will run next, and the logs in /var/log/unattended-upgrades/ show the individual runs. In addition, the security sources must be listed in Unattended-Upgrade::Allowed-Origins or Unattended-Upgrade::Origins-Pattern (unattended-upgrades README), and packages in the Package-Blacklist are not upgraded (according to the Ubuntu documentation). apt-mark showhold lists packages that are on hold; if apt appears there, it is not updated automatically. Whether unattended-upgrade applied the update is shown by the awk command from the Checking section. How automation, reboots and evidence fit together as one process is described in the guide Linux patch management.

Containers and templates. A container image based on Debian or Ubuntu can contain an older APT version, namely the one installed when it was built; images without a package manager contain none. If apt-get install in the build runs over an HTTP source, the same requirement applies to this step as on a server. Check the base images of pipelines, self-built golden images and VM templates (for example for Proxmox), as well as long-running containers in which packages are installed later.

Exploit status and assessment

Our assessment: the flaw is dangerous because success undermines signature verification and leads to root, but it is not trivially reachable because the attacker has to be in the data path. Priority is highest for servers that fetch packages over HTTP through untrusted networks or through a mirror or proxy that others can influence. With HTTPS-only sources and a trusted mirror the risk is lower; the update still belongs in the next maintenance window. The fix commit with its test is public, which lowers the bar for attackers to reproduce the flaw. Audit and “patch” scripts from third parties, which we have not reviewed, are circulating on GitHub; for production systems, the distribution’s updates are what counts.

Common misconceptions

• “Anyone on the internet can take over my server now.” No. The attacker needs a position in the HTTP data path or a malicious mirror or proxy, and a package must currently be installed.
• “GPG signatures protect me anyway.” Not for this flaw. The sources describe that a package bypasses the verification or is swapped after it.
• “With HTTPS the matter is settled.” HTTPS protects against the attack in the data path on the connection to a trusted server. Against a malicious mirror it does not replace the update.
• “APT 3.3.6 is the fixed version.” That is the development branch. Debian stable and Ubuntu have their own versions (see the tables).
• “Debian 11 and Ubuntu 20.04 are safe because retries is 0 there.” Only in the default configuration. Anyone who set Acquire::Retries to a value other than 0 can be affected. The fixes for both releases come through Freexian ELTS and Ubuntu Pro respectively.
• “This is the PHP2Shell flaw.” No. PHP2Shell carries CVE-2026-109618 and CVE-2026-109619 and affects PHP. CVE-2026-109518 affects APT.

Status and methodology

As of 9 November 2026. The basis is the CVE record and the NVD data set, the advisories DSA-6607-1, DLA-4880-1 and USN-8996-1, the Debian Security Tracker, the Freexian ELTS tracker, the Ubuntu blog, the APT team’s announcement and the fix commit. Information on the package indexes of security.debian.org (amd64 and arm64) and security.ubuntu.com (amd64), on the absence of an APT package in the amd64 indexes of the Proxmox pve-no-subscription repository, on the HTTPS availability of the hosts named and on the certificate of download.proxmox.com comes from our own queries on 9 November 2026. We tested the commands using grep, sed and awk on sample files; the others are standard APT, dpkg and systemd calls. Our own assessments are marked as such in the text. Later changes to vendor information are not reflected in this version.

Our approach at WZ-IT

For managed Linux servers we proceed in this order when such an advisory appears:

1. Record the inventory: distribution, APT version, package sources (HTTP or HTTPS), Acquire::Retries, proxy or mirror and the state of automatic updates, plus container base images and templates.
2. Prioritise: hosts with HTTP sources over untrusted networks and hosts with a mirror or proxy first, then the rest of the estate.
3. Secure before the update: HTTPS sources where the mirror offers them, otherwise Acquire::Retries 0 for a limited time.
4. Update and evidence: APT to the fixed version, document the version per host, remove temporary settings.
5. Secure permanently: sources on HTTPS where the mirror offers it, the state of unattended-upgrades in monitoring and new distribution advisories in CVE monitoring.

Linux server management covers patching, hardening, monitoring with response according to the service level and backup management, from EUR 149.90 net per month for the first server. Anyone who first just wants to know where they stand can use the server audit, which among other things checks the patch level. With Managed Proxmox, Proxmox VE, kernel and packages are part of patch management in agreed maintenance windows. Support, consulting and implementation by WZ-IT.

Further guides

• Linux patch management: process, deadlines and evidence, automation, reboots and documentation.
• Linux end of life: support end of Debian, Ubuntu and CentOS, dates for Debian 11 and Ubuntu 20.04.
• Linux server hardening: checklist based on CIS and BSI, further measures on the host.
• Linux kernel vulnerabilities 2026: patch management is a board-level matter, assessment for decision makers.
• pedit COW and DirtyClone: Linux kernel flaws in 2026, patching Linux fleets against privilege escalation.
• Why companies need CVE monitoring, how vulnerabilities are tracked in a structured way.
• PHP2Shell: CVE-2026-109618 and CVE-2026-109619, the PHP flaws with a similar number.
• UEFI vulnerability CVE-2026-97631 (EDK II, PXE), another current flaw related to server reboots.
• Proxmox consulting and operations, the hub for Proxmox topics.
• Linux server management and CVE monitoring, the hubs for operations and vulnerability management.
• SSHole (CVE-2026-123158): check OpenSSH on Alpine - another current security case (as of November 2026)
• Linux kernel TCP flaw CVE-2026-98432: patch Proxmox, Debian, Ubuntu - another current security case (as of November 2026)
• CWPdoor: check for the Control Web Panel backdoor - another current security case (as of November 2026)
• Node-RED editor without adminAuth: CVE-2026-58115 (Siemens IoT2050) - another current security case (as of November 2026)

Have the APT status of your servers checked? We compare version, package sources and update automation with the fixed versions, apply the update and switch the sources to HTTPS where the mirror offers it. Book an intro call

Sources

• CVE record CVE-2026-109518
• NVD, CVE-2026-109518
• CVE record API, CVE-2026-109518 (including the CISA ADP assessment)
• FIRST, CVSS v4.0 Specification Document
• Debian Security Tracker, CVE-2026-109518
• Debian DSA-6607-1, apt
• Debian DLA-4880-1, apt
• Freexian ELTS tracker, CVE-2026-109518
• Freexian, Extended LTS FAQ
• Debian, information on Debian 11 bullseye (end of LTS)
• APT team, APT-2026-11-01 security update
• APT fix commit 5af16a8a, methods: Open target files exclusively
• oss-security, CVE-2026-109518: RCE in apt(1) (DSA 6607-1)
• Ubuntu, CVE-2026-109518
• Ubuntu Security Notice USN-8996-1
• Ubuntu blog, CVE-2026-109518 APT vulnerability fixes available
• APT changelog (entry 2.3.2, Acquire::Retries)
• APT source code 3.0.4, apt-pkg/acquire-item.cc
• APT source code 3.0.4, methods/basehttp.cc
• Debian manual page apt.conf(5)
• Debian manual page apt-transport-http(1)
• Proxmox VE, Package Repositories
• Proxmox VE, FAQ (versions and end of support)
• Proxmox VE, Host System Administration (system updates)
• Debian Wiki, UnattendedUpgrades
• Ubuntu Server, Automatic updates
• unattended-upgrades, README (Allowed-Origins, Origins-Pattern)
• CISA, Known Exploited Vulnerabilities Catalog
• Debian Security Tracker, CVE-2019-3462
• Max Justicz, Remote Code Execution in apt/apt-get (2019)