CVE-2026-109518: APT Flaw Enables MitM Root Code Execution

A high-severity vulnerability in APT, the package management system used by Debian, Ubuntu, and derivative Linux distributions, could allow an on-path attacker to replace a verified software package with a malicious one and execute arbitrary code with root privileges. Tracked as CVE-2026-109518, the flaw carries a CVSS 4.0 score of 7.7 and affects APT’s HTTP download and retry handling.

The vulnerability is caused by improper handling of hard links when APT follows HTTP redirects and retries failed package downloads. Under the right conditions, two different downloads can be merged after a redirect causes them to resolve to the same URI. An attacker able to manipulate traffic between an APT client and a repository can abuse this behavior to substitute an attacker-controlled .deb package after verification has already taken place.

Because Debian packages can execute installation scripts with root privileges, successful exploitation can result in complete system compromise. However, exploitation requires several conditions: the victim must initiate a package installation, APT must communicate over manipulable HTTP, and the Acquire::Retries option must be set to a non-zero value.

Ubuntu 22.04 LTS and newer releases are exposed by default because retries are enabled. Debian has similarly enabled retries by default since APT 2.3.2, including Debian 12. Older releases can still be vulnerable when administrators or automation scripts manually enable retries.

Contact Sales

The vulnerability was discovered by security researcher Max Justicz and publicly disclosed on November 4, 2026. Debian and Ubuntu released security updates on the same day. Neither vendor advisory currently reports exploitation of the flaw in real-world attacks.

Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to operationalize threat intelligence and strengthen defenses against software supply-chain attacks, package manager abuse, malicious payload execution, and post-compromise activity across SIEM, EDR, XDR, and Data Lake environments.

Detect CVE-2026-109518 by monitoring suspicious changes in package repository traffic, unexpected redirects or repeated package-download failures, anomalous package installations, and new privileged processes occurring immediately after APT activity.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-109518 analysis

CVE-2026-109518 affects APT deployments on Debian, Ubuntu, and derivative Linux distributions when package files are downloaded over an attacker-manipulable HTTP path and retry functionality is enabled. Ubuntu classifies the vulnerability as High with a CVSS 4.0 score of 7.7 and the vector CVSS:4.0/AV/AC/AT/PR/UI/VC/VI/VA/SC/SI/SA.

APT is responsible for downloading, verifying, and installing packages on Debian-based Linux systems. Package authenticity normally relies on Debian and Ubuntu repository signature mechanisms designed to ensure that packages delivered by mirrors cannot be silently modified by an untrusted intermediary.

CVE-2026-109518 breaks an important part of this trust model under specific download conditions.

The vulnerability occurs when APT handles HTTP redirects and retries. According to Debian’s advisory, APT can merge two separate package downloads when a redirect causes them to share the same URI. When a download subsequently needs to be resumed, incorrect handling of reused hard links can allow the content associated with an already verified package to be overwritten.

An attacker first needs the ability to manipulate HTTP traffic between the victim and the package archive. Potential positions include a malicious or compromised network intermediary, proxy, Wi-Fi network, or package mirror. Ubuntu explicitly includes malicious mirrors and proxies in its threat model.

The attacker can then use redirects together with transient HTTP errors to force APT into its retry path. When APT retries the package download, the flaw in hard-link handling can cause attacker-controlled data to replace content associated with a package that has already passed verification.

This allows the malicious package to bypass the protection normally provided by repository signatures.

The impact becomes particularly severe because .deb packages can contain maintainer scripts executed during installation. These scripts run with root privileges when packages are installed, meaning an attacker who successfully substitutes a package can execute commands with full system privileges.

The vulnerability does not mean that every Debian or Ubuntu host can be compromised remotely at any time. The attack requires the victim system to perform a package installation or upgrade while the attacker can interfere with the network path.

Another important prerequisite is Acquire::Retries.

APT uses this option to determine whether failed downloads should automatically be retried. The vulnerable behavior requires a value greater than zero. Debian’s APT developers state that retries have been enabled by default since APT 2.3.2, while Ubuntu confirms that Ubuntu 22.04 LTS and newer releases use a non-zero default value.

Older systems are therefore not necessarily safe. Although Ubuntu 20.04 LTS and earlier releases do not enable retries by default, custom configuration, deployment automation, or administrator scripts can set Acquire::Retries manually and make those systems exploitable.

The vulnerability exists in APT’s HTTP backend and therefore applies across APT-based frontends, including apt, apt-get, aptitude, and graphical Ubuntu applications that ultimately use the same underlying package management infrastructure. Snap packages are not affected because they use a different distribution mechanism.

HTTPS also changes the attack surface significantly. Ubuntu states that TLS protects against this vulnerability because the attacker must be able to modify HTTP traffic in transit. Package sources accessed exclusively over properly validated HTTPS are therefore protected from the documented on-path attack method. FTP and unrelated transport mechanisms are not affected by this specific issue.

The CVE-2026-109518 PoC situation should be interpreted carefully. Debian and Ubuntu’s official advisories do not link to a public exploit demonstrating full root compromise, and they do not report malicious exploitation in the wild. The technical information released by APT developers nevertheless explains enough of the redirect, retry, and hard-link behavior for defenders to understand the attack requirements.

The weakness is associated with improper hard-link handling and a time-of-check/time-of-use condition. The CVE record maps it to CWE-62, UNIX Hard Link, and CWE-367, Time-of-check Time-of-use Race Condition.

APT developers released fixed versions across multiple maintained branches:

APT branch	Fixed version
1.2.x	1.2.36
1.4.x	1.4.12
1.6.x	1.6.19
1.8.2.x	1.8.2.4
2.0.x	2.0.12
2.2.x	2.2.5
2.4.x	2.4.15
2.6.x	2.6.2
2.8.x	2.8.4
3.0.x	3.0.4
3.2.x	3.2.1

Debian 13 “Trixie” received APT 3.0.4, while Debian 12 “Bookworm” received version 2.6.2.

Ubuntu released the following corrected packages:

Ubuntu release	Fixed APT version
26.10	3.3.3ubuntu0.1
26.04 LTS	3.2.1ubuntu0.1
24.04 LTS	2.8.4ubuntu0.1
22.04 LTS	2.4.15ubuntu0.1
20.04 LTS	2.0.12+esm1
18.04 LTS	1.6.19+esm1
16.04 LTS	1.2.36+esm1
14.04 LTS	1.0.1ubuntu2.24+esm4

Updates for older Ubuntu releases require the applicable Ubuntu Pro or Extended Security Maintenance coverage.

For CVE-2026-109518 detection, security teams should correlate package-management activity with network and endpoint telemetry. Repeated HTTP redirects, transient download failures immediately followed by successful package retrieval, unexpected repository destinations, or package installation from unusual network paths can provide useful investigation pivots.

Endpoint monitoring should also identify unusual child processes spawned during or immediately after APT or dpkg execution. Because successful exploitation results in an attacker-controlled package being installed as root, suspicious shell execution, new services, altered system files, persistence mechanisms, user creation, credential access, or unexpected outbound connections following package installation should be treated as high-priority indicators.

APT and dpkg logs can provide additional context. Defenders should review /var/log/apt/, /var/log/dpkg.log, system journal records, proxy telemetry, DNS logs, and network security data around suspicious package operations. Comparing installed package versions and checksums against trusted distribution repositories can help identify unexpected modifications.

At present, vendor advisories provide no attacker infrastructure, malware hashes, or campaign-specific CVE-2026-109518 IOCs because Debian and Ubuntu have not reported active malicious exploitation. Behavioral monitoring is therefore more valuable than searching for a static IOC list.

CVE-2026-109518 Mitigation

The primary remediation is to install the updated APT package supplied by Debian, Ubuntu, or the relevant derivative distribution. Administrators should not rely solely on network controls because the corrected APT implementation prevents the package verification bypass at its source.

Ubuntu recommends updating all installed packages while explicitly disabling retries during the update process:

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

Organizations that cannot perform a complete system upgrade can target APT itself:

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

Setting retries to zero during this operation prevents the vulnerable retry path from being used while the security update itself is downloaded and installed.

Security teams should take the following steps:

1. Inventory Debian, Ubuntu, and derivative Linux systems using APT.
2. Identify the installed APT version and compare it with the vendor-fixed release.
3. Prioritize internet-connected systems and environments using untrusted, third-party, or community package mirrors.
4. Apply the vendor security update with Acquire::Retries=0.
5. Confirm that the corrected APT package is installed.
6. Review /etc/apt/sources.list and files under /etc/apt/sources.list.d/ for unexpected HTTP repositories.
7. Move package sources from HTTP to HTTPS where supported.
8. Review proxy and package mirror infrastructure for signs of compromise or unauthorized modification.
9. Investigate unexpected package installations that occurred before the fix was deployed.

Ubuntu confirms that changing package repositories to HTTPS provides protection against the documented attack because exploitation requires modification of HTTP traffic. Administrators should first verify that their selected repository mirrors support TLS and then run sudo apt update to ensure that the configuration operates without errors.

Using HTTPS should be treated as defense in depth rather than a substitute for updating APT. Systems may later use another repository, proxy, automation workflow, or HTTP endpoint, so installing the corrected package remains necessary.

Temporarily setting Acquire::Retries to zero provides another effective workaround against the documented exploitation condition. Since the flaw depends on APT retrying a failed download, disabling retries prevents the vulnerable code path from being reached. This setting can reduce package-download reliability, however, and should primarily be used while applying the actual security update.

Organizations using unattended upgrades should verify patch deployment rather than assuming every machine has already been corrected. Ubuntu notes that unattended-upgrades is enabled by default from Ubuntu 16.04 LTS onward and normally applies security updates within 24 hours, but fleet management, network restrictions, custom repository configurations, or disabled services can prevent successful installation.

If compromise is suspected, administrators should preserve APT, dpkg, proxy, network, and system logs before remediation. Review packages installed during the suspected exposure window, validate package provenance, inspect maintainer scripts, and investigate any root-level processes or persistence established immediately afterward.

Because a malicious package can run arbitrary commands as root, confirmed exploitation should be treated as full system compromise. Rebuilding the affected host from trusted media may be more reliable than attempting to remove individual artifacts, especially when the attacker could have modified system binaries, services, authentication configuration, or kernel-level components.