The Other APT: Why Ignored Bug Reports Help Attackers

On 4 November, Debian, Ubuntu and APT's maintainer released fixes for CVE-2026-109518. The flaw in APT, the tool that installs software on Debian and Ubuntu, lets an attacker on the network path get their own package installed and run as root. The fix credits another researcher, who says he found it with an AI model in two hours.

We found the same bug and reported it to APT's maintainer and to Debian at the end of September, about five weeks before the fixes went out. We never got a reply.

This isn't a claim for credit. It doesn't matter who finds a bug or who fixes it. What matters is that reports get answered, because an unanswered report keeps a hole open for the other kind of APT: the advanced persistent threats, who don't file bug reports at all.

The bug in plain words

APT is the tool that installs software on Debian, Ubuntu and every distribution built on them. Before it installs a package, it checks the download against a hash from the signed archive index. Installing then runs the package's scripts as root, so that check is the whole defense.

CVE-2026-109518 breaks the check. When a download fails and APT retries it, APT reopened the file it was writing to without making sure the file was its own. That file could be a hard link, a second name for a file that another download was also using. An attacker who can tamper with APT's traffic can use that to swap in a different package after APT has verified the real one.

The official CVE record puts the result bluntly: an attacker "can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges."

The attacker doesn't need a login. They need to sit on the network path: a hostile Wi-Fi network, a compromised router, a malicious mirror or a proxy. Most Debian and Ubuntu systems fetch packages over plain HTTP by default, and download retries are on by default from Debian 12 and Ubuntu 22.04.

Are you affected, and how to patch

Whatever you think of how this bug came to light, patch it. You're exposed in practice if APT retries downloads, which is the default from Debian 12 and Ubuntu 22.04 onward, and fetches packages over a network someone could tamper with.

Check your APT version:

dpkg-query -W -f='${Version}\n' apt

Fixed versions are 3.0.4 (Debian 13), 2.6.2 (Debian 12), 2.8.4ubuntu0.1 (Ubuntu 24.04) and 2.4.15ubuntu0.1 (Ubuntu 22.04). On Ubuntu, a version ending in ubuntu0.1 means the fix has arrived.

Update APT, with retries off while it downloads its own fix:

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

The vulnerable APT downloads the fixed one, so turning retries off for that one install closes the gap, as Ubuntu recommends. No reboot is needed.

Don't forget containers and CI. The official Debian and Ubuntu images on Docker Hub still shipped the vulnerable APT on 4 November. Rebuild your images, or upgrade APT with the command above before any other apt-get install in your Dockerfile.

If you can't patch yet, turn retries off until you can:

echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518

That removes a condition the attack needs, but it doesn't fix APT. Use HTTPS sources where your mirror offers them, install only over networks you trust, and remove the file once you've updated.

Our report

It started before we operated under the Nergal name. While testing for a client where the stakes are high, our tooling kept raising findings that looked like false positives. They were too coherent to dismiss, so we kept digging.

Deeper research confirmed they were real. Using narrow agentic testing, an AI agent aimed at one target with training data chosen to fit that single objective closely, we pinned the flaw down by the end of September: a retried download could make APT install a package other than the one it had verified.

We wrote it up and sent it privately to APT's maintainer and to Debian, the two places a report like this should go.

We never heard back. There was no acknowledgement, no follow-up question and no note saying the bug was already known. We have kept our original report and its timestamps, but we aren't publishing them. This post isn't about proving who was first.

On 12 October, about two weeks after our report, APT's maintainer wrote the fix. We learned it existed when the advisories went public on 4 November.

Then it surfaced elsewhere

On 12 October, APT's maintainer, Julian Andres Klode, wrote the fix: "methods: Open target files exclusively." The commit credits Max Justicz as the reporter. Fixed releases for Debian 12 and 13 and most older APT branches were ready by 2 November, and everything went public on 4 November in a coordinated release:

• APT 3.3.6 was released upstream that morning (APT developers' advisory).
• Canonical published the CVE record, rated High.
• Debian issued DSA-6607-1, which opens: "Max Justicz discovered a vulnerability in the APT package manager."
• Ubuntu followed in the afternoon with USN-8996-1.

Later that day, Justicz posted about it: "I used an AI for two hours and found a zero-day that would let a nation-state hack any server running stock Ubuntu. It was patched this morning." In the thread, he said he had pointed an AI model at APT, which found the bug two hours later, and that "we need to urgently audit and patch everything important on the internet using powerful AI models."

He isn't wrong about that. Justicz has a track record here: he found an earlier APT flaw, CVE-2019-3462, in 2019. Independent rediscovery is common in security, and it is getting more common as AI tools make this kind of hunting faster.

But the public story now has a single beginning, and it isn't where this bug's story started for us.

Where the process broke

We don't know what happened to our report. Maybe it arrived after another one and was treated as a duplicate. Maybe it sat unread in an inbox. Either way, nobody told us, and that silence is the problem.

To be fair, the fix itself wasn't slow. Preparing coordinated fixes for every APT branch across Debian, Ubuntu and their derivatives in about five weeks is solid work. The failure is smaller, and easier to fix: a report that never got an answer.

Silence has a cost

• The reporter is left blind. We couldn't tell whether the bug was being fixed, whether it was already known or when it would go public, so we couldn't plan how to protect the people who rely on us.
• It pushes reporters toward worse choices. Some go public early to force a response. Others stop reporting. Neither helps anyone.
• A duplicate is a warning, not noise. When two unrelated teams find the same bug within weeks, it's easy to find. Assume someone without good intentions can find it too.

AI is shrinking the window

Both discoveries of this bug involved AI. The other researcher says a general-purpose model found it in two hours. We found it with a narrow agent built for this kind of target. The same tools, and others like them, are available to attackers.

That changes the math on an unanswered report. When finding a bug takes hours instead of weeks, the gap between the first private report and the first attacker who finds it independently can be short. Every week a report sits unread is a week the other APTs get for free. They don't file reports, and they don't wait for a coordinated release.

In this case, the fix did ship. But on 4 November, the official Debian and Ubuntu container images still carried the vulnerable APT, and Debian testing and several derivatives had no fix yet. The slower the start of the process, the longer that tail.

What we'd ask

Of maintainers and security teams:

• Answer every report, even with one line. "Received" or "already known, fix in progress" takes a minute, and it tells the reporter the bug is in hand so they can stay quiet while you work.
• Tell duplicate reporters they're duplicates, and consider crediting independent finders together. A CVE record can carry more than one credit.
• Publish how to report and how fast you'll respond, so a report doesn't depend on reaching the right person on the right day.

Of fellow researchers:

• Take coherent "false positives" seriously. If they fit together too neatly, look again. Ours turned out to be real.
• Keep records of what you sent, when and to whom.
• Follow up on a schedule, for example after two weeks, and widen the circle if nothing comes back: a distribution's security team, another affected vendor or a coordination center such as CERT/CC.
• Assume you aren't the only one who has found it. With today's tools, you almost certainly aren't.

It doesn't matter who finds a bug or who fixes it. It matters that somebody answers.

Sources

• Debian security advisory DSA-6607-1 and Debian's security announcement
• Debian security tracker: CVE-2026-109518
• Ubuntu security notice USN-8996-1
• Ubuntu: CVE-2026-109518 APT vulnerability fixes available
• APT developers' advisory
• CVE record: CVE-2026-109518