Debian 11 security packages 404 and the archive is missing

Debian 11 security packages are in the worst possible state: the index says they exist, the files return 404, and there is no archive to fall back on. Bullseye LTS ended August 31, 2026. Almost a month later the bullseye-security suite is still being advertised by deb.debian.org while the packages behind it are being deleted, and archive.debian.org — the place every EOL Debian release eventually lands — has no bullseye-security at all. We checked this ourselves today. If you have a box still pointed at bullseye, apt update will tell you everything is fine and apt install will hand you a 404.

What actually happened

We pulled the live files rather than take anyone's word for it. As of September 27, 2026:

• The Release file is still served. https://deb.debian.org/debian-security/dists/bullseye-security/Release returns 200, dated Sat, 12 Sep 2026, suite oldoldstable-security, codename bullseye-security.
• The index still lists the packages. The updates/main amd64 Packages.gz lists 3,816 binary packages, including openssl version 1.1.1w-0+deb11u8.
• The package file is gone. .../pool/updates/main/o/openssl/openssl_1.1.1w-0+deb11u8_amd64.deb returns 404. The pool directory itself still returns 200. The metadata and the bits have diverged.
• There is no archived fallback. https://archive.debian.org/debian-security/dists/bullseye-security/ returns 404 — the directory does not exist. Debian 10's security archive is there, at dists/buster/updates/. Bullseye's is not.
• Non-security bullseye is fine. archive.debian.org/debian/dists/bullseye/Release returns 200. It is specifically the security suite that fell into the gap.

This was flagged on the debian-mirrors list on September 8 by a mirror operator watching the same divergence: indexes referencing deleted files, no archive snapshot to redirect to. Nineteen days later it is still broken. To be clear about what this is — an incomplete archival transition, not a compromise. That does not make it less disruptive.

Why a broken package archive matters for your business

Your CI is the thing that breaks first. Every FROM debian:11 image, every Ansible role with apt: name=openssl state=latest, every provisioning script written in 2022 and never touched since. The failure mode is nasty because apt update succeeds — the signed Release file and the indexes are valid. You only fail at fetch time, deep in a build, with a 404 on a package your index swears exists. That is a red pipeline on a Monday for a reason nobody on your team will guess.

"It still boots" is not a patch strategy. Bullseye left LTS four weeks ago. Right now the practical situation is worse than unsupported: you cannot even reinstall the last security build of openssl from the official mirror. If you are running bullseye in production today you have no supported patch path, and as of this week no reliable reinstall path either. The options are a real upgrade to bookworm or trixie, or Freexian's commercial ELTS, which is a paid subscription and a different set of repository URLs. Both are work. Pretending is not a third option.

Pin your base images to a digest, and mirror what you depend on. This is the second time this year a dependency we all treat as permanent infrastructure has quietly moved. If your build reaches out to a public mirror at build time, your build's reproducibility is somebody else's retention policy. Cache the packages you actually install, pin base images by digest rather than tag, and keep a local mirror of anything you cannot rebuild from scratch on demand.

Run the check now, not after the outage. grep -r bullseye /etc/apt/sources.list* on every host. grep -rn "debian:11\|bullseye" Dockerfile* across every repo. It takes ten minutes and tells you exactly how exposed you are.

Sources: debian-mirrors list, September 8, 2026, archive.debian.org, Debian LTS.