Is CVE-2026-109518 being exploited right now?

At the time of writing (8 November 2026), a secondary security report says the advisories it reviewed do not report exploitation in the wild or public exploit code, and that the CVE is not in CISA's Known Exploited Vulnerabilities catalog. That can change, so patch anyway.

Can I set Acquire::Retries to 0 instead of patching?

Canonical recommends setting Acquire::Retries=0 only for the update command as a temporary mitigation while installing the patched APT package. It is not a substitute for patching.

Who found this bug and how serious is it?

Ubuntu credits Max Justicz with the discovery. Ubuntu rates it High priority with a CVSS v4.0 base score of 7.7.

Does this affect Debian servers too?

Ubuntu's CVE page notes that the retry default of 3 also applies from Debian 12 onward, so Debian servers can be affected. Check Debian's own security advisory for the fixed Debian package versions, because this guide only covers Ubuntu.

How much does Ubuntu Pro cost for an old 20.04 server?

At the time of writing (8 November 2026), the Ubuntu security notice page says Ubuntu Pro is free for up to five machines. The 16.04 and 14.04 fixes also need the Legacy Support add-on.

Can unattended-upgrades email me when it installs something?

Yes. The Ubuntu Server documentation says you can set Unattended-Upgrade::Mail in /etc/apt/apt.conf.d/50unattended-upgrades to get email notifications.

Is there a tool that only tells me about updates without installing them?

The Ubuntu Server documentation mentions apticron, which you install with sudo apt install apticron and configure in /etc/apticron/apticron.conf with your email address.

Fix APT CVE-2026-109518 on an Ubuntu VPS

To fix CVE-2026-109518 on an Ubuntu VPS, install the patched APT package and confirm its version. Canonical recommends temporarily disabling download retries while you patch: run sudo apt update && sudo apt upgrade -o Acquire::Retries=0. If a full upgrade is not possible, use Canonical’s targeted APT command below.

Here is the part that surprises people: the tool you use to install security fixes was the weak spot this time. According to Ubuntu's notice USN-8996-1, published on 4 November 2026, a rogue mirror or proxy sitting between your server and the package archive could trick APT into installing a package it never verified, and that package would run as root.

By the end of this guide you will have patched APT, checked that the right version is installed, checked whether your server was even exposed, and set up unattended-upgrades so the next security fix lands without you having to remember it.

What this APT bug actually is

APT is the package manager on Ubuntu, the program behind apt update and apt install. Normally it checks every package against a signed list before installing it, so a fake package gets rejected.

Ubuntu's notice says APT "incorrectly handled hard links when encountering redirects and retrying package downloads". A hard link is a second name for the same file on disk. A redirect is when a server says "the file you want is over there instead". A retry is APT trying a failed download again.

Think of it like a parcel locker. You check the label on the parcel, the courier says "wrong locker, try the next one", and in the confusion someone swaps the box after you checked the label. You open a box nobody inspected.

The Ubuntu CVE page lists the priority as High with a CVSS v4.0 base score of 7.7. CVSS is the common 0 to 10 scale for how serious a security bug is.

Who is exposed by default

Why this matters: the attack only works when APT is set to retry downloads. The Ubuntu CVE page says the client must have a non-zero Acquire::Retries setting, and that the default value is 3 starting with Debian 12 and Ubuntu 22.04 LTS. It also says older releases are unaffected in a default configuration.

So in plain words:

Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 retry by default, so treat them as exposed until patched.
Ubuntu 20.04 and older do not retry by default, but someone may have turned retries on by hand, so check anyway.

The attacker also has to be "on-path", meaning they can see and change traffic between your server and the archive. The CVE page names a malicious mirror or proxy as examples.

Before you start

This is a low-risk update, but it touches the tool that installs everything else, so do it with a little care.

SSH access to the server with a user that can run sudo.
About 10 minutes per server.
A recent backup or a provider snapshot of the VPS, taken before you start.
Your Ubuntu release number, which you will find in Step 1.
For Ubuntu 20.04, 18.04, 16.04 or 14.04: an Ubuntu Pro subscription, because the fixed packages for those releases ship through Pro.
A second SSH session open, in case your first one drops during the upgrade.

Quick tip: if you have firewall or SSH hardening rules you are nervous about, read our UFW guide first. Package upgrades do not normally touch your firewall, but it is good to know how you would get back in.

Heads up: take the snapshot from your VPS provider's control panel if it offers one. It is the fastest way back if anything goes wrong, and it costs you a minute.

Patch APT step by step

Step 1: Find your Ubuntu release

You need to know which release you run, because each release has its own fixed version. This command prints the release name and number.

lsb_release -a

The lsb_release manual describes -a as "Show all of the above information." Look for the Ubuntu version number in the output and note it.

Step 2: Check the APT version you have now

This command asks dpkg, the low-level package tool, for the installed version of the apt package.

dpkg-query -W apt

The dpkg-query manual says the default output is one line with the package name and its installed version, separated by a tab. It looks like this example, where the version is a placeholder:

apt	2.8.3

Keep this number. You will compare it with the fixed version in a moment.

Step 3: Compare with the fixed version for your release

At the time of writing (8 November 2026), USN-8996-1 lists these fixed apt versions:

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, available with Ubuntu Pro
Ubuntu 18.04 LTS: 1.6.19+esm1, available with Ubuntu Pro
Ubuntu 16.04 LTS: 1.2.36+esm1, available with Ubuntu Pro through the Legacy Support add-on
Ubuntu 14.04 LTS: 1.0.1ubuntu2.24+esm4, available with Ubuntu Pro through the Legacy Support add-on

If your version from Step 2 matches the fixed version, or is higher, you are already patched and can skip to the checks. If it is lower, keep going.

Step 4: Apply the update with retries disabled

Canonical recommends setting Acquire::Retries=0 for the update command as a temporary safeguard while installing the fix. This prevents APT from retrying a failed download through a potentially untrusted path.

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

Review the package list, approve the upgrade, and let the command finish without errors. The option applies to this command only; it does not permanently change the server’s APT configuration.

Step 5: Target only APT if a full upgrade is not possible

If you cannot perform a full system upgrade during this maintenance window, Canonical provides this targeted command for the APT source package.

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

This installs the available update for packages built from the APT source package. Schedule the remaining system updates separately; this narrower command is for the urgent APT fix.

Optional: Simulate the targeted change first

A simulation shows the planned package changes without installing them.

sudo apt-get -s install --only-upgrade apt

Read the simulation output, then run one of Canonical’s retry-disabled commands above to apply the fix.

Step 6: Confirm the new version

Run the same check as before to prove the fix is on disk.

dpkg-query -W apt

The version shown should now match the fixed version for your release from Step 3. If it does, APT is patched.

Variant: Ubuntu 20.04 and older

For 20.04 and 18.04, the notice says the fix is available with Ubuntu Pro. For 16.04 and 14.04, it needs Ubuntu Pro with the Legacy Support add-on. Without that subscription, apt update will not offer the fixed version, and Step 6 will still show the old number.

Remember that these releases are not affected in a default setup, because they do not retry downloads by default. If you cannot get Pro right away, run the check in the next section to make sure nobody switched retries on. Then plan the move to a supported LTS release, because a release without updates will keep collecting problems like this one.

Check whether retries are switched on

This is the "was I even exposed" check. It also tells you whether a hand-made config is changing the default.

Step 1: Look at the live APT config

This command prints APT's whole configuration space and filters it down to lines that mention retries.

apt-config dump | grep -i retries

The apt-config manual says dump will "Just show the contents of the configuration space." If you see a line such as Acquire::Retries "3";, retries are on. If you see nothing, no config file sets the option, and your release default applies: 3 on 22.04 and newer, according to the Ubuntu CVE page.

Step 2: Find which file sets it

If you saw a value, this command shows which config file under /etc/apt/ sets it.

grep -ri retries /etc/apt/apt.conf /etc/apt/apt.conf.d/

You will see the file name and the matching line. If grep complains that /etc/apt/apt.conf does not exist, that is fine: many servers only use the files in apt.conf.d.

The apt.conf manual describes the option like this: "If this is non-zero APT will retry failed files the given number of times." Retries are useful on a shaky network, so do not remove them just because they exist. Patching APT is the real fix.

Set up unattended-upgrades so the next fix is automatic

Patching once is good. Not needing to remember next time is better. The unattended-upgrades package installs security updates on a schedule, with no one logged in.

Imagine a made-up example: Priya runs three small VPS servers for client websites. She patches APT on Monday, feels good, and then a different security fix lands two weeks later while she is on holiday. With unattended-upgrades set up, that second fix installs itself on schedule, and she reads about it in the log when she gets back.

Step 1: Install the package

This command, taken from the Ubuntu Server documentation, installs unattended-upgrades. On many Ubuntu servers it is already present, and APT will simply say so.

sudo apt install unattended-upgrades

Step 2: Check which updates it is allowed to install

The main config file is /etc/apt/apt.conf.d/50unattended-upgrades. Open it with a text editor so you can read the allowed sources.

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Look for the Unattended-Upgrade::Allowed-Origins block. The Ubuntu documentation shows it like this:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Lines starting with // are comments, so they are ignored. In this default, the main release and the -security pocket are allowed, while -updates, -proposed and -backports are off. For a web server, leaving it like this is a sensible start: security fixes come in, bigger changes wait for you.

Step 3: Block packages you want to upgrade by hand

The same file has a Unattended-Upgrade::Package-Blacklist block. Anything listed there is skipped. The documentation shows these commented examples:

Unattended-Upgrade::Package-Blacklist {
//      "vim";
//      "libc6";
//      "libc6-dev";
//      "libc6-i686";
};

Why this matters: if a package has broken your site after an upgrade before, list it here and upgrade it yourself in a maintenance window. Remove the // in front of a line to make it active. Save and close the file when done (in nano, press Ctrl+O, Enter, then Ctrl+X).

Step 4: Turn on the schedule

The second file, /etc/apt/apt.conf.d/20auto-upgrades, decides whether the automatic run happens at all. Open it.

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Make sure it contains exactly these four lines from the Ubuntu documentation:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

The first line refreshes package lists, the second downloads upgrades in advance, the third cleans old downloaded files every 7 days, and the fourth runs unattended-upgrades. Save and close.

Step 5 (optional): Keep timer overrides valid

Ubuntu’s default APT timers normally need no custom override. If you inspect or edit one, remember that systemd’s Persistent= setting accepts a boolean such as true or false. Persistent=delay is not valid syntax. Check the active timer definitions before changing anything.

systemctl cat apt-daily.timer apt-daily-upgrade.timer
systemctl list-timers --all 'apt-daily*'

How to check it worked

Check 1: APT is on the fixed version

Run the version check one more time.

dpkg-query -W apt

Expected result: the version matches your release's fixed version from the list above, for example 2.8.4ubuntu0.1 on 24.04 LTS.

Check 2: Unattended-upgrades runs without errors

This command simulates a run and prints debug detail, without installing anything. The manual says --dry-run will "Just simulate installing updates, do not actually do it".

sudo unattended-upgrade --dry-run --debug

Expected result: lines showing the allowed origins it found and the packages it would upgrade, if any, and no Python traceback at the end.

Check 3: The timers are scheduled

This command lists the APT timers and when they will next fire. The systemctl manual says list-timers shows timers "ordered by the time they elapse next."

systemctl list-timers 'apt-daily*'

Expected result: two rows, one for apt-daily.timer and one for apt-daily-upgrade.timer, each with a time in the NEXT column.

Check 4: Read the logs the next day

The unattended-upgrade manual says every run is logged to /var/log/unattended-upgrades/unattended-upgrades.log, and dpkg output goes to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log. This command shows the last 50 lines of the main log.

sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log

Expected result: recent dated lines saying which packages were checked or upgraded. The Ubuntu package documentation also notes that APT actions are logged in /var/log/dpkg.log, which is useful if you want to see when APT itself changed version.

Troubleshooting

APT says another process holds the lock

Symptom: sudo apt upgrade stops and says it could not get a lock because another process is using it. Likely cause: the automatic daily run is already installing updates in the background. Fix: wait a few minutes and try again. Do not delete lock files by hand, because that can leave packages half installed.

The version did not change after upgrading

Symptom: dpkg-query -W apt still shows the old version. Likely cause: the package list did not refresh, the configured mirror has not synced, or the update failed. Fix: run sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)' and read the output for errors. If a custom mirror fails, switch to an official Ubuntu archive for this update, then repeat the version check.

20.04 or 18.04 says APT is already the newest version

Symptom: APT reports nothing to upgrade, but dpkg-query -W apt still shows a version without +esm in it. Likely cause: the fixed packages for these releases ship through Ubuntu Pro, and the machine is not attached to a Pro subscription. Fix: attach the server to Ubuntu Pro, run sudo apt update, then repeat the upgrade. Until then, use the retries check to confirm you are on the default setting.

unattended-upgrades is installed but nothing ever happens

Symptom: the log file is empty or missing after several days. Likely cause: /etc/apt/apt.conf.d/20auto-upgrades is missing or has "0" values. Fix: open the file and make sure it contains the four lines from Step 4, then run the dry run from Check 2.

The dry run shows no packages even though updates exist

Symptom: apt list --upgradeable shows packages, but the dry run skips them. Likely cause: those packages come from -updates or a third-party source, which are not in Allowed-Origins by default. Fix: this is often fine, because only security fixes install automatically. Upgrade the rest by hand, or add the origin on purpose if you understand the change.

A package you rely on keeps getting upgraded

Symptom: something on your site changes after the nightly run. Likely cause: the package is in an allowed origin and not blacklisted. Fix: add the package name to Unattended-Upgrade::Package-Blacklist in 50unattended-upgrades, and upgrade it yourself after testing.

Syntax error after editing a config file

Symptom: apt commands complain about a config file with a line number. Likely cause: a missing quote or semicolon in a file under /etc/apt/apt.conf.d/. Fix: open the file named in the error, check that every value line ends with "; and that braces match, then run sudo apt update again.

Security notes and when to ask for help

Patching APT closes this hole, but the attack started with someone able to tamper with your traffic. Keep your server pointed at official Ubuntu mirrors or a mirror you control, and be careful with proxies you do not run yourself.

If you manage a server with a control panel on top, check the panel as well. Our guide to checking cPanel and Plesk on a VPS walks through that in about ten minutes. And while you are in a security mood, setting up Fail2ban for SSH is a good next step.

Ask your host or a developer for help if the version check does not match after two tries, if the server is on 16.04 or 14.04 and you do not have Pro, or if you see errors during the upgrade that mention broken packages.

The one message worth forwarding

Copy this to whoever looks after your Ubuntu servers:

“Hi, Ubuntu published USN-8996-1 on 4 November 2026 for CVE-2026-109518 in APT. Canonical recommends patching with download retries temporarily disabled. Please run sudo apt update && sudo apt upgrade -o Acquire::Retries=0, or use Canonical’s targeted APT-only command if a full upgrade is not possible. Then confirm with dpkg-query -W apt that the installed version matches the fixed version for the Ubuntu release. Please also confirm unattended-upgrades is enabled. Thanks.”

The takeaway: one APT upgrade and a quick version check fix this today, and unattended-upgrades makes sure the next security fix does not wait for you.