Patch APT root bug: Ubuntu, Debian VPS dey safe?

To patch the APT root bug, check the apt version wey dey your Ubuntu or Debian server, compare am with the fixed version, then upgrade only apt first. If your version don reach the fixed one, this bug no fit touch that server again. If e never reach, you go apply the APT security update with few commands, and the download small, so e no go finish your data.

Wetin this APT bug dey do, and which server e touch?

APT na the tool wey Ubuntu and Debian dey use to install package. On 4 November 2026, Ubuntu publish USN-8996-1 (Ubuntu Security Notice) for this bug, and the CVE (Common Vulnerabilities and Exposures) number na CVE-2026-109518. Ubuntu mark am High priority. The CVSS (Common Vulnerability Scoring System) v4.0 score na 7.7. Max Justicz na the person wey find am.

APT suppose verify every package before e install am. This bug na way to pass that check. The notice say attacker wey dey on the network path between your server and the package archive fit trick APT to install package wey nobody verify. That one fit give the attacker remote code execution with root power, because package dey install as root.

The APT maintainers' announcement (APT-2026-11-01) explain how e dey work. The attacker go use redirects together with "standard transient HTTP server errors that cause APT to retry downloads". Transient error mean small temporary error, so APT go try the download again. The result, for their own words, na APT go "override existing hardlinks with a chosen payload". Hard link na second name for the same file on disk, so if you write through one name, the data for the other name go change too. The upstream fix make APT open target files exclusively, so download no fit write through hard link wey already dey.

The bug need one condition: Acquire::Retries must no be zero. That setting tell APT how many times to retry failed files. Canonical's CVE text say the value 3 na the default from Debian 12 and Ubuntu 22.04, and APT's changelog show say APT 2.3.2 na the version wey turn am on. So exposure go be like this:

• Ubuntu 22.04 or newer, and Debian 12 or newer: exposed by default until you patch.
• Ubuntu 20.04 or older, and Debian 11 or older: default setup no dey exposed. The box dey exposed only if config file or script set Acquire::Retries to a value wey no be zero.

Status as of 5 November 2026: the advisories wey we read no report any attack or public proof of concept, and our web search no find any. That silence no prove anything, so no use am as reason to wait.

Check the apt version for your Ubuntu server

Paste this one for your server. E read your Ubuntu release, pick the fixed version for that release, and compare am with the version wey dey installed.

. /etc/os-release
case "$VERSION_ID" in
  26.10) FIXED=3.3.3ubuntu0.1 ;;
  26.04) FIXED=3.2.1ubuntu0.1 ;;
  24.04) FIXED=2.8.4ubuntu0.1 ;;
  22.04) FIXED=2.4.15ubuntu0.1 ;;
  20.04) FIXED=2.0.12+esm1 ;;
  18.04) FIXED=1.6.19+esm1 ;;
  16.04) FIXED=1.2.36+esm1 ;;
  14.04) FIXED=1.0.1ubuntu2.24+esm4 ;;
  *) FIXED= ;;
esac
NOW=$(dpkg-query -W -f='${Version}' apt)
echo "$PRETTY_NAME, apt $NOW, fixed in ${FIXED:-unknown}"
if [ -z "$FIXED" ]; then
  echo "RELEASE NOT IN USN-8996-1"
elif dpkg --compare-versions "$NOW" ge "$FIXED"; then
  echo "PATCHED"
else
  echo "NOT PATCHED"
fi

PATCHED mean your version na the fixed one or newer. NOT PATCHED mean you need the next section. RELEASE NOT IN USN-8996-1 mean the notice no list your release, so check the release name for the first line of the output, then read the notice yourself.

We use dpkg --compare-versions with ge (greater or equal) because e follow Debian version order and return 0 when the condition true. So the check go still talk true when later versions land. No compare the numbers with your eye. Each release get im own fixed number, so a number wey look big for one release fit still be old for that release.

These na the fixed versions for Ubuntu, from USN-8996-1, as of 5 November 2026:

• Ubuntu 26.10: 3.3.3ubuntu0.1
• Ubuntu 26.04 LTS: 3.2.1ubuntu0.1
• Ubuntu 24.04 LTS: 2.8.4ubuntu0.1
• Ubuntu 22.04 LTS: 2.4.15ubuntu0.1
• Ubuntu 20.04 LTS: 2.0.12+esm1, you need Ubuntu Pro
• Ubuntu 18.04 LTS: 1.6.19+esm1, you need Ubuntu Pro
• Ubuntu 16.04 LTS: 1.2.36+esm1, you need Ubuntu Pro with the Legacy Support add-on
• Ubuntu 14.04 LTS: 1.0.1ubuntu2.24+esm4, you need Ubuntu Pro with the Legacy Support add-on

How to apply the APT security update: upgrade only apt first

Run these three commands:

sudo apt-get update
apt-cache policy apt
sudo apt-get install --only-upgrade apt

apt-get update refresh the package lists. apt-cache policy apt show the Installed: version and the Candidate: version, and the candidate must be the fixed version or newer. --only-upgrade upgrade only package wey already dey, and e no go install new ones.

Why only apt first? The bug live for apt, so you close the problem before you download anything big. E also save data. On Ubuntu 24.04 amd64, packages.ubuntu.com list the apt download as 1,363.8 kB. apt need libapt-pkg6.0t64 (>= 2.8.4ubuntu0.1), so the library go upgrade if the installed version never reach that minimum; a newer library version also satisfy am, and the page no show im size. apt-get update also get im own download, and the size depends on your sources. Before you press Y, read the Need to get line, because that line show the real size for your box.

Now run the check from the last section again. You suppose see PATCHED. When you get better data, run the full upgrade:

sudo apt-get upgrade

USN-8996-1 say "a standard system update will make all the necessary changes", and the notice no mention reboot.

If the candidate still old after apt-get update, your server no dey see the fixed package. The usual place to look na your sources, because the fix enter the security pocket first. Print them with this command:

grep -rhE '^(deb |URIs:|Suites:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

You suppose see your release name with -security, like noble-security for 24.04. If apt-get update itself dey complain about your source files, fix the deb822 duplicate source error first. If the install stop because of broken dependencies, follow how to fix broken packages with apt, then come back.

Ubuntu 20.04 and older: wetin you go do?

The fixed versions for 20.04, 18.04, 16.04 and 14.04 come through Ubuntu Pro, so apt-get update alone no go bring them if Pro no dey attached. 16.04 and 14.04 also need the Legacy Support add-on.

Canonical's Pro page say Pro dey free for personal use on up to 5 physical machines, or 50 for official Ubuntu Community members. That page talk about physical machines. We no confirm whether VPS count, so read the terms before you depend on the free plan. To see how attach work, read how Ubuntu Pro works on a server.

If you no get Pro, remember the condition from the CVE text: these old releases no dey exposed in default setup. So check your retries setting with the section below. The better fix na to move to a supported release, and if the tool no gree, read why do-release-upgrade says no new release.

Debian: the versions wey you go compare

Debian fixed versions, from the Debian security tracker, as of 5 November 2026:

• Debian 13 trixie: 3.0.4 (DSA-6607-1, Debian Security Advisory)
• Debian 12 bookworm: 2.6.2 (DLA-4880-1, Debian LTS Advisory, where LTS mean long term support)
• Debian forky and sid: 3.3.6

The commands for this guide target Ubuntu. We no test them on Debian, so treat this part as steps wey you go run and read yourself. On Debian 13, use this line:

dpkg --compare-versions "$(dpkg-query -W -f='${Version}' apt)" ge 3.0.4 && echo PATCHED || echo "NOT PATCHED"

For Debian 12, change 3.0.4 to 2.6.2. The upgrade use the same apt-get update and apt-get install --only-upgrade apt commands, because Debian use the same tool. The tracker list these fixes under the security suites, so your sources must include trixie-security or bookworm-security.

Debian 11 bullseye regular LTS end on 31 August 2026. Freexian's paid ELTS (Extended LTS) service list advisory ELA-1880-1 for this bug, with 2.2.5 as the fixed version for bullseye. If you pay for ELTS, check deb.freexian.com/extended-lts/tracker/CVE-2026-109518. If you no pay, plan your move with the Debian 11 end of life upgrade path.

unattended-upgrades don already apply the fix?

E fit be so, but no assume am and no guess am from the time. The version check wey you run above na the answer to "my server safe?", no matter who install the update. The logs answer "who do am, and when?".

sudo zgrep -h -B3 ' apt:' /var/log/apt/history.log*

APT write each job for that file with Start-Date:, and Commandline: if e know the command. Upgrades appear in the form Upgrade: apt:amd64 (old, new). Look for the entry wey new na your fixed version. Then check the automatic job itself:

cat /etc/apt/apt.conf.d/20auto-upgrades
systemctl status apt-daily-upgrade.timer
sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log

For the first file, APT::Periodic::Unattended-Upgrade mean run every n days, and 0 mean off. The systemctl status output show when the timer go fire next. The log show wetin the job do the last time e run. If that file no dey, or the value na 0, that one alone no mean automatic upgrades dey off: APT read config fragments in alphanumeric ascending order, and command-line options override config directives. Another file fit enable the job, so check the combined config with apt-config dump | grep -i 'APT::Periodic', the timer and the logs; if your installed version never patch, upgrade by hand. For a full setup, read how to set up unattended-upgrades on Ubuntu. On Debian, if the job dey quiet, read why unattended-upgrades is not running on Debian.

How to read Acquire::Retries for your box

apt-config dump | grep -i 'Acquire::Retries'

Read this output with care, because empty output no mean zero. For APT's main branch, the default of 3 dey inside the code, as FindI("Acquire::Retries", 3), and we no see am for the list of defaults in apt-pkg/init.cc. So, going by the source, apt-config dump fit print nothing and retries still dey on. On Ubuntu 24.04 with 2.8.4ubuntu0.1, this command print nothing for us.

• On apt 2.3.2 or newer, retries dey on unless you see Acquire::Retries "0";.
• On apt older than 2.3.2, retries dey on only if this command show a value wey no be 0.

Retry no mean APT go try again after every error. For upstream 2.8.4 source wey we read on 5 November 2026, a 503 count as transient only when the response carry a body, and a 503 without body fail at once. When we test am with one 503 from a small local server, the download stop with 503 Service Unavailable, and we no see a retry. So our test no prove the empty-output point, that one still rest on the source. E also mean one failed download no show say retries dey off.

apt-config output no show options wey another command get for im own command line. A script wey call apt-get -o Acquire::Retries=3 no go show here, so also read your own cron jobs and deploy scripts if you dey on an old release.

Workaround dey? Wetin clear and wetin never clear

The real fix na the update. The APT announcement, USN-8996-1 and the CVE pages no give any workaround.

-o Acquire::Retries=0 na mitigation wey Canonical recommend for the upgrade run. Canonical's explanation confirm say setting retries to zero temporarily stop exploitation, including from a malicious mirror. If you must upgrade on a network wey you no trust, run am this way:

sudo apt-get -o Acquire::Retries=0 update
sudo apt-get -o Acquire::Retries=0 install --only-upgrade apt

The -o flag affect only that one command. With 0, APT no go retry failed files, so if your connection drop, just run the command again.

Acquire::http::AllowRedirect=false never confirm. The APT man page say this option control redirects, and redirects dey on by default. Some people dey suggest am for this bug, but no advisory wey we read recommend am, and we never test am. No count am as protection.

HTTPS: Canonical confirm protection against the network attacker. TLS (transport layer security) stop a stranger on the network from changing your traffic. E no go help if the bad party na the mirror or the proxy wey terminate TLS itself, and the CVE text put "a malicious mirror or proxy" inside the attack. Check wetin your server dey use:

grep -rhE '^(deb |URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
apt-config dump | grep -i 'proxy'

If the first command show http://, or the second one show proxy wey you no know, patch first, then find out why.

Where attacker fit stand for Nigeria?

The attacker must sit between your machine and the archive, or control the mirror or proxy. So the risk depends on the path wey your APT traffic take.

• A laptop or office server on shared Wi-Fi, for example co-working space, hotel or cyber cafe. Other people control that network.
• An office APT proxy wey many machines share. If person take over that box, every machine behind am dey at risk.

As of 5 November 2026, Launchpad's list of official Ubuntu archive mirrors no show any mirror for Nigeria, and the CD image list no show any too. Based on that list then, APT traffic from Nigeria to an official mirror go likely leave the country, and e go pass more networks on the way. That one no prove any attack. E only explain why you no suppose treat the path as private.

Docker images wey run apt on old base

The bug dey fire when apt dey download package. So the risk for Docker sit for image build, and for any container wey call apt-get when e dey run. If your Dockerfile get RUN apt-get install on an old base image, that build dey use the old apt.

Put the apt upgrade before your other installs, because you no fit assume say the base image don get the fix:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --only-upgrade apt

Then rebuild, and check the result:

docker build --pull --no-cache -t myapp .
docker run --rm myapp dpkg-query -W -f='${Version}\n' apt

You need both flags. --pull try to get a newer base image. --no-cache force the RUN steps to run again, because Docker no dey invalidate RUN cache by itself, and e match a cached apt-get update layer by the command string only. So --pull alone fit still reuse the old apt layer.

After the patch

This bug no be the only one wey fit dey your server. To see the rest, read how to check your server for known CVEs. The same APT release also carry some memory fixes for the 2.6, 2.8 and 3.0 series. The announcement say those ones no get expected security impact beyond denial of service, for apps wey dey parse untrusted .deb files as root.

The advisories wey we read no give any sign wey you fit search for to know whether person already use this bug on your box. If you get strong reason to suspect your server, like strange root process or package wey you no install, treat am as separate job and no trust a patch alone to clean am.

FAQ: questions wey people dey ask about the APT bug

How I go know say my server don patch for the APT bug?

Run dpkg-query -W -f='${Version}\n' apt, then compare the version with the fixed one for your release, using dpkg --compare-versions. On Ubuntu 24.04 the fixed version na 2.8.4ubuntu0.1, on 22.04 na 2.4.15ubuntu0.1, on Debian 13 na 3.0.4, and on Debian 12 na 2.6.2. If your version equal or pass am, the box don patch, no matter whether you or unattended-upgrades install am.

My APT sources dey use HTTPS. I still need to patch?

Yes. Canonical confirm say HTTPS protect against the network attacker, but still recommend the update. HTTPS no stop a malicious mirror itself from serving bad package. Install the fixed version.

Acquire::Retries=0 na official workaround?

Canonical recommend am as temporary mitigation while you install the security update. E stop the retry wey the attack need, including for a malicious mirror. Still install the fixed version.

I dey on Ubuntu 20.04 and I no get Ubuntu Pro. My server dey in danger?

For default setup, no. Canonical's CVE text say releases older than Ubuntu 22.04 no dey affected in a default configuration, because Acquire::Retries no dey on by default there. The box become exposed if config file or script set that value to a number wey no be zero. The fixed package 2.0.12+esm1 need Ubuntu Pro, so check your config and scripts, and plan to move to a supported release.

I need to reboot after I upgrade apt?

USN-8996-1 no mention reboot. E say a standard system update go make all the necessary changes. To confirm, run the version check again after the upgrade. If you see the fixed version or a newer one, the update don land.