Aktuelle Sicherheitslücken: Update-Stand und was zu tun ist

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im SSL-VPN für Fernzugriff von Cisco Secure Firewall ASA und FTD. Ein Angreifer ohne Anmeldung kann mit einer präparierten Anfrage beim Aufbau der VPN-Verbindung das Gerät neu starten lassen. Während des Neustarts fällt das Gerät aus, mit ihm das VPN.

Laut Cisco liegt das an Logikfehlern, wenn in einer Tunnel-Gruppe eine zweite Anmeldestufe (secondary-authentication-server-group) eingerichtet ist. Seit dem 29. Oktober 2026 führt die CISA die Lücke als aktiv ausgenutzt.

Wer betroffen ist

Cisco Secure Firewall ASA und FTD, wenn SSL-VPN (webvpn) auf mindestens einer Schnittstelle eingeschaltet ist und eine Tunnel-Gruppe eine zweite Anmeldestufe hat, auch die Standardgruppe DefaultWEBVPNGroup. Das Firewall Management Center selbst ist laut Cisco nicht betroffen.

Korrigiert beim Hersteller

Cisco hat korrigierte Software veröffentlicht. Welche Version für Ihr Gerät die Korrektur enthält, zeigen die Meldung und der Cisco Software Checker.

Was zu tun ist

1. Firewall auf eine korrigierte Version aktualisieren. Einen Workaround nennt Cisco nicht.

2. Bis dahin nennt Cisco eine Gegenmaßnahme, die laut Cisco die Sicherheit des VPN senkt: Nutzt die Standardgruppe keine zweite Anmeldestufe, die Liste der Tunnel-Gruppen abschalten (no tunnel-group-list enable). Nutzt sie eine, die zweite Anmeldestufe entfernen (no secondary-authentication-server-group). Vorher prüfen, was das in Ihrer Umgebung bedeutet.

3. Auf FTD die bereitgestellte VPN-Richtlinie im Firewall Management Center prüfen.

So prüfen Sie es

1. Auf der ASA: Ist SSL-VPN eingeschaltet? Nur dann ist das Gerät betroffen, erkennbar an webvpn mit enable und einem Schnittstellennamen.

   show running-config webvpn

2. Ist in einer Tunnel-Gruppe eine zweite Anmeldestufe eingerichtet? Laut Cisco auch die Standardgruppe prüfen.

   show running-config tunnel-group | include secondary-authentication-server-group

3. Laufende Version.

   show version

Quellen

• Cisco: cisco-sa-asaftd-tunnel-dos-s6mgkb75
• Cisco Software Checker
• ENISA: EUVD-2026-112462
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 28. Oktober 2026 · CVSS 3.1 laut Cisco · EUVD-2026-112462 · KEV-Katalog geprüft, Stand 30. Oktober 2026

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im Netzwerkteil des Kernels beim Zusammenfügen empfangener Pakete. Dadurch kann der Kernel beim Entschlüsseln von IPsec-Daten in Speicher schreiben, der zu Dateien im Zwischenspeicher gehört. Laut heise ist Fragnesia eine Variante der Lücke Copy Fail, Microsoft hat im Mai 2026 davor gewarnt.

Nach CVSS 3.1 ein lokaler Angriff mit hohen Folgen: Wer schon ein Programm auf dem Server ausführen kann, etwa über eine Lücke in einer Website, kommt damit an mehr Rechte. Laut heise folgte in angegriffenen Systemen nach dem Einbruch über php2shell die Rechteausweitung mit Fragnesia.

Seit dem 28. Oktober 2026 führt die CISA die Lücke als aktiv ausgenutzt.

Wer betroffen ist

Ubuntu 22.04, 24.04 und 26.04 vor den Korrekturen unten, Debian 11 bis 13 ebenso. Ubuntu 20.04 und älter sowie 26.10 sind nicht betroffen.

Update-Stand je Version

Was zu tun ist

1. Debian und Ubuntu: Update einspielen und den Server neu starten. Ein Kernel-Update wirkt erst nach dem Neustart, bis dahin läuft der alte Kernel weiter.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Steht Ihre Version oben noch auf „In Arbeit“ oder „Verwundbar“, gibt es dort noch keine Korrektur. Spielen Sie die übrigen Updates ein und sehen Sie auf der Seite der Distribution nach.

So prüfen Sie es

1. Welcher Kernel läuft: Ubuntu zeigt etwa 6.8.0-147-generic, Debian 13 etwa 6.12.113+deb13-amd64. Debian 12 nennt hier nur die Reihe, die Paketversion steht in uname -v.

   uname -r
   uname -v

2. Fehlt der Neustart? Ist der neueste installierte Kernel nicht der, den uname -r meldet, läuft noch der alte.

   ls /boot/vmlinuz-*

3. Endet die Version auf -aws, -azure, -gcp, -oracle oder -raspi, gilt die Tabelle nicht: Diese Kernel haben eigene Nummern, 6.8.0-1030-aws ist nicht neuer als 6.8.0-124. Dann auf der Ubuntu-Seite zur Lücke beim passenden Paket nachsehen, etwa linux-aws.

Quellen

• Ubuntu: CVE-2026-46300
• Debian Security Tracker: CVE-2026-46300
• ENISA: EUVD-2026-31535
• CISA: Known Exploited Vulnerabilities Catalog
• heise online: Angriffe auf Linux- und VMware-ESX-Schwachstellen (29.10.2026)
• heise online: Fragnesia, Microsoft warnt vor weiterer Rechteausweitungslücke (15.05.2026)

Veröffentlicht am 23. Mai 2026 · CVSS 3.1 laut EUVD · EUVD-2026-31535 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 16,1 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

In VMware ESX kann ein Administrator bestimmte Vorgänge ausführen, ohne dass sie protokolliert werden. Broadcom stuft das mit CVSS 2,7 als niedrig ein.

Laut heise nutzten Angreifer die Lücke als Zero-Day, um nach dem Einbruch in vCenter-Umgebungen ihre Spuren zu verwischen. Seit dem 28. Oktober 2026 führt die CISA sie als aktiv ausgenutzt. Dieselbe Meldung von Broadcom schließt auch CVE-2026-59310 in vCenter, die laut CISA von Ransomware genutzt wird (unter „Erledigt“).

Wer betroffen ist

VMware ESX 8.0, 9.0 und 9.1 vor den Korrekturen unten, dazu VMware Cloud Foundation und vSphere Foundation.

Korrigiert beim Hersteller

ESXi 8.0 U3j (Build 25429389), 9.0.2.0100 (Build 25595025) und 9.1.0.0 (Build 25370933), Meldung vom 30. Juli 2026.

Was zu tun ist

1. ESX und vCenter auf die korrigierten Versionen bringen. Wer vCenter betreibt: Die Meldung schließt dort eine Lücke, über die Angreifer Code ausführen (CVE-2026-59310).

2. Wer seit Juli nicht aktualisiert hat, sollte die Umgebung auf Spuren eines Einbruchs prüfen lassen. Auf die Protokolle allein ist dabei kein Verlass, laut heise haben Angreifer die Lücke genau dafür genutzt.

So prüfen Sie es

1. Version und Build auf dem ESX-Host, über SSH oder die ESXi Shell.

   vmware -vl

Quellen

• Broadcom: Sicherheitsmeldung 38017 (VMware ESX und vCenter)
• ENISA: EUVD-2026-51107
• CISA: Known Exploited Vulnerabilities Catalog
• heise online: Angriffe auf Linux- und VMware-ESX-Schwachstellen (29.10.2026)

Veröffentlicht am 30. Juli 2026 · CVSS 3.1 laut Broadcom · EUVD-2026-51107 · KEV-Katalog geprüft, Stand 30. Oktober 2026

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Pufferüberlauf im Decoder der Kompressionsbibliothek Brotli von Google. Ein manipulierter Brotli-Datenstrom kann Speicher überschreiben oder auslesen und im schlimmsten Fall fremden Code ausführen, ohne Anmeldung.

Node.js bringt Brotli mit. Laut Node.js genügt es, dass eine Anwendung Brotli-Daten, die ein Angreifer liefert, mit node:zlib entpackt.

Wann das passiert: Express 5 entpackt laut Express eingehende Anfragen mit Content-Encoding: br von selbst, sobald express.json(), express.urlencoded(), express.text() oder express.raw() im Einsatz ist. Laut ELLIO gilt das auch für body-parser 2 und Koa mit @koa/bodyparser. In die andere Richtung trifft es fetch(), axios und got, wenn die abgerufene Gegenstelle mit Brotli antwortet. Ein nackter node:http-Server entpackt von sich aus nichts.

Seit dem 27. Oktober 2026 führt die CISA die Lücke als aktiv ausgenutzt. ELLIO hat am 26. Oktober Angriffsversuche mit öffentlichem Exploit-Code beobachtet, bestätigte Einbrüche meldet ELLIO keine (Stand 29. Oktober).

Wer betroffen ist

Brotli 1.0.3 bis 1.2.0 und Node.js 22, 24 und 26 vor den Sicherheitsreleases vom 21. Oktober 2026.

Anwendungen in Containern bringen ihr eigenes Node.js mit, etwa n8n und Docmost. Dort hilft nur ein neues Image des Herstellers, das Update des Servers erreicht sie nicht.

Ubuntu und Debian bauen ihr Node.js gegen die Brotli-Bibliothek des Systems. Bei Ubuntu genügt deshalb das Paket brotli. Debians Node.js-Pakete gelten laut Tracker trotzdem noch als verwundbar, weil dort zusätzlich eine Änderung in Node selbst nötig ist.

Node.js korrigiert nur die Reihen 22, 24 und 26. Reihen ohne Support wie 20, 23 und 25 sind laut Node.js bei jeder Sicherheitsfreigabe betroffen und bekommen keine Korrektur, dort hilft nur der Wechsel auf eine gepflegte Reihe.

Weitere betroffene Pakete laut Tracker: .NET bei Ubuntu (dotnet8 und dotnet10 korrigiert, dotnet6 für 22.04 zurückgestellt) und python-brotlicffi bei Debian 13 (verwundbar).

Update-Stand je Version

Korrigiert beim Hersteller

Brotli 1.0.10, 1.1.1 und 1.2.1 (Google). Node.js 22.23.4, 24.22.1 und 26.12.1 vom 21. Oktober 2026.

Was zu tun ist

1. Debian und Ubuntu: Update einspielen. Dienste, die die Bibliothek schon geladen haben, nutzen sie erst nach einem Neustart. Am einfachsten ist ein Neustart des Servers.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Anwendungen auf Node.js im Container, etwa n8n oder Docmost: Sobald der Hersteller ein Image mit korrigiertem Node.js liefert, eine fest eingetragene Version oder einen Digest im Compose darauf umstellen, denn pull holt nur, was dort steht. Dann neu holen und den Container neu erstellen. Eigene Images mit aktueller Basis neu bauen.

3. Bis zum Update empfiehlt ELLIO, eingehende Anfragen mit Content-Encoding: br am Proxy zu verwerfen, wo das geht. Das schützt nur eingehende Anfragen, was der Server selbst per fetch() abruft, bleibt offen.

   docker compose pull
   docker compose up -d

So prüfen Sie es

1. Node.js-Version in einem Container. Sicher sind 22.23.4, 24.22.1, 26.12.1 oder neuer in derselben Reihe.

   docker compose exec <dienst> node --version

2. Ein Image, das gerade nicht läuft, etwa vor dem Update.

   docker run --rm --entrypoint node <image> --version

3. Installierte Brotli-Pakete des Systems mit der Tabelle vergleichen.

   dpkg -l 'libbrotli*' | grep ^ii

Quellen

• ENISA: EUVD-2026-108169
• Node.js: October 2026 Security Releases
• Google Brotli: Releases
• Express: Migration auf Express 5, Brotli-Unterstützung
• ELLIO: Node2Shell, CVE-2026-111497
• Ubuntu: CVE-2026-111497
• Debian Security Tracker: CVE-2026-111497
• Debian: DSA-6582-1, Brotli für Debian 13
• Debian: DLA-4855-1, Brotli für Debian 12
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 22. Oktober 2026 · CVSS 4.0 laut Google · EUVD-2026-108169 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 82,6 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Zwei Fehler im Kern von PHP. Bricht PHP eine Anfrage wegen Speichermangels ab, prüfen manche Stellen danach nicht, in welchem Zustand sie zurückbleiben (CVE-2026-109618). Außerdem kann Zustand aus einer Anfrage in der nächsten Anfrage desselben Prozesses weiterleben (CVE-2026-109619). Laut PHP-Projekt führt beides zur Ausführung fremden Codes, ohne Anmeldung.

Laut PHP-Projekt betrifft es jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php, dort löst eine Anfrage ohne Anmeldung den Angriff aus, bevor überhaupt Code der Anwendung läuft. Ein Update von WordPress, Nextcloud oder der eigenen Anwendung schließt die Lücke deshalb nicht.

Schweregrad 9,2 nach CVSS 4.0 (PHP-Projekt). Seit dem 26. Oktober 2026 führt die US-Behörde CISA beide als aktiv ausgenutzt. Laut AWS gab es den ersten Angriffsversuch schon am 17. Oktober, vier Tage vor der Veröffentlichung, und kurz danach Angriffe mehrerer Gruppen auf Sensoren von AWS. Ob sie auf echten Systemen gelungen wären, lässt AWS offen. AWS empfiehlt, Protokolle ab dem 17. Oktober zu prüfen.

Laut heise folgte in angegriffenen Systemen nach dem Einbruch über php2shell die Rechteausweitung zu root über die Kernel-Lücke Fragnesia (CVE-2026-46300, weiter unten).

Wer betroffen ist

Jede Anwendung, die mit PHP läuft, etwa WordPress, Drupal und Nextcloud. Betroffen sind auch ältere Reihen als 8.2: Ubuntu korrigiert PHP 7.0, 7.2, 7.4 und 8.1. Das PHP-Projekt selbst liefert Korrekturen nur für 8.2 bis 8.5 (8.2.35, 8.3.36, 8.4.27, 8.5.12).

Debian und Ubuntu haben die Korrektur in ihre Pakete übernommen, auch für ältere PHP-Fassungen. Die Versionsnummer bleibt dabei gleich: Ubuntu 24.04 meldet nach dem Update weiter PHP 8.3.6. Maßgeblich ist die Paketversion in der Tabelle.

Läuft PHP in einem Container, kommt die Korrektur nur mit einem neuen Image.

Auch Geräte mit PHP im Inneren: Laut heise warnt Palo Alto Networks vor aktivem Missbrauch der php2shell-Lücken im Firewall-Betriebssystem PAN-OS, Hotfixes stehen bereit.

Update-Stand je Version

Korrigiert beim Hersteller

PHP-Projekt: 8.2.35, 8.3.36, 8.4.27 und 8.5.12 vom 22. Oktober 2026. Für PHP 8.1 und älter gibt es dort keine Korrektur mehr.

Was zu tun ist

1. Debian und Ubuntu: Update einspielen und danach PHP-FPM oder Apache neu starten, damit die laufenden Prozesse die neue Fassung laden. Die Versionsnummer im Befehl an Ihre PHP-Fassung anpassen.

   sudo apt update
   sudo apt full-upgrade
   sudo systemctl restart php8.3-fpm

2. PHP im Container: Ist im Compose eine feste Version oder ein Digest eingetragen, zuerst auf ein Image mit korrigiertem PHP umstellen, denn pull holt nur, was dort steht. Eigene Images mit aktueller Basis neu bauen. Dann neu holen und den Container neu erstellen. Ein bloßer Neustart des Containers startet wieder das alte Image.

   docker compose pull
   docker compose up -d

3. Laut PHP-Projekt hilft vollständig nur das Update. PHP 8.1 und älter ohne Paket der Distribution: auf eine Reihe mit Sicherheitsupdates wechseln.

4. Wer nicht sofort aktualisieren kann oder PHP 8.1 und älter ohne Korrektur betreibt, soll die Systeme laut CISA vom Netz nehmen, bis sie aktualisiert sind. Eine Web Application Firewall kann laut CISA bis dahin teilweise schützen. CISA weist auch darauf hin, dass PHP oft unbemerkt in anderer Software steckt.

So prüfen Sie es

1. Installierte Paketversion mit der Tabelle vergleichen.

   dpkg -l 'php*' | grep ^ii

2. Im Container zeigt php -v die PHP-Version, sie muss mindestens die oben genannte korrigierte Version sein.

   docker compose exec <dienst> php -v

Quellen

• PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• PHP 8 ChangeLog
• PHP: Security advisory vom 21.10.2026
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21.10.2026)
• AWS: PHP2Shell exploitation prior to public disclosure in MadPot
• Ubuntu: CVE-2026-109618
• Debian Security Tracker: CVE-2026-109618
• Debian: DSA-6574-1, PHP für Debian 13
• Debian: DLA-4848-1, PHP für Debian 12
• ENISA: EUVD-2026-107260
• CISA: Known Exploited Vulnerabilities Catalog
• heise online: Angriffe auf Linux- und VMware-ESX-Schwachstellen (29.10.2026)

Veröffentlicht am 21. Oktober 2026 · CVSS 4.0 laut PHP-Projekt · EUVD-2026-107260 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 99,9 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Eine Lücke in proxy.php der Nextcloud-App „Collabora Online – Built-in CODE Server“ (richdocumentscode). Sie bringt den Dokumenteneditor Collabora direkt in Nextcloud mit. Ein Angreifer kann ohne Anmeldung Befehle als Benutzer des Webservers ausführen.

Laut Collabora gelingt der Angriff nur, solange der eingebaute CODE-Server nicht läuft: nach einem Neustart des Containers, bei einem Update oder nach einem Absturz.

Seit dem 23. Oktober 2026 führt die CISA die Lücke als aktiv ausgenutzt.

Wer betroffen ist

Nur die App richdocumentscode vor 26.4.303. Ein eigener Collabora-Online-Server ist laut Collabora nicht betroffen.

Nextcloud 29 und älter bekommt die korrigierte App nicht mehr. Dort hilft nur ein Nextcloud-Update oder das Entfernen der App.

Korrigiert beim Hersteller

Collabora Online – Built-in CODE Server (richdocumentscode) 26.4.303.

Was zu tun ist

1. Die App auf 26.4.303 oder neuer aktualisieren, in Nextcloud unter Apps oder auf der Kommandozeile. Abschalten genügt laut Collabora nicht: Entweder aktualisieren oder entfernen.

   sudo -u www-data php occ app:update richdocumentscode

2. Nextcloud im Container: denselben Befehl im Container ausführen.

   docker compose exec -u www-data <dienst> php occ app:update richdocumentscode

3. Wer die App nicht braucht, entfernt sie.

   sudo -u www-data php occ app:remove richdocumentscode

So prüfen Sie es

1. Installierte Version der App. Steht dort 26.4.303 oder höher, ist die Korrektur da. Fehlt die Zeile, ist die App nicht installiert.

   sudo -u www-data php occ app:list | grep richdocumentscode

Quellen

• Collabora: GHSA-g3vx-3m76-fghh (CVE-2026-110447)
• ENISA: EUVD-2026-100780
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 14. Oktober 2026 · CVSS 4.0 laut Collabora · EUVD-2026-100780 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 73,3 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Pfadfehler in FortiOS: Ein angemeldeter Angreifer mit Administratorprofil und mindestens Lese- und Schreibrechten kann über bestimmte Befehle der Kommandozeile beliebige Dateien schreiben oder löschen.

Seit dem 16. Oktober 2026 führt die CISA die Lücke als aktiv ausgenutzt.

Wer betroffen ist

FortiOS 7.6.0 bis 7.6.4, 7.4.0 bis 7.4.9, 7.2.0 bis 7.2.13, 7.0.0 bis 7.0.19 und 6.4.0 bis 6.4.16. Laut Fortinet für 7.2, 7.0 und 6.4 alle Versionen. Dazu FortiProxy, FortiPAM und FortiSwitchManager.

Korrigiert beim Hersteller

FortiOS 7.6.5 und 7.4.10, die EUVD führt 7.6.4 und 7.4.9 als letzte betroffene Versionen. Für FortiOS 7.2, 7.0 und 6.4 gilt jede Version als betroffen, dort gibt es keine Korrektur und nur der Wechsel auf eine neuere Reihe hilft. Einzelheiten in FG-IR-26-122.

Was zu tun ist

1. FortiOS auf eine korrigierte Version der Reihe 7.4 oder 7.6 heben, nach der Meldung FG-IR-26-122.

2. Die Lücke setzt ein Administratorkonto voraus: Konten und Zugänge zur Verwaltung der Firewall prüfen.

So prüfen Sie es

1. Laufende Version auf der FortiGate.

   get system status

Quellen

• Fortinet: FG-IR-26-122
• ENISA: EUVD-2025-209452
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 14. April 2026 · CVSS 3.1 laut Fortinet, Basiswert · EUVD-2025-209452 · KEV-Katalog geprüft, Stand 30. Oktober 2026

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

CVE-2026-102489: In Zammad 6.3.0 bis 6.5.4 lässt sich eine Sitzung übernehmen, das führt zur Ausführung von Code als Benutzer zammad. In 7.0.0 bis 7.1.2 steckt der Fehler auch, ist dort aber nicht ausnutzbar. Zammad 6.5 und älter erhält keine Sicherheitsupdates mehr, dort gibt es keine Korrektur. Aktiv ausgenutzt laut EUVD seit 30. September, in der KEV seit 2. Oktober 2026.

CVE-2026-102490: In den DEB- und RPM-Paketen von Zammad kann ein Angreifer, der schon als Konto zammad Dateien schreiben darf, root werden. Container-Images und Installationen aus dem Quelltext sind nicht betroffen. Aktiv ausgenutzt laut EUVD und KEV.

CVE-2026-84458 (CVSS 9,1): Ist „Automatic account link on initial logon“ eingeschaltet, verknüpft Zammad eine Anmeldung über einen fremden Anbieter (SSO) allein über die E-Mail-Adresse mit einem bestehenden Konto, ohne zu prüfen, ob der Anbieter die Adresse bestätigt hat. Wer beim Anbieter eine Identität mit der Adresse eines Opfers anlegt, ist als dieses angemeldet, auch als Administrator. Laut Zammad gilt das in der Grundeinstellung für jeden Azure-AD-Mandanten über die Microsoft-365-Anbindung.

GHSA-79wh-8g2f-xj2c (CVSS 9,3): Ungefilterte Felder bei Selbstregistrierung und Ticket-Änderung geben Einblick in Tickets fremder Organisationen. GHSA-f3qr-94c2-7mx2 (CVSS 9,1): Die Zwei-Faktor-Anmeldung lässt sich über die E-Mail-Bestätigung umgehen. Beide kamen am 6. Oktober zusammen mit weiteren Meldungen.

Wer betroffen ist

Zammad 7.2.0 und älter (GHSA-Meldungen), DEB- und RPM-Pakete bis 7.2.1 (CVE-2026-102490), Zammad vor 7.1.2 mit automatischer Kontoverknüpfung (CVE-2026-84458), Zammad 6.3.0 bis 6.5.4 (CVE-2026-102489).

Zammad liefert eigene Pakete und Images. Debian und Ubuntu führen Zammad nicht.

Korrigiert beim Hersteller

Zammad 7.1.2 für CVE-2026-84458, 7.2.1 für die GHSA-Meldungen vom 6. Oktober 2026, 7.2.2 für CVE-2026-102490 (Meldung vom 8. Oktober 2026).

Was zu tun ist

1. Vor dem Update eine Sicherung der Datenbank anlegen.

2. Docker: Version 7.2.2 oder neuer setzen, etwa in der .env, dann neues Image holen und neu starten.

   docker compose pull
   docker compose up -d

3. Paketinstallation unter Debian oder Ubuntu: Zammad-Paket aktualisieren.

   sudo apt update
   sudo apt install zammad

4. Zammad 6.5 und älter erhält laut Zammad keine Sicherheitsupdates mehr: sofort auf 7.2.2 oder neuer wechseln. Zammad empfiehlt außerdem, den Zugang zum Server selbst auf vertrauenswürdige Administratoren zu beschränken.

So prüfen Sie es

1. Laufende Version: Docker zeigt das Image mit Versionsangabe, die Paketinstallation die Paketversion.

   docker compose images
   dpkg -l zammad

Quellen

• ENISA: EUVD-2026-90080
• ENISA: EUVD-2026-90081
• Zammad: GHSA-p97w-927q-8vxq (CVE-2026-102490)
• Zammad: GHSA-86cc-3ggh-mf2m (CVE-2026-84458)
• Zammad: GHSA-79wh-8g2f-xj2c
• Zammad: GHSA-f3qr-94c2-7mx2
• Zammad: alle Sicherheitsmeldungen
• Zammad: Advisory zu CVE-2026-102489 und CVE-2026-102490
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 30. September 2026 · CVSS 4.0 laut EUVD · EUVD-2026-90080 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 22,5 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Eine Befehlseinschleusung in der Windows-Shell. Laut Microsoft kann ein Angreifer ohne Anmeldung über das Netz eine Schutzfunktion umgehen. Microsoft führt auch Microsoft Edge und Outlook.com als betroffen, Outlook.com hat Microsoft selbst korrigiert.

Aktiv ausgenutzt laut EUVD seit 25. September, also vor dem Update. In der KEV seit dem 13. Oktober 2026, dem Tag des Oktober-Updates.

Wer betroffen ist

Windows 10, Windows 11 und Windows Server 2012 R2 bis 2025 ohne das Oktober-Update 2026, dazu Microsoft Edge vor 154.0.4258.62.

Update-Stand je Version

Korrigiert beim Hersteller

Microsoft, Sicherheitsupdates Oktober 2026 vom 13. Oktober. Microsoft Edge ab 154.0.4258.62. Die Builds oben stammen aus dem CVE-Eintrag von Microsoft in der EUVD.

Was zu tun ist

1. Windows Update ausführen und neu starten. Im Unternehmen über WSUS, Intune oder den eigenen Update-Weg das Oktober-Update verteilen.

2. Microsoft Edge aktualisiert sich selbst. Prüfen, ob er auf 154.0.4258.62 oder neuer steht.

So prüfen Sie es

1. Build der laufenden Windows-Version, in der Eingabeaufforderung oder PowerShell. Die letzte Zahl muss mindestens die aus der Tabelle sein.

   cmd /c ver

Quellen

• Microsoft: CVE-2026-96951
• Microsoft: October 2026 Security Updates (CVRF)
• ENISA: EUVD-2026-100274
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 13. Oktober 2026 · CVSS 3.1 laut Microsoft · EUVD-2026-100274 · KEV-Katalog geprüft, Stand 30. Oktober 2026

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im Bridge-Filter ebtables des Kernels. Schreibt die Regel SNAT die Absenderadresse in ARP-Paketen um, schreibt der Kernel in Speicher, der dafür nicht vorbereitet ist.

Nach CVSS 3.1 ein lokaler Angriff, dessen Folgen über die betroffene Komponente hinausreichen können. Seit dem 18. September 2026 führt die CISA die Lücke als aktiv ausgenutzt.

Wer betroffen ist

Noch keine Korrektur gibt es für Ubuntu 20.04 (auch die Cloud-Kernel dort), den HWE-Kernel 6.17 von 24.04 und die Raspberry-Pi-Kernel von 22.04 und 24.04. Für den HWE-Kernel 6.8 von 22.04 ist sie in Arbeit. Der normale Kernel der übrigen gepflegten Ubuntu-Versionen sowie Debian 12 und 13 sind korrigiert.

Update-Stand je Version

Was zu tun ist

1. Debian und Ubuntu: Update einspielen und den Server neu starten. Ein Kernel-Update wirkt erst nach dem Neustart, bis dahin läuft der alte Kernel weiter.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Steht Ihre Version oben noch auf „In Arbeit“ oder „Verwundbar“, gibt es dort noch keine Korrektur. Spielen Sie die übrigen Updates ein und sehen Sie auf der Seite der Distribution nach.

So prüfen Sie es

1. Welcher Kernel läuft: Ubuntu zeigt etwa 6.8.0-147-generic, Debian 13 etwa 6.12.113+deb13-amd64. Debian 12 nennt hier nur die Reihe, die Paketversion steht in uname -v.

   uname -r
   uname -v

2. Fehlt der Neustart? Ist der neueste installierte Kernel nicht der, den uname -r meldet, läuft noch der alte.

   ls /boot/vmlinuz-*

3. Endet die Version auf -aws, -azure, -gcp, -oracle oder -raspi, gilt die Tabelle nicht: Diese Kernel haben eigene Nummern, 6.8.0-1030-aws ist nicht neuer als 6.8.0-124. Dann auf der Ubuntu-Seite zur Lücke beim passenden Paket nachsehen, etwa linux-aws.

Quellen

• Ubuntu: CVE-2026-53266
• Debian Security Tracker: CVE-2026-53266
• ENISA: EUVD-2026-39217
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 25. Juni 2026 · CVSS 3.1 laut EUVD · EUVD-2026-39217 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 0,9 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im Kernel beim Zusammensetzen von IPv6-Paketen. Laut Fehlerbeschreibung kann ein Benutzer ohne besondere Rechte über einen UDPv6-Socket hinter das Ende eines Puffers schreiben.

Nach CVSS 3.1 ein lokaler Angriff mit hohen Folgen: Er setzt voraus, dass der Angreifer schon ein Programm auf dem Server ausführen kann. Seit dem 27. August 2026 führt die CISA die Lücke als aktiv ausgenutzt.

Wer betroffen ist

Ubuntu 24.04 und 26.04 vor den Korrekturen unten. Noch keine Korrektur gibt es für den HWE-Kernel 6.8 von Ubuntu 22.04, den HWE-Kernel 6.17 von 24.04 und den Raspberry-Pi-Kernel von 24.04. Der normale Kernel von 22.04 und Ubuntu 20.04 sind nicht betroffen. Debian 12 und 13 sind korrigiert.

Update-Stand je Version

Was zu tun ist

1. Debian und Ubuntu: Update einspielen und den Server neu starten. Ein Kernel-Update wirkt erst nach dem Neustart, bis dahin läuft der alte Kernel weiter.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Steht Ihre Version oben noch auf „In Arbeit“ oder „Verwundbar“, gibt es dort noch keine Korrektur. Spielen Sie die übrigen Updates ein und sehen Sie auf der Seite der Distribution nach.

So prüfen Sie es

1. Welcher Kernel läuft: Ubuntu zeigt etwa 6.8.0-147-generic, Debian 13 etwa 6.12.113+deb13-amd64. Debian 12 nennt hier nur die Reihe, die Paketversion steht in uname -v.

   uname -r
   uname -v

2. Fehlt der Neustart? Ist der neueste installierte Kernel nicht der, den uname -r meldet, läuft noch der alte.

   ls /boot/vmlinuz-*

3. Endet die Version auf -aws, -azure, -gcp, -oracle oder -raspi, gilt die Tabelle nicht: Diese Kernel haben eigene Nummern, 6.8.0-1030-aws ist nicht neuer als 6.8.0-124. Dann auf der Ubuntu-Seite zur Lücke beim passenden Paket nachsehen, etwa linux-aws.

Quellen

• Ubuntu: CVE-2026-53362
• Debian Security Tracker: CVE-2026-53362
• ENISA: EUVD-2026-41669
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 4. Juli 2026 · CVSS 3.1 laut EUVD · EUVD-2026-41669 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 0,7 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im Benachrichtigungssystem watch_queue des Kernels. Ein lokaler Benutzer kann damit Teile des Kernel-Speichers überschreiben und an mehr Rechte kommen oder das System zum Absturz bringen.

Die Lücke ist von 2022. Seit dem 26. August 2026 führt die CISA sie als aktiv ausgenutzt, sie wird also auf alten Servern gezielt genutzt.

Wer betroffen ist

Kernel vor 5.17. Ubuntu führt 20.04, 18.04 und 16.04 weiter als verwundbar. Ubuntu 22.04 ist korrigiert, neuere Versionen und Debian 12 und 13 enthalten die Korrektur von Anfang an.

Update-Stand je Version

Was zu tun ist

1. Debian und Ubuntu: Update einspielen und den Server neu starten. Ein Kernel-Update wirkt erst nach dem Neustart, bis dahin läuft der alte Kernel weiter.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Steht Ihre Version oben noch auf „In Arbeit“ oder „Verwundbar“, gibt es dort noch keine Korrektur. Spielen Sie die übrigen Updates ein und sehen Sie auf der Seite der Distribution nach.

3. Ubuntu 20.04 und älter erhalten nur noch mit Ubuntu Pro Sicherheitsupdates, und für diese Lücke nennt Ubuntu auch dort keine. Planen Sie den Wechsel auf eine gepflegte Version.

So prüfen Sie es

1. Welcher Kernel läuft: Ubuntu zeigt etwa 6.8.0-147-generic, Debian 13 etwa 6.12.113+deb13-amd64. Debian 12 nennt hier nur die Reihe, die Paketversion steht in uname -v.

   uname -r
   uname -v

2. Fehlt der Neustart? Ist der neueste installierte Kernel nicht der, den uname -r meldet, läuft noch der alte.

   ls /boot/vmlinuz-*

3. Endet die Version auf -aws, -azure, -gcp, -oracle oder -raspi, gilt die Tabelle nicht: Diese Kernel haben eigene Nummern, 6.8.0-1030-aws ist nicht neuer als 6.8.0-124. Dann auf der Ubuntu-Seite zur Lücke beim passenden Paket nachsehen, etwa linux-aws.

Quellen

• Ubuntu: CVE-2022-0995
• Debian Security Tracker: CVE-2022-0995
• ENISA: EUVD-2022-15988
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 25. März 2022 · CVSS 3.1 laut EUVD · EUVD-2022-15988 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 8,9 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im Linux-Kernel beim Aufbau von TCP-Verbindungen über IPv4. Bearbeiten zwei Prozessorkerne denselben Verbindungsaufbau gleichzeitig, kann der Kernel Speicher lesen, der schon freigegeben ist (Use-after-free). Ausgelöst wird das über das Netz, ohne Anmeldung.

Schweregrad 9,8 von 10 nach CVSS 3.1, so führen ihn Ubuntu und die europäische Schwachstellendatenbank EUVD. Nach CVSS 4.0 nennt Ubuntu 8,3.

Anthropic hat am 27. Oktober 2026 beschrieben, wie ein Angreifer über diese Lücke ohne Zugangsdaten Befehle als root ausführt. Der gezeigte Angriff richtet sich gegen Server mit einem MPTCP-Listener, also einem Dienst, der Verbindungen über Multipath TCP annimmt. Im Versuch dauerte er 48 Minuten bis zum ersten Schritt und fünf weitere bis zur Befehlsausführung. Ein misslungener Versuch bricht nur den Verbindungsaufbau ab, der Angreifer kann beliebig oft neu ansetzen.

Die Lücke selbst ist nicht auf MPTCP beschränkt. Die Fehlerbeschreibung nennt die allgemeinen Funktionen für IPv4-TCP, MPTCP kommt darin nicht vor. Einen Angriff ohne MPTCP-Listener beschreibt keine der verlinkten Quellen.

MPTCP-Listener entstehen auch ohne Absicht: Seit Go 1.24 nutzt net.ListenConfig auf Linux standardmäßig MPTCP. Ein in Go geschriebenes Programm kann also MPTCP-Verbindungen annehmen, ohne dass jemand es eingestellt hat.

Aktiv ausgenutzt wird die Lücke nach den verlinkten Quellen nicht: Sie steht nicht im KEV-Katalog der US-Behörde CISA, die EUVD führt keine Ausnutzung.

Wer betroffen ist

Der Fehler liegt im Kernel, nicht in einer Anwendung. Er sitzt im Code, der ankommende TCP-Verbindungen über IPv4 annimmt. Diesen Teil nutzt jeder Server mit Website, Mail oder Fernzugang.

Docker-Container nutzen den Kernel des Servers. Das Update gehört deshalb auf den Server selbst, ein neues Container-Image ändert nichts.

Ubuntu führt alle Versionen von 16.04 bis 26.10 als verwundbar, nur 14.04 als nicht betroffen. Für die HWE-Kernel 6.17 und 7.0 von 24.04 und für die Raspberry-Pi-Kernel nennt Ubuntu noch keine vorgesehene Version, die Cloud-Kernel (linux-aws, -azure, -gcp) haben eigene. Debian hat die Versionen 12 und 13 korrigiert.

Update-Stand je Version

Korrigiert beim Hersteller

Wer den Kernel selbst baut: Korrigiert ist die Lücke in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3, mit dem Commit e3f33b0 (Angaben des Kernel-Teams in der EUVD).

Was zu tun ist

1. Debian 12 und 13: Update einspielen und den Server neu starten.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Ubuntu: Die Korrektur ist noch nicht freigegeben, eine Übergangslösung nennt Ubuntu nicht. Spielen Sie bis dahin die übrigen Updates ein und sehen Sie auf der Ubuntu-Seite zur Lücke nach. Steht dort für Ihre Version „Released“, führen Sie dieselben drei Befehle aus.

3. Der Neustart gehört dazu. Ein Kernel-Update wirkt erst nach dem Neustart, bis dahin läuft der alte Kernel weiter und die Lücke bleibt offen.

4. MPTCP abzuschalten ersetzt das Update nicht. Der Fehler liegt im allgemeinen TCP-Code und bleibt.

So prüfen Sie es

1. Welcher Kernel läuft: Ubuntu zeigt etwa 6.8.0-147-generic, Debian 13 etwa 6.12.113+deb13-amd64. Debian 12 nennt hier nur die Reihe, die Paketversion steht in uname -v.

   uname -r
   uname -v

2. Fehlt der Neustart? Ist der neueste installierte Kernel nicht der, den uname -r meldet, läuft noch der alte.

   ls /boot/vmlinuz-*

3. Endet die Version auf -aws, -azure, -gcp, -oracle oder -raspi, gilt die Tabelle nicht: Diese Kernel haben eigene Nummern, 6.8.0-1030-aws ist nicht neuer als 6.8.0-124. Dann auf der Ubuntu-Seite zur Lücke beim passenden Paket nachsehen, etwa linux-aws.

4. Unter Ubuntu zeigt zusätzlich die Datei /var/run/reboot-required, dass ein Neustart aussteht.

   ls /var/run/reboot-required

5. Welche Dienste MPTCP-Verbindungen annehmen. Eine leere Liste heißt nicht, dass der Server sicher ist.

   ss -lnM

Quellen

• Ubuntu: CVE-2026-98432
• Debian Security Tracker: CVE-2026-98432
• Debian: DSA-6568-1, Kernel-Update für Debian 13
• Debian LTS: DLA-4841-1, Kernel-Update für Debian 12
• Debian LTS: DLA-4850-1, linux-6.12 für Debian 12
• ENISA: EUVD-2026-102025
• Linux: Korrektur e3f33b0 (7.3-rc7)
• Anthropic: Discovering vulnerabilities with Claude (27.10.2026)
• Go 1.24 Release Notes, Paket net
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: EPSS für CVE-2026-98432
• Linux man-pages: ss(8)

Veröffentlicht am 15. Oktober 2026 · CVSS 3.1 laut Ubuntu, EUVD · EUVD-2026-102025 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 0,4 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

CVE-2026-59797 (Apache: niedrig): Über SSLRequire in einer .htaccess lassen sich Dateifunktionen nutzen, die dort nicht vorgesehen sind. Betrifft Server, auf denen Dritte .htaccess-Dateien schreiben dürfen.

CVE-2026-57941 (Apache: mittel): Use-after-free in mod_http2, dem Modul für HTTP/2.

CVE-2026-56154 (Apache: niedrig): Use-after-free in mod_rewrite bei Regeln mit Vorausschau %{LA-U:HTTP:...}.

Die EUVD führt alle drei mit CVSS 9,8. Apache selbst stuft sie niedriger ein, weil sie bestimmte Module oder Einstellungen voraussetzen. Aktiv ausgenutzt wird keine nach den verlinkten Quellen.

Wer betroffen ist

Apache 2.4.0 bis 2.4.68, mod_http2 ab 2.4.17.

Ubuntu und Debian 13 haben korrigiert, Debian 12 und Ubuntu 26.10 noch nicht.

Update-Stand je Version

Korrigiert beim Hersteller

Apache HTTP Server 2.4.69 vom 1. Oktober 2026. Der Stand bei Debian und Ubuntu gilt für alle drei Kennungen gleich.

Was zu tun ist

1. Ubuntu und Debian 13: Update einspielen, Apache startet danach neu.

   sudo apt update
   sudo apt full-upgrade

2. Debian 12: Es gibt noch keine Korrektur. Prüfen Sie, ob die betroffenen Module geladen sind, und sehen Sie im Debian-Tracker nach.

So prüfen Sie es

1. Installierte Paketversion mit der Tabelle vergleichen.

   dpkg -l apache2 | grep ^ii

2. Geladene Module: Fehlen http2_module, rewrite_module und ssl_module, greifen die drei Lücken nicht.

   sudo apache2ctl -M | grep -E 'http2|rewrite|ssl'

Quellen

• Apache: Security Vulnerabilities fixed in 2.4.x
• Ubuntu: CVE-2026-59797
• Debian Security Tracker: CVE-2026-59797
• Debian: DSA-6569-1, Apache für Debian 13
• ENISA: EUVD-2026-90900

Veröffentlicht am 1. Oktober 2026 · CVSS 3.1 laut EUVD · EUVD-2026-90900 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 0,5 % (30. Oktober 2026)

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

Ein Fehler im IPv4-Teil des Netzwerk-Codes im Kernel des Hosts. Eine virtuelle Maschine kann über ihre virtio-net-Netzwerkkarte Pakete mit präparierten Angaben zur Prüfsumme schicken. Der Host-Kernel verändert damit den IPv4-Kopf, nachdem er ihn schon geprüft hat.

Laut den Entdeckern von pwn.ai liegt der Fehler nicht im Hypervisor, sondern im Netzwerk-Code von Linux. Bestätigt haben sie, dass ein Gast pro Versuch 32 Byte Speicher des Hosts auslesen und den Host zum Absturz bringen kann. In ihrem eigenen Labor reichte das bis zur Ausführung eines Programms als root auf dem Host. Einen Exploit haben sie nicht veröffentlicht.

Nach CVSS 3.1 ein lokaler Angriff, dessen Folgen über die betroffene Komponente hinausreichen (9,3 laut EUVD). Ubuntu stuft die Priorität als mittel ein. Aktiv ausgenutzt wird die Lücke nach den verlinkten Quellen nicht.

Wer betroffen ist

Hosts, auf denen virtuelle Maschinen mit virtio-net laufen, etwa mit KVM und QEMU. Getestet haben die Entdecker Linux 6.12 und 7.x. Entscheidend ist der Kernel des Hosts, nicht der Kernel in der VM.

Wer VMs bei einem Hoster mietet, betreibt den Host nicht: Das Update dort ist Sache des Hosters.

Ubuntu führt alle Versionen von 16.04 bis 26.10 als verwundbar, die Korrekturen für 22.04 bis 26.10 sind in Arbeit, für die HWE-Kernel 6.17 und 7.0 von 24.04 nennt Ubuntu noch keine. Debian hat 12 und 13 korrigiert, mit denselben Paketen wie bei CVE-2026-98432.

Update-Stand je Version

Korrigiert beim Hersteller

Upstream mit dem Commit 6785011f8b16 „ipv4: validate checksum_start before completing checksum“, seit 14. Oktober 2026 im Hauptzweig (laut pwn.ai). Eine Übergangslösung nennen die Entdecker nicht.

Was zu tun ist

1. Auf dem Host, nicht in der VM: Update einspielen und den Host neu starten. Vorher die VMs herunterfahren oder auf einen anderen Host verschieben.

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

2. Ubuntu: Die Korrektur ist noch nicht freigegeben. Wer VMs von Dritten auf dem Host betreibt, sollte die Ubuntu-Seite zur Lücke beobachten und sofort aktualisieren, sobald dort „Released“ steht.

So prüfen Sie es

1. Welcher Kernel läuft: Ubuntu zeigt etwa 6.8.0-147-generic, Debian 13 etwa 6.12.113+deb13-amd64. Debian 12 nennt hier nur die Reihe, die Paketversion steht in uname -v.

   uname -r
   uname -v

2. Fehlt der Neustart? Ist der neueste installierte Kernel nicht der, den uname -r meldet, läuft noch der alte.

   ls /boot/vmlinuz-*

3. Endet die Version auf -aws, -azure, -gcp, -oracle oder -raspi, gilt die Tabelle nicht: Diese Kernel haben eigene Nummern, 6.8.0-1030-aws ist nicht neuer als 6.8.0-124. Dann auf der Ubuntu-Seite zur Lücke beim passenden Paket nachsehen, etwa linux-aws.

4. Laufen auf dem Host virtuelle Maschinen über libvirt? Dann ist er betroffen, solange der Kernel nicht korrigiert ist.

   sudo virsh list --all

Quellen

• pwn.ai: PwnEscape (CVE-2026-99999)
• Ubuntu: CVE-2026-99999
• Debian Security Tracker: CVE-2026-99999
• Debian: DSA-6568-1, Kernel-Update für Debian 13
• ENISA: EUVD-2026-102044
• CISA: Known Exploited Vulnerabilities Catalog

Veröffentlicht am 15. Oktober 2026 · CVSS 3.1 laut EUVD · EUVD-2026-102044 · KEV-Katalog geprüft, Stand 30. Oktober 2026

Direkt zu diesem Eintrag:Link kopierenLink für LinkedIn

Worum es geht

CVE-2026-15176: Pufferüberlauf, wenn ein location-Block alias zusammen mit rewrite und set oder return verwendet.

CVE-2026-93479: Pufferüberlauf beim Auswerten von Variablen, wenn eine map mit regulären Ausdrücken in root oder im Format des Zugriffsprotokolls vorkommt.

CVE-2026-97205: Use-after-free, wenn asynchrones Datei-I/O (aio) eingeschaltet ist und eine Seite mit Server Side Includes einen Befehl include virtual enthält.

nginx stuft alle drei als mittel ein, die EUVD führt sie mit CVSS 9,2. Aktiv ausgenutzt wird keine nach den verlinkten Quellen.

Wer betroffen ist

CVE-2026-15176: nginx 0.1.29 bis 1.31.6. CVE-2026-93479: 1.30.0 bis 1.30.5 und 1.31.2 bis 1.31.6. CVE-2026-97205: 0.8.11 bis 1.31.6 (laut nginx, die EUVD nennt nur die neuen Reihen).

Ubuntu und Debian 13 haben korrigiert, Debian 12 noch nicht. Für Ubuntu 20.04 und älter hat Ubuntu die Lücken noch nicht bewertet.

Update-Stand je Version

Korrigiert beim Hersteller

nginx 1.30.6 (stable) und 1.31.7 (mainline). Der Stand bei Debian und Ubuntu gilt für alle drei Kennungen gleich.

Was zu tun ist

1. Ubuntu und Debian 13: Update einspielen. Danach läuft der neue nginx.

   sudo apt update
   sudo apt full-upgrade

2. Debian 12 und nginx aus anderen Quellen: Prüfen Sie, ob Ihre Einstellungen die genannten Muster enthalten. nginx vom Hersteller (nginx.org) auf 1.30.6 oder 1.31.7 heben.

So prüfen Sie es

1. Installierte Version und Paketversion.

   nginx -v
   dpkg -l nginx | grep ^ii

2. Kommen die Bausteine der drei Lücken in Ihren Einstellungen vor?

   sudo nginx -T 2>/dev/null | grep -nE '\b(alias|aio|map)\b'

Quellen

• nginx: Security Advisories
• Ubuntu: CVE-2026-15176
• Debian Security Tracker: CVE-2026-15176
• Debian: DSA-6575-1, nginx für Debian 13
• ENISA: EUVD-2026-101112

Veröffentlicht am 14. Oktober 2026 · CVSS 4.0 laut EUVD · EUVD-2026-101112 · KEV-Katalog geprüft, Stand 30. Oktober 2026 · EPSS 0,8 % (30. Oktober 2026)