Geprüft. Dann getauscht.
Themenstand: 06.11.2026 · Für den Blog aufbereitet am 06.11.2026. Auf Basis vorhandener Postingtexte neu ausgearbeitet.
APT prüft das Paket. Trotzdem kann bei der Installation fremder Code mit Root-Rechten laufen. CVE-2026-109518 trifft den Übergang zwischen Prüfung und Nutzung – und macht schon den ersten Patchlauf zur entscheidenden Stelle.
Die Prüfung war erfolgreich. Die Datei ist eine andere.
Ein Paketmanager soll die Herkunft und Integrität der Pakete absichern, die er installiert. Genau diese Erwartung bricht CVE-2026-109518 an einer unangenehmen Stelle: Eine bereits geprüfte Paketdatei kann vor ihrer Verwendung durch andere Daten überschrieben werden.
Debian beschreibt, wie HTTP-Weiterleitungen zwei Downloads auf dieselbe Adresse führen können. Fehler beim Fortsetzen eines Downloads erlauben anschließend den Austausch der geprüften Datei. Bei der Installation können Paketskripte mit Root-Rechten ausgeführt werden. Die Sicherheitsmeldung DSA-6607-1 stammt vom 4. November 2026.
Welche Bedingungen zusammenkommen müssen
Der Angriff setzt voraus, dass jemand die HTTP-Paketantworten beeinflussen kann – etwa auf dem Übertragungsweg oder über einen bösartigen Mirror beziehungsweise Proxy. Hinzu kommen Weiterleitungen und ein erneut versuchter Paketdownload. Ein beliebig aus dem Internet erreichbarer Linux-Server ist damit allein noch kein nachgewiesenes Angriffsziel.
Entscheidend ist Acquire::Retries: Der Wert muss größer als null sein. Laut Debian-Tracker ist 3 ab Debian 12 und Ubuntu 22.04 die Voreinstellung. Ältere Releases können bei einer eigenen Retry-Konfiguration ebenfalls betroffen sein. Für die Bewertung zählen deshalb Distribution, APT-Version, Paketquellen und tatsächliche Konfiguration zusammen.
Den ersten Patchlauf absichern
Der Punkt, den ich zuerst prüfen würde: Das Update auf die sichere APT-Version startet mit dem bisher installierten APT. Ubuntu empfiehlt, beim Einspielen dieses Updates Download-Retries vorübergehend abzuschalten. Der dafür verwendete Parameter lautet -o Acquire::Retries=0.
Für Ubuntu nennt Canonical diesen vollständigen Ablauf: sudo apt update && sudo apt upgrade -o Acquire::Retries=0. Der Parameter steht beim Upgrade, das die Paketdateien herunterlädt und installiert. Für gezielte Updates führt der Hersteller eine eigene Variante auf. Den passenden Ablauf würde ich mit dem Advisory der eingesetzten Distribution abgleichen.
Fix-Versionen zum Gegenprüfen
Der Debian-Tracker führt für Debian 12 Bookworm APT 2.6.2 und für Debian 13 Trixie APT 3.0.4 als korrigierte Versionen. Entscheidend ist das zur jeweiligen Distribution gehörende Sicherheitsupdate; Versionsnummern aus unterschiedlichen Release-Zweigen lassen sich dafür nicht einfach austauschen.
Ubuntu nennt in USN-8996-1 unter anderem 2.4.15ubuntu0.1 für 22.04 LTS, 2.8.4ubuntu0.1 für 24.04 LTS, 3.2.1ubuntu0.1 für 26.04 LTS und 3.3.3ubuntu0.1 für 26.10. Für ältere Ubuntu-Versionen hängen die angebotenen Fixes teilweise von Ubuntu Pro beziehungsweise der jeweiligen erweiterten Support-Abdeckung ab. Die Herstellerlisten bleiben die Referenz für den konkreten Release.
HTTPS schützt den Weg. APT braucht den Fix.
HTTPS verhindert die hier relevante Manipulation durch einen Angreifer auf dem Transportweg. Ein bösartiger Mirror ist eine andere Vertrauensgrenze: Er liefert die Daten selbst aus. Ubuntu empfiehlt deshalb weiterhin das APT-Sicherheitsupdate. Retries für den Patchlauf auf null zu setzen schützt laut Hersteller auch gegenüber einem solchen Mirror.
Für mich gehört zur Kontrolle deshalb beides: Welchen Weg nehmen die Paketdownloads, und läuft danach tatsächlich die korrigierte APT-Version? Die Transportabsicherung und das Update beantworten unterschiedliche Teile dieser Prüfung.
Im tatsächlichen Build-Job nachsehen
Für Runner und Container-Images leite ich daraus eine praktische Reihenfolge ab: Zuerst die installierte APT-Version im laufenden Job erfassen. Dann das verwendete Basis- oder Runner-Image identifizieren, die Paketmanager-Komponenten dort aktualisieren und das Image neu bauen. Anschließend die neue Fassung ausrollen und im nächsten Job erneut die Version prüfen.
Ein gepatchter Host repariert kein altes Build-Image. Wenn ein Job weiterhin denselben alten Image-Stand startet, ist die Änderung am Host noch kein Beleg für den Zustand im Job. Ich würde deshalb die verwendete Image-Version oder ihren Digest zusammen mit dem Prüfergebnis dokumentieren.
Abgeschlossen ist es mit einem überprüften Ergebnis
Die offene Frage lautet für mich: Welches APT läuft jetzt wirklich – auf dem Server, im Runner und im Container? Eine abgeschlossene Update-Aufgabe sollte diese Frage mit einer überprüften Version und dem zugehörigen Release beantworten können.
Die hier geprüften Herstellerhinweise belegen die Schwachstelle und verfügbare Updates. Daraus leite ich keine Aussage ab, dass ein bestimmtes System bereits angegriffen wurde. Bei Hinweisen auf Manipulation braucht es zusätzlich eine Untersuchung; der installierte Fix allein beantwortet die Frage nach einem früheren Zugriff nicht.