APT-Sicherheitslücke CVE-2026-109518: Debian und Ubuntu sicher aktualisieren

Die praktische Antwort vor der großen Schlagzeile

Einem Paketmanager erlaube ich regelmäßig etwas, das ich sonst eher ungern aus der Hand gebe: eine komplette Linux-Installation zu verändern. Eine Lücke in seiner Paketprüfung verdient deshalb Aufmerksamkeit. Die sinnvolle Reaktion bleibt erfreulich unspektakulär: Distribution feststellen, installierte Pakete prüfen, die passende Korrektur beziehen und das Ergebnis kontrollieren.

CVE-2026-109518 kann dazu führen, dass APT ein ungeprüftes Paket mit Root-Rechten installieren lässt, wenn ein Angreifer den HTTP-Download beeinflussen kann. Debian veröffentlichte DSA-6607-1 am 4. November 2026. Dafür müssen eine Paketinstallation und bestimmte Downloadbedingungen zusammenkommen. Der Besuch irgendeiner Webseite löst diese APT-Lücke allein nicht aus.

Der Versionsstand dieses Artikels wurde am 5. November 2026 geprüft. Worldnode läuft mit Debian 13; damit ist das Thema für mich durchaus persönlich relevant. Einen neuen APT-Check auf diesem Server habe ich für diesen Beitrag aber nicht durchgeführt. Die folgenden Schritte helfen dir, den Zustand deines eigenen Systems nachvollziehbar zu prüfen.

Was APT normalerweise überprüft

APT löst Abhängigkeiten auf, lädt Pakete herunter und übergibt die Installation an dpkg. Ein Paketarchiv ist dabei mehr als ein Verzeichnis mit Dateien. Signierte Release-Metadaten verankern eine Prüfsummenkette über die Paketlisten bis zu den heruntergeladenen .deb-Dateien. Ein gewöhnlicher Spiegelserver kann deren Inhalt normalerweise nicht beliebig ersetzen und trotzdem diese Prüfung bestehen.

Das Handbuch zu apt-secure beschreibt eine wichtige Unterscheidung: Die Authentifizierung eines Archivs ist keine individuelle Prüfung einer Maintainer-Signatur auf jedem installierten Binärpaket. Die verkürzte Erklärung „jedes deb ist signiert“ führt deshalb am eigentlichen Vertrauensmodell vorbei.

Danach folgt eine zweite Grenze: die Installation mit administrativen Rechten. Pakete bringen Dateien und gegebenenfalls Maintainer-Skripte mit. Eine erfolgreich geprüfte Datei hilft nur, wenn der Installer anschließend noch genau diesen Inhalt verwendet. Verändert sich das zugrunde liegende Objekt unerwartet, kann eine korrekte kryptografische Prüfung ihre Schutzwirkung verlieren.

Die eigene Grafik am Artikelanfang zeigt diese Beziehung vereinfacht. Oben steht der normale Weg von authentifizierten Metadaten über geprüfte Paketbytes zur Installation. Die untere Markierung zeigt, wo Downloadverwaltung und Dateiidentität auseinanderlaufen konnten. Die für einen Angriff nötige Reihenfolge einzelner Anfragen gehört bewusst nicht in diese Erklärung.

Die Ursache: Weiterleitungen, Wiederholungen und Hardlinks

Die technische Meldung des APT-Teams vom 4. November beschreibt einen Prüfungsbypass durch HTTP-Weiterleitungen und vorübergehende Downloadfehler, die Wiederholungen auslösen. Unterschiedliche Downloadaufträge können dieselbe URI erhalten. Fehlerhafte Dateibehandlung beim Fortsetzen eines Downloads kann dann den Inhalt bereits geprüfter Pakete verändern.

Ein Hardlink ist ein zusätzlicher Verzeichniseintrag für dasselbe Dateiobjekt. Er erzeugt keine unabhängige Kopie. Wird der Inhalt über einen Namen geändert, sehen auch andere Hardlinks diesen geänderten Inhalt. Entscheidend ist hier die Verbindung zwischen Downloadzuordnung, gemeinsamem Dateiobjekt und dem Zeitpunkt der Prüfung. Dafür muss niemand einen Hashalgorithmus brechen.

Der Debian Security Tracker nennt die Voraussetzungen: Ein Angreifer muss HTTP-Verkehr beeinflussen können, Weiterleitungen und Downloadwiederholungen müssen zum Tragen kommen, und Acquire::Retries muss ungleich null sein. Ein bösartiger Mirror oder Proxy zählt dabei genauso wie ein Angreifer auf dem Übertragungsweg. Eine Paketinstallation liefert schließlich die privilegierte Aktion.

Für Debian 12 sowie Ubuntu 22.04 und die in den Meldungen genannten neueren Reihen sind Wiederholungen standardmäßig aktiviert. Ältere Systeme können betroffen sein, wenn Administratoren oder Skripte diese Einstellung nachträglich gesetzt haben. Ein historischer Standardwert ersetzt deshalb keine Prüfung des tatsächlich gestarteten Installationsbefehls.

Korrigierte Versionen: zuerst die Distribution zuordnen

Die Tabelle enthält die am 5. November geprüften Distributionsversionen für diese CVE. Spätere Pakete derselben unterstützten Reihe können die Korrektur ebenfalls enthalten. Debian und Ubuntu haben unterschiedliche Versionszweige. Eine Ubuntu-Version mit einem Debian-Grenzwert zu vergleichen, beantwortet die falsche Frage.

Für ältere Ubuntu-Versionen führt der Tracker ESM-Korrekturen auf: 20.04 mit 2.0.12+esm1, 18.04 mit 1.6.19+esm1, 16.04 mit 1.2.36+esm1 und 14.04 mit 1.0.1ubuntu2.24+esm4. Der Zugang hängt vom jeweiligen Supportkanal ab; für die ältesten Reihen ist Legacy Support relevant. „Korrektur veröffentlicht“ bedeutet noch nicht, dass die Quellen eines konkreten Rechners sie anbieten.

Debian Testing, Unstable, selbst gebaute APT-Pakete und Derivate brauchen eine eigene Zuordnung. Eine auf Ubuntu basierende Distribution kann andere Patches, Quellen und Versionszusätze verwenden. Maßgeblich bleibt deren Sicherheitsmeldung. Ein Debian-Paket aus einem anderen Release ist kein sinnvoller Ersatz, nur weil seine Nummer größer aussieht.

APT Security Check: den eigenen Rechner prüfen

Diese Webseite kann deine installierte APT-Version nicht auslesen. Sie nimmt keine Terminalausgaben entgegen, überträgt keine Diagnosedaten und speichert die Häkchen nicht. Die Auswahl grenzt lediglich die Hinweise ein. Sie berechnet keinen Sicherheitsstatus. Ohne JavaScript bleiben alle Referenzen und Befehle verfügbar.

1. Release und installierten Paketstand feststellen

cat /etc/os-release

apt --version

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

Die dpkg-Abfrage liefert die Paketrevision und damit mehr als eine reine Upstream-Versionsnummer. Epoch-Präfixe und Distributionszusätze gehören zum Ergebnis. Hier steht bewusst keine erfundene Beispielausgabe, die wie ein echter Check deines Servers aussieht.

2. Installiert und verfügbar auseinanderhalten

apt-cache policy apt

Installed beziehungsweise „Installiert“ beschreibt das vorhandene Paket. Der Kandidat ist die Version, die APT anhand seiner zwischengespeicherten Paketinformationen auswählt. Ein korrigierter Kandidat ist noch nicht installiert. Veraltete Listen können umgekehrt eine neue Korrektur verbergen. Laut apt-cache-Handbuch lassen sich diese Daten auch offline lesen; aktuell werden sie dadurch nicht.

3. Einstellungen lesen, ohne sie zu verändern

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

Der Filter zeigt passende Einträge in der für apt-config sichtbaren Konfiguration. Eine leere Ausgabe beweist nicht, dass beim tatsächlichen Frontend keine Wiederholungen aktiv sind. Programmstandards, APT_CONFIG, Dienstumgebungen und Kommandozeilenoptionen spielen ebenfalls hinein. Prüfe deshalb auch den verwendeten Wrapper oder Automatisierungsbefehl. Die APT-Konfigurationsreferenz erläutert die Rangfolge.

Für einen bewussten lokalen Versionsvergleich versteht dpkg --compare-versions die Debian-Sortierung einschließlich Epoch und Revision. Voraussetzung bleibt der richtige Grenzwert für genau diesen Distributionszweig. Auch ein korrekt berechneter Vergleich erkennt keine abweichende Patchhistorie eines fremden Eigenbaus.

Bleibt der Kandidat nach erfolgreicher Aktualisierung unterhalb der passenden Korrektur, prüfe die Sicherheitsquelle, den Aktualisierungsstand des Mirrors, Pinning und gegebenenfalls den Supportzugang. Pakete aus einer anderen Release-Reihe einzumischen, löst diese Unklarheit nicht sauber. Ein Hold kann die Installation ebenfalls verhindern, obwohl ein korrigierter Kandidat sichtbar ist. Auf mehreren Rechnern braucht deshalb jede eigenständige Installation ihren eigenen Prüfvermerk.

Das gilt auch für Systemabbilder: Ein aktualisierter Host schreibt die APT-Pakete in alten Containern oder Chroots nicht automatisch um. Prüfe, wo tatsächlich Paketinstallationen stattfinden und welche Images später neu ausgerollt werden. Eine vorhandene alte Paketdatei im Cache allein belegt dagegen weder einen laufenden Angriff noch den installierten Zustand. Halte diese Beobachtungen getrennt, bevor du daraus eine Maßnahme ableitest.

Die Korrektur mit vorübergehend abgeschalteten Wiederholungen installieren

Die folgenden Befehle verändern installierte Software. Prüfe auf Servern die geplante Transaktion und halte deinen üblichen Wiederherstellungsweg bereit. Ein -y ist absichtlich nicht enthalten: Lies die vorgeschlagenen Änderungen, bevor du bestätigst. Starte keine zweite Paketverwaltung parallel.

Ubuntus technische Meldung empfiehlt, die Paketinformationen zu aktualisieren und das Upgrade mit auf null gesetztem Retry-Wert auszuführen. In zwei bewusst getrennten Schritten lautet der allgemeine Weg:

sudo apt update

sudo apt upgrade -o Acquire::Retries=0

Schlägt das Aktualisieren der Quellen fehl, kläre zuerst den Fehler. Ein alter Kandidat ist keine zuverlässige Grundlage. apt update lädt Indizes; apt upgrade installiert Pakete. Diese Trennung beschreibt auch apt(8). Die Option gilt nur für den jeweiligen Aufruf und schreibt keine dauerhafte Konfiguration um.

Für Ubuntu dokumentiert die Meldung außerdem eine gezielte Alternative, wenn ein vollständiges Upgrade nicht passt. Nach erfolgreicher Aktualisierung der Listen lassen sich die bereits installierten Pakete aus dem APT-Quellpaket aktualisieren:

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

Die einfachen Anführungszeichen halten das Paketmuster zusammen. Das ist relevant, weil die betroffene Komponente auch die APT-Bibliothek umfasst. Nur die ausführbare Datei zu betrachten, wäre zu kurz gegriffen. Debian empfiehlt in DSA und DLA das Upgrade der APT-Pakete. Nutze die passende Sicherheitsquelle und prüfe Abhängigkeiten; der allgemeine Upgradeweg verwendet APTs dokumentierte Transaktionsoption.

Kontrolliere anschließend erneut die installierte Version und die Policy-Ausgabe. Unter Ubuntu zeigt der in der Meldung genannte Befehl apt list --installed '?source-package(^apt$)' die installierte Paketfamilie. Lange laufende grafische Paketverwaltungen können noch eine ältere Bibliothek geladen haben; starte solche Werkzeuge bei Bedarf neu. Ein APT-Update allein erzwingt nicht grundsätzlich einen Neustart des gesamten Rechners.

Was HTTPS zusätzlich schützt

HTTPS mit gültiger Zertifikatsprüfung verhindert, dass ein Angreifer auf dem Übertragungsweg den HTTP-Austausch einfach verändert. Das ist hier eine sinnvolle zusätzliche Schutzschicht. Die Vertrauenswürdigkeit des Endpunkts folgt daraus allerdings nicht: Auch ein bösartiger Mirror kann HTTPS anbieten. Die korrigierte APT-Version repariert die betroffene Paketprüfungsgrenze.

Wer Quellen auf HTTPS umstellt, sollte /etc/apt/sources.list und die Dateien unter /etc/apt/sources.list.d/ gezielt prüfen. Es gibt klassische .list-Dateien und deb822-Dateien mit der Endung .sources. Kontrolliere HTTPS-Unterstützung pro Mirror und erhalte Suite, Komponenten und Schlüsselzuordnung. Ein blindes Ersetzen über private und fremde Paketquellen kann andere Fehler erzeugen.

Zertifikatsprüfung und Archivauthentifizierung bleiben eingeschaltet. Eine Fehlermeldung durch Abschalten dieser Prüfungen zu umgehen, würde ausgerechnet den Schutz beseitigen, um den es hier geht. Ein abgebrochener Download bei deaktivierten Wiederholungen ist lästig. Er rechtfertigt einen erneuten kontrollierten Versuch, keine Installation ungeprüfter Pakete.

Die Fragen aus dem echten Administratoralltag

Bringt die normale Repository-Signatur noch etwas?

Ja. Die Lücke betrifft den Weg geprüfter Downloadinhalte bis zur Installation. Sie beweist nicht, dass Signaturen oder Hashes grundsätzlich nutzlos wären. Korrigierter Client und eingeschaltete Authentifizierung gehören zusammen.

Hat unattended-upgrades das längst erledigt?

Vielleicht. Belegen lässt sich das durch installierte Paketversionen und abgeschlossene Transaktionen. Quellen, Zeitplanung, Holds, Pinning und Fehler können automatische Updates beeinflussen. Meine frühere nginx-Prüfung auf Worldnode zeigt die Methode; sie enthält keinen neuen Beleg über dessen APT-Stand.

Kann ich einen Offline-Server prüfen?

Release-Datei und dpkg-Abfragen funktionieren ohne Netz. Ein zwischengespeicherter Kandidat belegt keine aktuelle Verfügbarkeit. Für Offline-Updates brauchst du den passenden Paketsatz und authentifizierte Repository-Informationen über einen vertrauenswürdigen Transferweg. Eine beliebige deb-Datei samt danebenliegender Prüfsumme ersetzt diese Vertrauenskette nicht.

Beweist das Update, dass vorher nichts passiert ist?

Nein. Ein Paketstand beschreibt den Patchzustand, kein forensisches Ergebnis. Konkrete Hinweise auf eine Kompromittierung wären separat zu untersuchen. Die Veröffentlichung einer Sicherheitsmeldung allein ist noch kein Hinweis auf einen Angriff auf deinen Rechner.

Was gilt für grafische Installer und Derivate?

Frontends auf Basis der betroffenen APT-Bibliothek nutzen dieselbe relevante Komponente. Snap verwendet eine andere Paketverwaltung. Bei Derivaten entscheiden deren Meldung und Paketherkunft; eine Versionsfreigabe für Ubuntu lässt sich nicht beliebig übertragen.

Mit einem überprüfbaren Ergebnis abschließen

1. Release, installierte APT-Paketfamilie und Paketherkunft festhalten.
2. Passenden Security Tracker und Versionsgrenzwert lesen.
3. Vertrauenswürdige Quellen erfolgreich aktualisieren und Transaktion prüfen.
4. Korrektur installieren und die dokumentierte Retry-Abschaltung verwenden.
5. Installierte Versionen und erfolgreichen Transaktionsabschluss bestätigen.
6. Automatische Updates, private Mirrors und Wrapper mitbetrachten.

Die dauerhafte Lehre ist einfach: Authentifizierung muss bis zur tatsächlichen Verwendung halten. Ein Paketmanager kann gute Kryptografie einsetzen und trotzdem einen Fehler in seiner Dateiverwaltung haben. Für normale Anwender zählt ein unterstütztes System mit nachweislich installierter Korrektur. Für Administratoren kommt ein nachvollziehbarer Prüfvermerk hinzu. Dramatische Hackerbilder braucht es dafür zum Glück nicht.