CVE-2026-109518 is a flaw in APT, the package manager on Debian, Ubuntu and their derivatives, that lets someone who can change the HTTP traffic between APT and the package server replace a package after APT has already checked its signature. Because APT installs packages as root, that means code running as root on your machine. It affects default setups from Debian 12 and Ubuntu 22.04 onwards. The fix is an updated apt package, published on 4 November 2026 for Debian (2.6.2 for bookworm, 3.0.4 for trixie) and Ubuntu (22.04, 24.04, 26.04 and 26.10). Upgrade apt itself first, on a network you trust, and then rebuild your Docker images.
I'm Kunal Vohra, a fractional CTO and a security researcher and cybersecurity advisor. Yesterday I wrote about patching the Linux kernel TCP flaw CVE-2026-98432, and the first command in that guide was sudo apt update. This bug is in the tool you use to apply every other fix, so it jumps the queue. Here is what it is, how to check where you stand, and how to patch without tripping over the bug while you do it.
What CVE-2026-109518 is
CVE-2026-109518 is a "download verification bypass" in APT, which is how Debian's own changelog for the fix labels it. In plain terms: APT downloads a package, verifies it, and then installs it, and this bug opens a short window in which the file on disk can be changed between the check and the install.
According to the reporting on Debian's advisory, the attacker uses HTTP redirects and ordinary temporary server errors to make APT retry a download. With the right redirects, APT ends up treating two different downloads as the same file, and the way it reuses files on disk when a download resumes lets the attacker's content replace the verified package. Debian credits the researcher Max Justicz with finding it. The upstream fix, in APT 3.3.6 by Julian Andres Klode, changes APT's download methods to "open target files exclusively", so two downloads can no longer end up writing to the same file.
The facts that matter for prioritising it:
- The attacker has to be on the path. Someone who can modify the HTTP traffic between your machine and the package server: a malicious or compromised mirror, a proxy, a hostile network (public Wi-Fi, a compromised router), or anyone who can intercept traffic in between. A random attacker on the internet cannot trigger it against your server by itself.
- It fires when you install or update. Nothing happens while a server sits idle. The risk is every
apt update,apt upgradeandapt-get install, which includes every Docker build and CI job that installs packages. - Retries are the switch. The bug needs APT's
Acquire::Retriessetting to be above zero. It is 3 by default on Debian 12 and Ubuntu 22.04 LTS and later, which is why those releases are affected out of the box. Debian 11 and Ubuntu 20.04 are not exposed by default, but they are if someone set retries in a config file or script. - Severity: high, with no single score yet. Ubuntu rates it high priority (CVSS 4.0 score of 7.7, as reported by The Hacker News); APT's developers call it critical; Debian's tracker lists it as important for testing. I could not find an NVD score at the time of writing.
- No reported attacks, but a public proof of concept is indexed. None of the advisories describe exploitation in the wild, and it is not in CISA's KEV catalogue. A proof-of-concept repository is listed in public PoC trackers, so treat this as "assume someone will try it".
The line I'd put in front of any founder: the signature check is only as good as the moment you check it, and this bug moves the swap to just after that moment.
Is this you? A two-minute check
You are affected if you run Debian 12 or 13, Ubuntu 22.04 or later, or a derivative (Linux Mint, Pop!_OS, Raspberry Pi OS, many cloud images), and you have not installed the fixed apt yet. That covers a lot of startup infrastructure: web and API servers, bastion hosts, CI runners, Kubernetes nodes, and every container image built FROM debian or FROM ubuntu.
On each machine, check which release and which apt you have:
cat /etc/os-release
dpkg-query -W -f='${Version}\n' apt
Then check the two conditions the attack depends on, retries and plain HTTP sources:
apt-config dump | grep -i retries
grep -rhE '^(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
If retries shows a number above 0 (or nothing, on Debian 12+ and Ubuntu 22.04+, where the default is 3) and your sources start with http://, you have both preconditions. Many stock images still point at http:// mirror URLs, because APT relies on signatures rather than the transport for integrity. That assumption is exactly what this bug breaks.
Now compare your apt version with the fixed versions below.
Fixed apt versions for CVE-2026-109518
These are the versions published on 4 November 2026. Debian's are confirmed on the Debian package tracker; Ubuntu's are as listed by Ubuntu and reported by The Hacker News, so check Ubuntu's CVE page for your release before you rely on them.
Debian
- Debian 13 (trixie, stable): apt 3.0.4 (DSA-6607-1). Vulnerable: 3.0.3.
- Debian 12 (bookworm, oldstable): apt 2.6.2 (DLA-4880-1). Vulnerable: 2.6.1.
- Debian testing (forky) and unstable (sid): fixed upstream in apt 3.3.6, accepted into unstable on 4 November. Testing was still on vulnerable 3.3.5 when I checked, with the migration blocked.
- Debian 11 (bullseye): not exposed in its default configuration; The Hacker News reports a fix in 2.2.5 for systems where retries were turned on.
Ubuntu
- Ubuntu 26.10: apt 3.3.3ubuntu0.1
- Ubuntu 26.04 LTS: apt 3.2.1ubuntu0.1
- Ubuntu 24.04 LTS: apt 2.8.4ubuntu0.1
- Ubuntu 22.04 LTS: apt 2.4.15ubuntu0.1
- Ubuntu 20.04 and older: not exposed by default; fixes for non-default setups go through Ubuntu Pro (ESM). Ubuntu tracks eight releases in total for this CVE.
One timing note: on the afternoon of 4 November, Ubuntu's tracker still marked releases as vulnerable for a while after the fixed builds were published. If your version matches the list above, you have the fix, whatever a cached page says.
How to fix CVE-2026-109518, step by step
The awkward part: the tool you are patching is the tool doing the downloading. So the order matters. Turn off the precondition, upgrade apt on its own, verify, and only then run your normal upgrades.
Step 1: Do the update from a network you trust
Do not patch a laptop on hotel Wi-Fi, and don't route this update through a proxy or mirror you don't control. For cloud servers talking to your provider's or your distribution's official mirror, the practical risk during the update is low, but it is not zero, which is why Step 2 exists.
Step 2: Remove the retry precondition for the upgrade itself
The bug needs Acquire::Retries above zero, so run the apt upgrade with retries set to 0 for that one command:
sudo apt-get -o Acquire::Retries=0 update
sudo apt-get -o Acquire::Retries=0 install --only-upgrade apt
If the download fails on a flaky connection, just run it again. A failed download is the price of not retrying automatically.
Step 3: Verify the fixed version
dpkg-query -W -f='${Version}\n' apt
Compare with the list above. No reboot is needed: apt is a userspace tool, and the next run uses the new code.
Step 4: Now run your normal updates
sudo apt update
sudo apt full-upgrade
If you were also waiting on the kernel fix from earlier this week, this is when you install it and reboot. The CVE-2026-98432 guide has the per-distribution details.
Step 5 (optional stopgap): disable retries on machines you can't patch today
For a machine you cannot upgrade right away, the reporting on the advisories (not the vendors themselves) points to setting retries to 0 as a way to remove one required condition. It makes updates less forgiving on bad connections, so treat it as temporary:
echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518
Delete that file once the fixed apt is installed if you want automatic retries back. Neither Debian nor Ubuntu offers an official workaround; the update is the fix.
Step 6: Prefer HTTPS mirrors where you can
Modern APT supports https:// sources out of the box. If your mirror offers HTTPS, switching makes the interception this bug depends on much harder. To be precise about it: none of the advisories says HTTPS sources are immune, so this is defence in depth on top of the update, not instead of it.
Docker images and CI runners: where the exposure really lives
Production servers run apt occasionally. Your build pipeline runs it all the time. Every RUN apt-get update && apt-get install in a Dockerfile, and every CI job that installs a package, is an APT session that this bug applies to, and it often runs on shared networks you have no visibility into.
What I would do this week:
- Find every image that installs packages. Search your repositories for
apt-getandapt installin Dockerfiles and CI config files. - Pull fresh base images and check what is inside them. A base image tag only contains the fixed
aptonce it has been rebuilt upstream. Check before you trust it:
docker pull debian:trixie
docker run --rm debian:trixie dpkg-query -W -f='${Version}\n' apt
- Until your base image ships the fix, upgrade apt first in the Dockerfile, with retries off, before installing anything else:
RUN apt-get -o Acquire::Retries=0 update \
&& apt-get -o Acquire::Retries=0 install -y --only-upgrade apt \
&& apt-get update && apt-get install -y --no-install-recommends your-packages \
&& rm -rf /var/lib/apt/lists/*
- Rebuild and redeploy images built in the last few weeks, so the fix is in what actually runs, not just in your Dockerfile.
- Patch self-hosted CI runners the same way as servers, and check that your hosted CI provider has updated its runner images.
What this means for startups
This is a supply chain bug in the most trusted part of the stack. Most teams treat the package manager as plumbing: it has signatures, so it must be safe. CVE-2026-109518 is a reminder that "signed" protects the file at the moment it is checked, and that the boring parts of your pipeline (mirrors, proxies, CI networks, base images) are part of your attack surface.
The teams that close this in a day are the ones with the same three things I mentioned for the kernel bug: an inventory of every Linux host and image, a patch routine that isn't a heroic effort, and someone who owns it. The last three big fixes on this blog, the Next.js CVE-2026-96889 upgrade, PHP2Shell and the kernel patch, all came down to the same lesson: the fix was quick, finding every place that needed it was the slow part. My startup security checklist puts that inventory near the top for exactly that reason.
If nobody on your team owns this kind of work, that is the real gap. A technical advisor can set up the inventory, base-image policy and patch routine with your engineers in a few sessions; a fractional CTO owns it on an ongoing basis, along with the rest of your security posture.
Frequently asked questions
What is CVE-2026-109518? A download verification bypass in APT, the package manager on Debian and Ubuntu. An attacker who can modify the HTTP traffic between APT and the package server can use redirects and retries to swap a package after APT has verified it, which leads to code running as root when the package installs. It was disclosed and patched on 4 November 2026.
Is Ubuntu affected by CVE-2026-109518? Yes. Ubuntu 22.04 LTS and later are affected in their default configuration because APT retries downloads by default. Fixed apt builds are 2.4.15ubuntu0.1 (22.04), 2.8.4ubuntu0.1 (24.04), 3.2.1ubuntu0.1 (26.04) and 3.3.3ubuntu0.1 (26.10). Ubuntu 20.04 is not exposed by default.
How do I fix the APT vulnerability on Debian? Upgrade the apt package: 3.0.4 on Debian 13 (trixie), 2.6.2 on Debian 12 (bookworm). Run sudo apt-get -o Acquire::Retries=0 update and sudo apt-get -o Acquire::Retries=0 install --only-upgrade apt from a trusted network, then confirm with dpkg-query -W apt.
Is CVE-2026-109518 being exploited? No attacks had been reported by Debian, Ubuntu or CISA as of 4 to 5 November 2026. A proof-of-concept repository is listed in public trackers, so patch now rather than waiting for reports.
Does using HTTPS mirrors protect me? It makes the attack harder, because the attacker has to tamper with traffic in transit, but no advisory says HTTPS sources are immune. Use HTTPS where your mirror supports it and still install the fixed apt.
Do I need to reboot after updating apt? No. APT is a userspace program, so the fixed version is used the next time it runs. You only need a reboot if you also install a new kernel.
If you're not sure how many servers, runners and images in your stack run APT, or you want a patch routine that makes the next one of these boring, book a 30-minute call. Bring your Dockerfiles; that's usually where the surprises are.
Sources
- apt package news and versions (Debian Package Tracker)
- apt unstable changelog, 3.3.6 entry (Debian)
- CVE-2026-109518 (Debian Security Tracker)
- CVE-2026-109518 (Ubuntu Security)
- Debian and Ubuntu APT Flaw Lets MitM Attackers Swap Verified Packages and Run Code as Root (The Hacker News)
- Debian and Ubuntu APT Flaw Lets Hackers Hijack Software Updates and Execute Code as Root (Cyber Security News)
- APT 3.3.6 Released with Security Fix for Download Verification Bypass (Linuxiac)
- Debian patches APT flaw that let network attackers swap verified packages for root code (RuntimeWire)
Written By
Kunal Vohra
Technical Co-Founder & Fractional CTO
I've co-founded 6+ startups across India, the UAE, and the US, spanning AI, Web3, fintech, and cybersecurity. I write about the technical and strategic decisions that determine whether a startup thrives or stalls.
Comments
Loading comments…