A newly patched flaw in APT, the package manager at the heart of Debian, Ubuntu and their many derivatives, could let anyone sitting on the network path slip an unverified package past signature checks and run code as root. Fixes landed on 4 November 2026, and the tool you would normally use to install them is the very component that needs fixing.
What happened
On 4 November 2026 the Debian security team, Canonical and the upstream APT maintainers disclosed CVE-2026-109518, a weakness in the way APT fetches package files over HTTP. Debian issued DSA-6607-1 for Debian 13 (trixie) and DLA-4880-1 for Debian 12 (bookworm), while Canonical published USN-8996-1 together with a detailed blog post covering every Ubuntu release from 14.04 to 26.10.
The bug was found and responsibly reported by Max Justicz, the researcher behind CVE-2019-3462, an earlier APT redirect flaw that also ended in root code execution. Canonical rates the new issue High and scores it 7.7 under CVSS 4.0, while SecurityOnline reports that the APT developers rated it critical in their own advisory. There are no public reports of exploitation in the wild.
Because APT sits underneath apt, apt-get, aptitude and the graphical software centres, every front end that uses its HTTP transport is in scope. Canonical notes that snap packages are unaffected, as are HTTPS and FTP transports.
The technical picture
Debian and Ubuntu archives are commonly served over plain HTTP. That has long been considered acceptable because integrity does not depend on the transport: APT checks each downloaded file against cryptographically signed repository metadata before anything is installed. CVE-2026-109518 undermines that model by opening a gap between the moment a file is verified and the moment it is used.
According to the Debian security tracker, the root cause is the reuse of hard links. Coverage of the advisories describes an attacker who controls the HTTP traffic steering downloads with redirects and forcing retries with server errors, so that APT can end up treating two different downloads as the same file on disk. The practical effect, as Canonical puts it, is that APT can be tricked into installing a package “even if it fails signature verification”. Since maintainer scripts inside a .deb run with root privileges, a successful attack means full compromise of the host.
Several conditions have to line up. The attacker needs to be able to manipulate HTTP traffic between the client and the archive, which covers a hostile or compromised mirror, a rogue proxy, or someone positioned on a shared network. The client must be installing a package at the time, and it must be configured to retry failed downloads. That last point is decisive: the Acquire::Retries setting has defaulted to 3 since Debian 12 and Ubuntu 22.04 LTS, so those releases and everything newer are exposed out of the box. Older releases are only affected if an administrator has switched retries on.
The upstream fix in APT 3.3.6 makes download methods open their target files exclusively, so two transfers can no longer write to the same file. It also rejects .deb files missing a Version field and fixes several out-of-bounds bugs.
Why it matters for UK organisations
Debian and Ubuntu are everywhere in UK estates: cloud instances, container images, CI runners, developer laptops, appliances and a long tail of edge devices. Many of these pull packages from default HTTP mirrors, and many sit behind caching proxies that nobody has reviewed in years.
The on-path requirement narrows the threat but does not remove it. Shared office networks, conference and hotel Wi-Fi, compromised home routers used by remote staff, and third-party mirrors all fit the description. For organisations that run internal package mirrors or proxies, the mirror itself becomes a high-value target, because whoever controls it could push code to every machine that trusts it.
Under the Cyber Essentials requirements for security update management, high and critical fixes must be applied within 14 days of release, and a High-rated flaw scoring 7.7 in the software that delivers every other update is exactly the kind of item assessors will expect to see closed. Firms likely to fall within the Cyber Security and Resilience Bill, particularly managed service providers, should also expect questions about how they secure the software supply path into customer environments.
Expert view
In my experience, package management is one of those layers that teams trust implicitly. When we test Linux estates, the repository configuration is rarely in scope, and HTTP sources are often waved through on the reasonable basis that signatures do the heavy lifting. This flaw is a useful reminder that a signature check is only as good as the guarantee that the bytes you checked are the bytes you install.
I would not overstate the exposure. An attacker needs a genuine position on the network path or control of a mirror, plus a target that is actively installing packages, and there is no sign of exploitation. For most well-run cloud workloads talking to provider-hosted mirrors, this is a sensible routine patch rather than a fire drill. The risk is sharper for laptops on untrusted networks, for build infrastructure that installs packages constantly, and for anyone relying on unvetted community or regional mirrors.
The awkward part is the bootstrap problem. The fix is delivered by the component that is broken, over the same transport that is being abused. Canonical addresses this directly, and it is worth following its guidance rather than simply running a routine upgrade from wherever the machine happens to be.
What to do now
- Patch APT first. On Debian, the security tracker lists apt 2.6.2 for bookworm and 3.0.4 for trixie as fixed, with 3.3.6 in unstable; testing (forky) was still on vulnerable 3.3.5 at the time of disclosure. On Ubuntu, fixed builds include 2.4.15ubuntu0.1 (22.04 LTS), 2.8.4ubuntu0.1 (24.04 LTS), 3.2.1ubuntu0.1 (26.04 LTS) and 3.3.3ubuntu0.1 (26.10), with 14.04 to 20.04 covered through Ubuntu Pro ESM.
- Update from a trusted position. Apply the fix from a network you control, and follow Canonical’s advice to disable download retries for the duration of that one update so the vulnerable code path cannot be triggered.
- Move sources to HTTPS where possible. Canonical recommends switching archive URLs to HTTPS as a mitigation, while noting some community and country-specific mirrors do not support it. Check that updates still succeed afterwards.
- Review mirrors and proxies. Inventory which mirrors and caching proxies your estate trusts, remove unofficial ones, and treat internal mirrors as critical infrastructure with the access control and monitoring to match.
- Rebuild images. Refresh container base images, golden VM images and CI runner templates so new workloads do not launch with a vulnerable APT.
- Do not forget derivatives and appliances. Distributions built on Debian or Ubuntu need their own updates, so watch your vendors’ notices and chase appliance suppliers for confirmation.
These steps map neatly onto the Cyber Essentials controls for security update management and secure configuration.
Bottom line
CVE-2026-109518 is not a mass-exploitation event, but it strikes at the trust model behind software updates on millions of Linux systems. Patch APT within your 14-day window, do it from a trusted network with retries disabled, and use the moment to retire plain HTTP sources and unvetted mirrors for good.
