Linux-Server patchen und Paketquellen absichern lassen? WZ-IT übernimmt Patching und Härtung in der Linux-Server-Betreuung ab 149,90 € netto pro Monat für den ersten Server und bewertet neue Lücken im CVE-Monitoring. Termin vereinbaren
Am 4. November 2026 haben Debian und Ubuntu Sicherheitsupdates für den Paketmanager APT veröffentlicht. CVE-2026-109518 betrifft den HTTP-Download von Paketen: Ein Angreifer, der den HTTP-Verkehr zwischen einem System und seinem Paketarchiv manipulieren kann, etwa über einen bösartigen Mirror oder Proxy, kann dem Client ein ungeprüftes Paket unterschieben. Die Skripte des Pakets laufen bei der Installation als root. Canonical bewertet die Lücke mit CVSS 4.0 7.7 (High), das APT-Team nennt sie „critical“.
APT ist hier der Paketmanager apt und keine Angreifergruppe. Betroffen sind alle Programme, die die APT-Bibliothek nutzen: apt, apt-get, aptitude und grafische Oberflächen (Ubuntu). Dieser Beitrag nennt die Fixversionen je Distribution, die Bedingungen für einen Angriff, die Prüfbefehle für Admins und die Reihenfolge, in der sich APT sicher aktualisieren lässt. Das schließt Proxmox VE ein. Alle Angaben haben den Stand 9. November 2026.
Inhaltsverzeichnis
- Die Lücke in Kürze
- Wie ein geprüftes Paket ausgetauscht werden kann
- Wann ein System angreifbar ist
- Fixversionen für Debian
- Fixversionen für Ubuntu
- Proxmox VE und andere Debian-basierte Systeme
- Prüfen: APT-Version, Paketquellen und Retries
- Patchen: die richtige Reihenfolge
- Härtung: Paketquellen auf HTTPS umstellen
- Automatische Updates und Images prüfen
- Exploit-Status und Einordnung
- Verbreitete Irrtümer
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Die Lücke in Kürze
| Merkmal | Wert |
|---|---|
| Kennung | CVE-2026-109518, vergeben von Canonical |
| Veröffentlicht | 4. November 2026 |
| Titel im CVE-Eintrag | „APT RCE via hard link reuse“ |
| Komponente | HTTP-Backend der APT-Bibliothek, gilt für apt, apt-get, aptitude und grafische Frontends |
| CWE | CWE-62 (UNIX Hard Link), CWE-367 (Time-of-check Time-of-use) |
| CVSS 4.0 | 7.7 High, CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
| Einstufung des APT-Teams | „critical file verification bypass“ |
| NVD | Stand 9. November 2026 ohne eigene Bewertung (Status „Received“) |
| Voraussetzungen | Angreifer, der den HTTP-Verkehr manipulieren kann (auch bösartiger Mirror oder Proxy), Weiterleitungen werden gefolgt, Acquire::Retries ungleich 0, eine Paketinstallation läuft |
| Folge | Installation eines vom Angreifer kontrollierten Pakets, Codeausführung als root |
| Nicht betroffen | Snap-Pakete, Transport per FTP |
| Gemeldet von | Max Justicz; Korrektur von Julian Andres Klode |
| Fix-Commit | 5af16a8a „methods: Open target files exclusively“ vom 12. Oktober 2026 |
Quellen: CVE-Eintrag, Debian Security Tracker, Ubuntu, Ubuntu-Blog, APT-Ankündigung, Fix-Commit.
Zu den Metriken (CVSS-4.0-Spezifikation): AT:P bedeutet, dass besondere Bedingungen im Zielsystem vorliegen müssen; nach den Herstellerangaben gehören dazu Acquire::Retries ungleich 0 und manipulierbarer HTTP-Verkehr. UI:P bedeutet eine passive, unfreiwillige Interaktion: Die Paketinstallation löst den Angriff aus, ohne dass jemand bewusst eingreift. Anmeldung und Rechte sind nicht nötig (PR:N), die Auswirkung auf das angegriffene System ist in allen drei Schutzzielen hoch.
Wie ein geprüftes Paket ausgetauscht werden kann
Das Signaturschema eines Archivs verhindert Manipulationen von Paketen normalerweise auch bei HTTP-Transport (Ubuntu). Bei CVE-2026-109518 greift der Angriff an einer anderen Stelle an, nämlich bei der Dateibehandlung des Downloads. Die Quellen beschreiben das mit unterschiedlichen Worten:
| Quelle | Beschreibung |
|---|---|
| Debian DSA-6607-1 | APT kann zwei verschiedene Paket-Downloads zusammenführen, wenn eine HTTP-Weiterleitung ihnen dieselbe URI gibt. Fehlerhafte Dateibehandlung beim Wiederaufnehmen eines HTTP-Downloads erlaubt es einem Man-in-the-Middle, ein Paket nach der Verifikation zu ersetzen, was zur Ausführung beliebigen Codes als root führt |
| APT-Team | Ein Angreifer kann die Prüfung heruntergeladener Pakete mit Weiterleitungen und üblichen vorübergehenden HTTP-Serverfehlern umgehen; APT überschreibt dabei vorhandene Hard Links mit einer Nutzlast nach Wahl des Angreifers |
| Ubuntu | Die Lücke erlaubt, APT ein Paket installieren zu lassen, obwohl es die Signaturprüfung nicht besteht |
| Fix-Commit | Das Öffnen und Verändern vorhandener Dateien kann bei Hard Links andere Dateien unerwartet verändern. Die Korrektur öffnet alle Zieldateien exklusiv; beim Wiederaufnehmen eines Downloads wird die alte Datei dabei entlinkt |
Gemeinsam ist den Beschreibungen die Kette aus Weiterleitung, vorübergehendem Fehler, Wiederholung des Downloads und Hard Link. Der zur Korrektur gehörende Integrationstest lädt eine Datei auf einen Hard Link zu einer Opferdatei, auf einen Hard Link zu einer teilweise geladenen Datei (Wiederaufnahme, HTTP-Status 206) und auf einen Symlink und prüft jeweils, dass die Opferdatei unverändert bleibt.
Wie genau sich die Formulierungen „nach der Prüfung ersetzt“ und „besteht die Signaturprüfung nicht“ zueinander verhalten, geht aus den öffentlichen Quellen nicht hervor. Einen technischen Bericht des Entdeckers haben wir bis zum 9. November 2026 nicht gefunden. Unsere Einschätzung: Für die Praxis ändert das nichts. Die Signaturprüfung allein schützt bei dieser Lücke nicht, und die Korrektur liegt in der Dateibehandlung von APT.
Hintergrund: Derselbe Forscher meldete 2019 mit CVE-2019-3462 eine ähnliche Klasse von Fehlern, damals in der Behandlung von HTTP-Weiterleitungen in APT. In seinem Bericht von 2019 war der Workaround, Weiterleitungen beim Update abzuschalten. Für CVE-2026-109518 nennen die Hersteller dagegen Acquire::Retries=0 und HTTPS.
Wann ein System angreifbar ist
Die Lücke ist kein Angriff „aus dem Internet auf jeden Server“. Der Angreifer braucht eine Position im Weg der Pakete.
| Bedingung | Beleg | Prüfung |
|---|---|---|
| APT-Version unter der Fixversion | CVE-Eintrag | dpkg-query -W apt |
| Angriff im Datenpfad: HTTP-Verkehr, den ein Angreifer manipulieren kann | Ubuntu: TLS schützt gegen diesen Fall, weil der Angriff manipulierten HTTP-Verkehr voraussetzt | Paketquellen mit http:// |
| Alternativ: bösartiger Mirror oder Proxy | Debian Tracker | Mirror, Proxy, Netzweg |
| APT folgt Weiterleitungen und wiederholt Downloads | Debian Tracker: Acquire::Retries ungleich 0 |
Acquire::Retries, Standard 3 |
| Eine Paketinstallation läuft | Ubuntu: Auslöser ist die Installation von Paketen | manuelles oder automatisches Update |
Der Standardwert von Acquire::Retries ist seit APT 2.3.2 gleich 3 (APT-Changelog: „Enable the Acquire::Retries option by default, set to 3“). Er gilt ab Debian 12 und Ubuntu 22.04. Ältere Releases sind in der Standardkonfiguration nicht betroffen (Debian Tracker).
Was das in typischen Umgebungen bedeutet:
- Server mit Standardquellen über HTTP: Der Angreifer muss im Datenpfad sitzen. Unsere Einschätzung: Das kann ein kompromittierter Router sein, ein geteiltes Netzsegment oder ein Netzbetreiber. Je mehr fremde Netze die Pakete ohne HTTPS durchqueren, desto eher ist diese Position erreichbar.
- Mirror und Proxy: Der CVE-Eintrag nennt bösartige Mirror und Proxys ausdrücklich. Unsere Einschätzung: Interne Mirror (zum Beispiel aptly, Artifactory), Caching-Proxys (zum Beispiel apt-cacher-ng, Squid) und Unternehmens-Proxys gehören zum Datenpfad; die Produkte haben wir nicht einzeln geprüft. Wer sie per HTTP anspricht, hat die Strecke zwischen Client und Zwischenstation ungeschützt, und ein übernommener Mirror kann die Lücke direkt ausnutzen.
- Bösartiger Mirror über HTTPS: HTTPS nennt Ubuntu nur gegen den Angriff im Datenpfad. Gegen einen bösartigen Mirror nennt Ubuntu
Acquire::Retries=0und das Update. - Container und Vorlagen: Ein Image oder eine VM-Vorlage auf Debian- oder Ubuntu-Basis kann APT in einer älteren Version enthalten, nämlich in der, die beim Bau installiert wurde; Images ohne Paketmanager enthalten keines. Unsere Einschätzung: Solange das Basis-Image nicht aktualisiert ist und der Build APT nicht als ersten Schritt aktualisiert, läuft
apt-getim Build mit der alten Version. - Ältere Releases: Sobald jemand
Acquire::Retriesin einem Skript, einer CI-Konfiguration oder Ansible-Rolle auf einen Wert ungleich 0 gesetzt hat und die übrigen Voraussetzungen erfüllt sind, gilt die Lücke auch dort. Das APT-Team weist darauf hin, dass viele Benutzerskripte die Option in älteren Releases verwendet haben könnten.
Fixversionen für Debian
| Debian-Release | Verwundbare Version laut Tracker | APT gefixt | Advisory | Hinweis |
|---|---|---|---|---|
| 13 trixie | 3.0.3 | 3.0.4 | DSA-6607-1 | über trixie-security |
| 12 bookworm | 2.6.1 | 2.6.2 | DLA-4880-1 | über bookworm-security |
| 11 bullseye | - | 2.2.5 | ELA-1880-1 | über Freexian ELTS |
| 10 buster | - | 1.8.2.4 | ELA-1880-1 | über Freexian ELTS |
| 9 stretch | - | 1.4.12 | ELA-1880-1 | über Freexian ELTS |
| forky (testing) | - | 3.3.6 | - | Entwicklungszweig |
| sid (unstable) | - | 3.3.7 | - | Korrektur seit 3.3.6 |
Quellen: Debian Security Tracker, Freexian-ELTS-Tracker. Die Paketindizes von security.debian.org (amd64 und arm64) führten am 9. November 2026 für trixie-security APT 3.0.4 und für bookworm-security APT 2.6.2. Die Tabelle nennt die Fixversionen laut Tracker, keine Zusage zur Verfügbarkeit auf jeder Architektur.
Der CVE-Eintrag und der Debian Security Tracker nennen APT 3.3.6 als Korrektur im Entwicklungszweig (unstable); stabile Releases erhalten 3.0.4 und 2.6.2. Das APT-Team führt Korrekturen für die Zweige 1.2.y bis 3.2.y: 1.2.36, 1.4.12, 1.6.19, 1.8.2.4, 2.0.12, 2.2.5, 2.4.15, 2.6.2, 2.8.4, 3.0.4 und 3.2.1 (APT-Ankündigung).
Debian 11 hat die reguläre LTS-Phase am 31. August 2026 beendet (Debian). Die Korrektur (APT 2.2.5, ELA-1880-1) liefert Freexian mit dem kommerziellen Extended-LTS-Angebot (ELTS); ELTS ist ein Dienst von Freexian und gehört nicht zum Debian-Projekt (Freexian-FAQ). Die Termine aller Distributionen stehen im Ratgeber Linux End of Life.
Fixversionen für Ubuntu
| Ubuntu-Release | APT gefixt | Bezug |
|---|---|---|
| 26.10 stonking | 3.3.3ubuntu0.1 | Standard-Updates |
| 26.04 LTS resolute | 3.2.1ubuntu0.1 | Standard-Updates |
| 24.04 LTS noble | 2.8.4ubuntu0.1 | Standard-Updates |
| 22.04 LTS jammy | 2.4.15ubuntu0.1 | Standard-Updates |
| 20.04 LTS focal | 2.0.12+esm1 | Ubuntu Pro |
| 18.04 LTS bionic | 1.6.19+esm1 | Ubuntu Pro |
| 16.04 LTS xenial | 1.2.36+esm1 | Ubuntu Pro mit Legacy-Support-Add-on |
| 14.04 LTS trusty | 1.0.1ubuntu2.24+esm4 | Ubuntu Pro mit Legacy-Support-Add-on |
Quellen: USN-8996-1, Ubuntu CVE-Seite. Die amd64-Paketindizes von security.ubuntu.com führten am 9. November 2026 in den Security-Suiten von jammy, noble und resolute genau diese Versionen.
Ubuntu 22.04 und neuer sind standardmäßig betroffen (bei erfüllten übrigen Voraussetzungen). Ältere Releases sind es nur, wenn Acquire::Retries auf einen Wert ungleich 0 gesetzt ist (Ubuntu-Blog).
Proxmox VE und andere Debian-basierte Systeme
Proxmox VE nutzt APT wie jedes Debian-System (Proxmox, Package Repositories). Der Fix kommt deshalb aus den Debian-Repositories: In den geprüften amd64-Paketindizes von pve-no-subscription für trixie und bookworm steht kein Paket apt (eigene Prüfung am 9. November 2026).
| Proxmox VE | Debian-Basis | APT-Fix | Hinweis |
|---|---|---|---|
| 9.x | 13 trixie | 3.0.4 (DSA-6607-1) | neueste in der Proxmox-FAQ aufgeführte Version |
| 8.x | 12 bookworm | 2.6.2 (DLA-4880-1) | laut Proxmox-FAQ Proxmox-Supportende im August 2026 |
Für Proxmox-Hosts sind vier Punkte relevant:
- Quellen: Die Proxmox-Dokumentation für Proxmox VE 9 führt die Debian-Basisrepositories mit
http://deb.debian.org/debian/undhttp://security.debian.org/debian-security/auf, das No-Subscription-Repository mithttp://download.proxmox.com/debian/pve. Das Enterprise-Repository verwendethttps://enterprise.proxmox.com/debian/pve. Ein Host mit diesen Standardquellen und dem StandardwertAcquire::Retries 3erfüllt auf dem Host die Voraussetzungen HTTP und Retries; es fehlen nur noch ein Angreifer im Datenpfad (oder ein kontrollierter Mirror) und eine laufende Paketinstallation. - HTTPS:
deb.debian.orgundsecurity.debian.orglieferten am 9. November 2026 ihre Release-Dateien über HTTPS aus. Fürdownload.proxmox.comdeckte das Zertifikat den Hostnamen in unserer Prüfung nicht ab (Zertifikat fürenterprise.proxmox.com), HTTPS ist dort also nicht ohne Weiteres möglich. Für Hosts mit No-Subscription-Repository bleibt das Update der entscheidende Schritt. - Update-Weg: Proxmox empfiehlt
apt updateundapt full-upgradeoder die Oberfläche; ein einfachesapt upgradekann zu einem teilweise aktualisierten oder defekten Paketzustand führen (Proxmox, Host System Administration). Proxmox VE prüft täglich auf Updates und benachrichtigt den Benutzerroot@pamper E-Mail, wenn der Mailversand des Hosts eingerichtet ist (Proxmox, Package Repositories); eingespielt werden die Updates über die Oberfläche oder die Kommandozeile. - Gäste: Ein Gast mit Debian oder Ubuntu, ob VM oder LXC-Container, hat sein eigenes APT, sofern es dort installiert ist. Das Update auf dem Host ändert nichts am APT in den Gästen.
Einen eigenen Hinweis von Proxmox zu CVE-2026-109518 haben wir bis zum 9. November 2026 nicht gefunden. Der CVE-Eintrag nennt auch abgeleitete Distributionen; maßgeblich ist dort die installierte APT-Version und der Stand des jeweiligen Herstellers. Unterstützung beim Betrieb gibt es auf den Seiten Proxmox-Beratung und Betrieb und Managed Proxmox.
Prüfen: APT-Version, Paketquellen und Retries
1. Installierte APT-Version und Vergleich mit der Fixversion
dpkg -l apt
dpkg-query -W -f='${Package} ${Version}\n' apt
apt-cache policy apt
Installed muss mindestens der Fixversion der Distribution entsprechen. Candidate zeigt nach apt update die verfügbare Version. Der Vergleich lässt sich skripten (fixed je Release aus den Tabellen setzen):
fixed=3.0.4 # trixie; bookworm: 2.6.2, noble: 2.8.4ubuntu0.1, jammy: 2.4.15ubuntu0.1
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' apt)" ge "$fixed" && echo "Fixversion erreicht" || echo "Fixversion nicht erreicht"
Der Vergleich prüft nur die Versionsnummer des Pakets apt gegen die Fixversion des eigenen Release-Zweigs. Schlägt die Abfrage fehl oder stammt das System aus einem anderen Zweig (abgeleitete Distribution, Backport), ist das Ergebnis nicht aussagekräftig; dann gilt der Tracker-Eintrag der Distribution. Auf Ubuntu nennt Canonical zusätzlich apt list --installed '?source-package(^apt$)', das auch die zum Quellpaket gehörenden Pakete anzeigt.
2. Paketquellen mit HTTP finden (klassische .list-Dateien und deb822-.sources-Dateien)
grep -rniE --include='*.list' --include='*.sources' \
'^[[:space:]]*(deb|deb-src)[[:space:]]+(\[[^]]*\][[:space:]]+)?(mirror\+)?http://|^[[:space:]]*URIs:.*(mirror\+)?http://|^[[:space:]]+(mirror\+)?http://' \
/etc/apt/sources.list /etc/apt/sources.list.d/
Der Ausdruck findet Zeilen im Einzeilen-Format (auch mit Optionen in eckigen Klammern), URIs:-Zeilen im deb822-Format (auch mit mehreren Adressen) und Fortsetzungszeilen, die mit einer Adresse beginnen. Er liest nur *.list- und *.sources-Dateien, auskommentierte Zeilen werden ignoriert. Das ist eine erste Sichtprüfung, keine vollständige Bestandsaufnahme: Quellen-Blöcke mit Enabled: no erscheinen ebenfalls in der Ausgabe. Ergänzend zeigt apt-cache policy die Quellen im Paketcache; der Stand entspricht dem letzten apt update:
apt-cache policy | grep -E '^ +[0-9]+ http://'
3. Retries, Proxy und Weiterleitungen
apt-config dump | grep -iE 'retries|proxy|allowredirect'
grep -rniE 'retries|proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d/ 2>/dev/null
apt-config dump zeigt die wirksame Konfiguration, einschließlich einiger Werte, die APT beim Start selbst setzt. Acquire::Retries gehört nicht dazu: Fehlt der Eintrag in der Ausgabe, gilt auf Releases ab Debian 12 und Ubuntu 22.04 der eingebaute Standardwert 3, auf älteren Releases bedeutet ein fehlender Eintrag keine Wiederholungen. Das ergibt sich aus dem APT-Quellcode in Version 3.0.4, der den Wert beim Anlegen jedes Download-Eintrags mit FindI("Acquire::Retries", 3) liest, ohne ihn in die Konfiguration zu schreiben. Ein Proxy-Eintrag (Acquire::http::Proxy) mit einer Adresse weist auf einen Zwischenpunkt im Datenpfad hin. Der Wert DIRECT schaltet den Proxy ab, und hostspezifische Einstellungen (Acquire::http::Proxy::<Host>) können ihn für einzelne Hosts ändern (apt-transport-http(1)).
4. Wurde APT schon aktualisiert?
zcat -f /var/log/apt/history.log* | awk '
/^Start-Date:/ { d = $0; c = "" }
/^Commandline:/ { c = $0 }
/^Upgrade:/ && / apt:[a-z0-9]+ \(/ { print d; if (c != "") print c; print $0; print "" }'
Die Ausgabe zeigt je Upgrade des Pakets apt den Zeitpunkt (Start-Date), den protokollierten Aufruf (Commandline, sofern vorhanden) und die Upgrade-Zeile mit alter und neuer Version, auch aus rotierten Protokollen. Ein Eintrag mit Commandline: /usr/bin/unattended-upgrade zeigt, dass unattended-upgrade das Upgrade ausgeführt hat. Ob der Aufruf vom Timer oder von Hand kam, zeigt der Abgleich des Zeitpunkts mit dem Journal der apt-daily*-Dienste. Ob die Behebung vollständig ist, zeigt die installierte Version (Befehl 1).
Patchen: die richtige Reihenfolge
Das Problem bei der Reihenfolge: APT lädt seine eigene Korrektur mit der verwundbaren Version herunter. Ubuntu empfiehlt, die Wiederholung von Downloads für das Update abzuschalten und, wo möglich, vorher HTTPS zu aktivieren. Gegen einen Angreifer im Datenpfad stellt TLS vor dem Einspielen laut Ubuntu sicher, dass es keinen Zeitpunkt gibt, zu dem er die Lücke noch ausnutzen könnte; gegen einen bösartigen Mirror hilft laut Ubuntu das Abschalten der Wiederholungen beim Update (Ubuntu-Blog).
Schritt 1: Bestand erfassen. APT-Version, Distribution und Paketquellen aller Server, dazu Container-Basis-Images und Vorlagen (Abschnitt Prüfen).
Schritt 2: HTTP-Quellen wo möglich auf HTTPS umstellen (nächster Abschnitt). Quellen, die HTTPS nicht anbieten, bleiben auf HTTP; für sie gelten die Schritte 3 und 4.
Schritt 3: Automatische Läufe absichern, bevor APT aktualisiert wird. Unsere Empfehlung: vor dem Update eine Konfigurationsdatei anlegen, damit auch das vorangehende apt update und der Lauf von unattended-upgrades ohne Wiederholungen arbeiten.
echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518-retries
Ob der Wert wirksam ist, zeigt apt-config dump | grep -i retries. Spätere Konfigurationsdateien in /etc/apt/apt.conf.d/, die Hauptdatei /etc/apt/apt.conf und Kommandozeilenoptionen können ihn überschreiben (Lesereihenfolge laut apt.conf(5)).
Schritt 4: APT mit abgeschalteten Wiederholungen aktualisieren. Der Befehl für das gesamte System stammt von Ubuntu und funktioniert auch auf Debian:
sudo apt update && sudo apt upgrade -o Acquire::Retries=0
Die Option -o Acquire::Retries=0 gilt nur für den Aufruf, an dem sie steht, hier also für apt upgrade, nicht für das vorangehende apt update; für apt update gilt die konfigurierte Einstellung, mit der Datei aus Schritt 3 also der Wert 0.
Wenn nicht alle Pakete aktualisiert werden sollen, nennt Canonical den gezielten Aufruf für alle Pakete des Quellpakets apt, also auch die zugehörigen Bibliotheken:
sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'
Kennt die installierte APT-Version den Selektor nicht, bleibt das vollständige Update. Auf Proxmox-Hosts gilt statt apt upgrade die Proxmox-Empfehlung apt full-upgrade; der gezielte Aufruf mit dem Selektor ist dort der erste Schritt, das vollständige Update folgt im Wartungsfenster.
Schritt 5: Ergebnis prüfen und festhalten. Die Version mit dem Vergleich aus dem Abschnitt Prüfen kontrollieren und je Host dokumentieren.
Schritt 6: Temporäre Einstellungen zurückbauen. Die Datei aus Schritt 3 wieder entfernen. Danach gilt die Einstellung, die ohne die Datei gegolten hat: der Standardwert oder ein Wert aus einer anderen Konfigurationsdatei. apt-config dump | grep -i retries zeigt, ob dort ein Wert steht.
sudo rm /etc/apt/apt.conf.d/99-cve-2026-109518-retries
Schritt 7: Images und Vorlagen aktualisieren. Basis-Images durch aktualisierte Versionen ersetzen oder im Build APT als ersten Schritt aktualisieren, zum Beispiel:
RUN apt-get -o Acquire::Retries=0 update \
&& apt-get -o Acquire::Retries=0 install -y --only-upgrade '?source-package(^apt$)'
Kennt APT im Basis-Image den Selektor nicht, bricht der Build mit einer Fehlermeldung ab; dann apt-get -o Acquire::Retries=0 upgrade -y verwenden.
In den Advisories stehen keine Indikatoren für eine Kompromittierung. Das Update schließt die Lücke, macht eine bereits erfolgte Ausnutzung aber nicht rückgängig. Unsere Einschätzung: Auf Servern, die in der Zeit vor dem Update Pakete über unsichere Netze geladen haben, lohnt ein Blick in /var/log/apt/history.log auf nicht geplante Installationen.
Härtung: Paketquellen auf HTTPS umstellen
Ubuntu empfiehlt TLS als mildernde Maßnahme vor dem Update und, nach dem Update, als Vorsichtsmaßnahme. Das Signaturschema bleibt laut Ubuntu der stärkere Schutz, weil es Ende-zu-Ende prüft und nicht nur den Transport (Ubuntu-Blog). TLS schützt die Strecke zum jeweiligen Server, also gegen einen Angreifer im Datenpfad; vor einem bösartigen Mirror schützt es nicht. APT folgt Weiterleitungen von http auf https, verweigert aber Weiterleitungen von https auf http (laut APT-Quellcode in Version 3.0.4; in 2.6.2 gilt dieselbe Regel). Eine HTTPS-Quelle lässt sich also nicht per Weiterleitung auf HTTP zurückstufen.
Für die offiziellen Debian-Archive lieferten deb.debian.org und security.debian.org am 9. November 2026 ihre Release-Dateien über HTTPS aus. Sicherung der Konfiguration, Umstellung und Test:
sudo cp -a /etc/apt /root/apt-backup-$(date +%F)
sudo find /etc/apt -maxdepth 2 -type f \( -name '*.list' -o -name '*.sources' \) \
-exec sed -Ei 's!http://(deb|security)\.debian\.org([/[:space:]]|$)!https://\1.debian.org\2!g' {} +
sudo apt update
Der Befehl ändert Einzeilen-Dateien (.list) und deb822-Dateien (.sources) gleichermaßen, aber nur die Hosts deb.debian.org und security.debian.org; andere Hostnamen (auch solche, die mit diesen Namen beginnen) und Adressen mit Portangabe bleiben unverändert. Auf Ubuntu verwendet Canonical diesen Befehl, der die offiziellen Ubuntu-Archive und deren Länderspiegel (de.archive.ubuntu.com) umstellt:
sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
Dieser Ausdruck prüft kein Hostende; ein Hostname, der mit einem der genannten Namen beginnt (zum Beispiel archive.ubuntu.com.example.net), würde ebenfalls umgestellt. Danach muss apt update ohne Fehler laufen. Manche Community-Mirror, auch länderspezifische, bieten laut Ubuntu kein HTTPS an. In dem Fall bleibt der Mirror auf HTTP, oder die Quelle wechselt auf einen offiziellen Mirror. Eigene Mirror und Caching-Proxys sollten für Clients HTTPS bereitstellen oder nur in einem vertrauenswürdigen Netzsegment erreichbar sein; das ist unsere Einschätzung.
Automatische Updates und Images prüfen
unattended-upgrades. Ubuntu gibt an, dass unattended-upgrades dort seit Ubuntu 16.04 standardmäßig aktiv ist und Sicherheitsupdates alle 24 Stunden einspielt; bei aktiviertem Dienst werden die Korrekturen für diese Lücke innerhalb von 24 Stunden nach Verfügbarkeit automatisch eingespielt (Ubuntu-Blog). Das beschreibt den Normalfall, keine Garantie: Gesperrte oder ausgeschlossene Pakete, nicht erlaubte Quellen, ein ausgeschaltetes System oder ein fehlgeschlagener Lauf verhindern die Installation. Auf Debian kann das Paket fehlen oder deaktiviert sein; es wird mit dpkg-reconfigure unattended-upgrades eingeschaltet (Debian Wiki). Der Zustand lässt sich prüfen:
dpkg-query -W unattended-upgrades
apt-config dump | grep -E 'APT::Periodic'
systemctl list-timers 'apt-daily*'
apt-mark showhold
APT::Periodic::Unattended-Upgrade "1" und APT::Periodic::Update-Package-Lists "1" sind die Voraussetzung für den täglichen Lauf, der Wert 0 schaltet die jeweilige Aktion ab (Ubuntu-Dokumentation). Dass die Automatik funktioniert, belegen die beiden Werte allein nicht: systemctl list-timers zeigt, wann die Timer zuletzt und das nächste Mal laufen, und die Protokolle in /var/log/unattended-upgrades/ zeigen die einzelnen Läufe. Außerdem müssen die Sicherheitsquellen in Unattended-Upgrade::Allowed-Origins oder Unattended-Upgrade::Origins-Pattern stehen (README von unattended-upgrades), und Pakete aus der Package-Blacklist werden nicht aktualisiert (laut Ubuntu-Dokumentation). apt-mark showhold listet Pakete, die auf Halten gesetzt sind; steht dort apt, wird es nicht automatisch aktualisiert. Ob unattended-upgrade das Update eingespielt hat, zeigt der awk-Befehl aus dem Abschnitt Prüfen. Wie sich Automatik, Neustarts und Nachweise zu einem Prozess verbinden, beschreibt der Ratgeber Linux-Patch-Management.
Container und Vorlagen. Ein Container-Image auf Debian- oder Ubuntu-Basis kann APT in einer älteren Version enthalten, nämlich in der, die beim Bau installiert wurde; Images ohne Paketmanager enthalten keines. Läuft apt-get install im Build über eine HTTP-Quelle, gilt für diesen Schritt dieselbe Voraussetzung wie auf einem Server. Zu prüfen sind die Basis-Images der Pipelines, selbst gebaute Golden Images und VM-Vorlagen (zum Beispiel für Proxmox), außerdem lange laufende Container, in denen später Pakete nachinstalliert werden.
Exploit-Status und Einordnung
| Quelle | Stand | Aussage |
|---|---|---|
| CISA ADP, SSVC | Bewertung vom 4. November 2026 | Exploitation: none, Automatable: no, Technical Impact: total |
| CISA KEV-Katalog | Katalogversion 6. November 2026 | nicht enthalten |
| Debian, Canonical, APT-Team | 4. November 2026 | keine Angaben zu Ausnutzung in den Veröffentlichungen |
| NVD | 9. November 2026 | Status „Received“, keine eigene Bewertung |
Unsere Einschätzung: Die Lücke ist gefährlich, weil der Erfolg die Signaturprüfung unterläuft und zu root führt, aber sie ist nicht trivial erreichbar, weil der Angreifer im Datenpfad stehen muss. Am höchsten ist die Priorität bei Servern, die Pakete über HTTP durch nicht vertrauenswürdige Netze oder über einen Mirror oder Proxy beziehen, den andere beeinflussen können. Bei reinen HTTPS-Quellen mit vertrauenswürdigem Mirror ist das Risiko geringer, das Update gehört trotzdem in das nächste Wartungsfenster. Der Fix-Commit samt Test ist öffentlich, das senkt für Angreifer die Hürde, die Lücke nachzubauen. Auf GitHub kursieren Prüf- und „Patch“-Skripte Dritter, die wir nicht geprüft haben; für Produktivsysteme sind die Updates der Distribution maßgeblich.
Verbreitete Irrtümer
- „Jeder im Internet kann jetzt meinen Server übernehmen.“ Nein. Der Angreifer braucht eine Position im HTTP-Datenpfad oder einen bösartigen Mirror oder Proxy, und es muss gerade ein Paket installiert werden.
- „Die GPG-Signaturen schützen mich ohnehin.“ Nicht bei dieser Lücke. Die Quellen beschreiben, dass ein Paket die Prüfung umgeht oder nach ihr ausgetauscht wird.
- „Mit HTTPS ist das Thema erledigt.“ HTTPS schützt gegen den Angriff im Datenpfad auf der Strecke zu einem vertrauenswürdigen Server. Gegen einen bösartigen Mirror ersetzt es das Update nicht.
- „APT 3.3.6 ist die Fixversion.“ Das ist der Entwicklungszweig. Debian-Stable und Ubuntu haben eigene Versionen (siehe Tabellen).
- „Debian 11 und Ubuntu 20.04 sind sicher, weil Retries dort 0 ist.“ Nur in der Standardkonfiguration. Wer
Acquire::Retriesauf einen Wert ungleich 0 gesetzt hat, kann betroffen sein. Die Korrekturen für beide Releases kommen über Freexian ELTS beziehungsweise Ubuntu Pro. - „Das ist die PHP2Shell-Lücke.“ Nein. PHP2Shell trägt CVE-2026-109618 und CVE-2026-109619 und betrifft PHP. CVE-2026-109518 betrifft APT.
Stand und Methodik
Stand 9. November 2026. Grundlage sind der CVE-Eintrag und der NVD-Datensatz, die Advisories DSA-6607-1, DLA-4880-1 und USN-8996-1, der Debian Security Tracker, der Freexian-ELTS-Tracker, der Ubuntu-Blog, die Ankündigung des APT-Teams und der Fix-Commit. Angaben zu den Paketindizes von security.debian.org (amd64 und arm64) und security.ubuntu.com (amd64), zur Abwesenheit eines APT-Pakets in den amd64-Indizes des Proxmox-Repositories pve-no-subscription, zur HTTPS-Erreichbarkeit der genannten Hosts und zum Zertifikat von download.proxmox.com stammen aus eigenen Abfragen am 9. November 2026. Die Befehle mit grep, sed und awk haben wir an Beispieldateien getestet; die übrigen sind Standardaufrufe von APT, dpkg und systemd. Eigene Einschätzungen sind im Text als solche gekennzeichnet. Spätere Änderungen der Herstellerangaben sind in diesem Stand nicht berücksichtigt.
Unser Vorgehen bei WZ-IT
Bei betreuten Linux-Servern gehen wir bei einem solchen Advisory in dieser Reihenfolge vor:
- Bestand erfassen: Distribution, APT-Version, Paketquellen (HTTP oder HTTPS),
Acquire::Retries, Proxy oder Mirror und Status der automatischen Updates, dazu Container-Basis-Images und Vorlagen. - Priorisieren: Hosts mit HTTP-Quellen über nicht vertrauenswürdige Netze und Hosts mit Mirror oder Proxy zuerst, danach der übrige Bestand.
- Vor dem Update absichern: HTTPS-Quellen, wo der Mirror sie anbietet, sonst
Acquire::Retries 0befristet. - Update und Nachweis: APT auf die Fixversion, Version je Host dokumentieren, temporäre Einstellungen zurückbauen.
- Dauerhaft absichern: Quellen auf HTTPS, soweit der Mirror es anbietet, Status von
unattended-upgradesim Monitoring und neue Advisories der Distribution im CVE-Monitoring.
Die Linux-Server-Betreuung umfasst Patching, Härtung, Monitoring mit Reaktion nach Service Level und Backup-Management, ab 149,90 € netto pro Monat für den ersten Server. Wer zunächst nur den Stand wissen will, nutzt das Server-Audit, das unter anderem den Patchstand prüft. Bei Managed Proxmox gehören Proxmox VE, Kernel und Pakete in abgestimmten Wartungsfenstern zum Patch-Management. Support, Beratung und Implementierung durch WZ-IT.
Weiterführende Guides
- Linux-Patch-Management: Prozess, Fristen und Nachweis, Automatik, Neustarts und Dokumentation.
- Linux End of Life: Supportende von Debian, Ubuntu und CentOS, Termine für Debian 11 und Ubuntu 20.04.
- Linux-Server härten: Checkliste mit CIS und BSI, weitere Maßnahmen auf dem Host.
- Linux-Kernel-Schwachstellen 2026: Patch-Management ist Chefsache, Einordnung für Entscheider.
- pedit COW und DirtyClone: Linux-Kernel-Lücken 2026, Patchen von Linux-Flotten bei Rechteausweitung.
- CVE-Monitoring für Self-Hosted Software, wie Schwachstellen strukturiert verfolgt werden.
- PHP2Shell: CVE-2026-109618 und CVE-2026-109619, die PHP-Lücken mit ähnlicher Nummer.
- UEFI-Lücke CVE-2026-97631 (EDK II, PXE), weitere aktuelle Lücke mit Bezug zu Server-Neustarts.
- Proxmox-Beratung und Betrieb, der Hub für Proxmox-Themen.
- Linux-Server-Betreuung und CVE-Monitoring, die Hubs zu Betrieb und Schwachstellenmanagement.
- SSHole (CVE-2026-123158): OpenSSH bei Alpine prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
- Kernel-TCP-Lücke CVE-2026-98432: Proxmox, Debian, Ubuntu patchen - weiterer aktueller Sicherheitsfall (Stand November 2026)
- CWPdoor: Hintertür im Control Web Panel prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
- Node-RED-Editor ohne adminAuth: CVE-2026-58115 (Siemens IoT2050) - weiterer aktueller Sicherheitsfall (Stand November 2026)
APT-Stand Ihrer Server prüfen lassen? Wir gleichen Version, Paketquellen und Update-Automatik mit den Fixversionen ab, spielen das Update ein und stellen die Quellen, soweit der Mirror HTTPS anbietet, auf HTTPS um. Termin vereinbaren
Quellen
- CVE-Eintrag CVE-2026-109518
- NVD, CVE-2026-109518
- CVE-Record-API, CVE-2026-109518 (inklusive CISA-ADP-Bewertung)
- FIRST, CVSS v4.0 Specification Document
- Debian Security Tracker, CVE-2026-109518
- Debian DSA-6607-1, apt
- Debian DLA-4880-1, apt
- Freexian ELTS Tracker, CVE-2026-109518
- Freexian, Extended LTS FAQ
- Debian, Informationen zu Debian 11 bullseye (LTS-Ende)
- APT-Team, APT-2026-11-01 security update
- APT-Fix-Commit 5af16a8a, methods: Open target files exclusively
- oss-security, CVE-2026-109518: RCE in apt(1) (DSA 6607-1)
- Ubuntu, CVE-2026-109518
- Ubuntu Security Notice USN-8996-1
- Ubuntu-Blog, CVE-2026-109518 APT vulnerability fixes available
- APT-Changelog (Eintrag 2.3.2, Acquire::Retries)
- APT-Quellcode 3.0.4, apt-pkg/acquire-item.cc
- APT-Quellcode 3.0.4, methods/basehttp.cc
- Debian-Handbuchseite apt.conf(5)
- Debian-Handbuchseite apt-transport-http(1)
- Proxmox VE, Package Repositories
- Proxmox VE, FAQ (Versionen und Supportende)
- Proxmox VE, Host System Administration (Systemupdates)
- Debian Wiki, UnattendedUpgrades
- Ubuntu Server, Automatic updates
- unattended-upgrades, README (Allowed-Origins, Origins-Pattern)
- CISA, Known Exploited Vulnerabilities Catalog
- Debian Security Tracker, CVE-2019-3462
- Max Justicz, Remote Code Execution in apt/apt-get (2019)













