A flaw in APT, the package manager for Debian and Ubuntu, allows an attacker who can modify package downloads to swap a checked package for their own. The attacker's code then runs as root, according to advisories that Debian, Ubuntu, and APT's developers published on November 4. The issue is tracked as CVE-2026-109518CVSS 7.7 HIGH / Published 2026-11-04On Debian, Ubuntu, and derivative Linux distributions, an on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy) between an APT client and an archive server triggered by a package install can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges.View on NVD.
What happened
Three advisories landed on the same day, from Debian, from Ubuntu, and from APT's own developers. Debian has released fixed versions of APT for the flaw. Ubuntu rates the flaw as high priority, with a CVSS 4.0 score of 7.7.
Ubuntu also says that distributions built on Debian and Ubuntu are affected as well, without naming any. That widens the exposure well past the two named projects, to anything downstream that ships the same package manager.
None of the three advisory reports describe attacks exploiting the flaw or offer a workaround for systems that cannot update yet. In practice that means patching is the route forward, and there is no documented stopgap for hosts that are stuck on an older build.
How it was done
The published detail is narrow, so it is worth repeating only what the advisories say. An attacker needs the ability to modify package downloads. With that position, they can swap a checked package for one of their own.
The attacker's code then runs as root, according to advisories that Debian, Ubuntu, and APT's developers published on November 4.
Nothing in the advisories sets out an exploitation chain beyond that, and nobody has been named as having used it.
What to check
The useful work here is inventory and patch coverage, then a look at how your builds and hosts fetch packages.
Inventory every APT version you run
Run apt-cache policy apt across servers, and pull the same data from your configuration management inventory. Include container base images, since those are often missed. Any host or image still on a pre-fix build is on your remediation list.
Patch and confirm the fix landed
Update package lists and upgrade APT itself, then re-run apt-cache policy apt and compare the installed version against the fixed version in your distribution's advisory. A host that reports the old version after a successful run usually means a pinned version or a stale mirror.
Check your downstream distributions
List any images or appliances built on Debian or Ubuntu, including vendor-supplied ones. Ask each vendor which APT build they ship and when a rebuild is available. A vendor who cannot answer is an open item, not a pass.
Review how packages are fetched
Grep /etc/apt/sources.list and /etc/apt/sources.list.d for entries using plain http, and check proxy and mirror configuration in /etc/apt/apt.conf.d. Anything that lets an intermediary touch package traffic deserves scrutiny.
Audit your build pipelines
Look at CI job definitions and Dockerfiles that call apt-get install, and check whether they run against an internal mirror you control. Builds that reach arbitrary external endpoints over untrusted networks are the ones to tighten first.
Make the fix stick in base images
Rebuild base images after patching and push them through your registry, then scan for older image tags still referenced in deployments. A deployment manifest pointing at a stale tag will quietly reintroduce the old package manager.