Debian published DSA 6607-1 on 4 November, fixing CVE-2026-109518 in apt, the package manager used by Debian, Ubuntu and everything downstream of them. The outcome is code execution as root.

The mechanism is worth getting right, because the interesting part is not that apt can be tricked. It is what apt had already done correctly before it was tricked.

The shape of the bug

Debian's own description: an on-path attacker who can manipulate the HTTP traffic between an apt client and an archive server, including a malicious mirror or proxy, can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges. The cause is given as the reuse of hard links, and it requires the client to follow redirects and to retry the download.

Two behaviours combine. Two different package downloads can be merged when a redirect leaves them sharing the same URI. And file handling on resume lets the package be replaced after it has been verified.

That second clause is the whole story. apt did check the signature. It checked the right file. The file it then installed was not the file it had checked.

Signature verification answers a question about a blob of bytes at a moment in time. It does not answer a question about the bytes you eventually execute, unless the path between those two moments is airtight. Here it was not.

The modern releases are the vulnerable ones

Exploitation needs a non-zero Acquire::Retries setting. That value has defaulted to 3 since Debian 12 and Ubuntu 22.04 LTS. Before those, the default was zero.

So in a default configuration older releases are not affected. Debian 11 and Ubuntu 20.04 are fine. Debian 12, Debian 13 and Ubuntu 22.04 onwards are not.

That inverts the usual advice in an uncomfortable way, and it should not be read as an argument for running old software. The retry default is not a mistake. A package manager that gives up on a flaky mirror is a worse package manager. It widened this particular flaw because the flaw lives in the resume path, and the resume path only runs when retries are allowed.

Fixed versions are 2.6.2 on bookworm, 3.0.4 on trixie and 3.3.6 in unstable. The vulnerable ones are 2.6.1, 3.0.3 and 3.3.5. Until you can update, setting Acquire::Retries to 0 in apt.conf removes the precondition.

The researcher has done this before

CVE-2026-109518 was found by Max Justicz.

In January 2019 the same researcher published remote code execution in apt, CVE-2019-3462. apt did not properly sanitise certain fields across an HTTP redirect, which let an attacker in the middle inject content and have an altered package installed. It was fixed in 1.4.9.

Seven years apart: the same program, the same attacker position, the same outcome, and the same underlying gap between what the package manager verified and what it installed.

The back catalogue makes the point harder. He has also published remote code execution in Alpine Linux's apk, on packagist.org, on rubygems.org and in CouchDB, plus a CocoaPods flaw he framed as reaching three million applications. One person has now broken the install path of six separate ecosystems.

That is not a comment about one researcher's skill. It is a comment about where the attention is not. Package managers are the most privileged software on most machines, they run as root by design, and the trust boundary inside them is a sequence rather than a signature.

What to do

  • Update apt before anything else you patch this week. It is the thing that installs the other patches.
  • Set Acquire::Retries to 0 if you cannot update immediately, and remember to put it back afterwards.
  • Audit what sits between your machines and your mirror. A caching proxy you operate is an on-path position. So is an inspection appliance, if your sources are plain HTTP.
  • Use HTTPS mirrors. It does not fix the bug, and Debian is right that signature verification is the real control, but it removes the cheap version of the attacker's position.

One check worth recording

Neither Debian nor Ubuntu nor Canonical has ever appeared as a vendor in the CISA catalogue of known exploited vulnerabilities. We checked the 4 November 2026 release, 1,768 entries. CVE-2026-109518 is not in it either, and nothing so far suggests it should be.

What is not established

  • Any exploitation. Nothing in the advisory or the announcement suggests this has been used.
  • A severity score. The advisory carries no CVSS.
  • The full affected version range. Debian publishes fixed versions, not a tested lower bound.
  • The technical detail from the finder. Max Justicz has published no write-up of this one, so the mechanism above is Debian's account rather than his.
  • Which Ubuntu releases have shipped the fix, and when.