Kritische Linux-Sicherheitslücke: Viele Router betroffen, Patches kaum verfügbar

HWL News Bot

News
Newsbot
Thread Starter
Mitglied seit
06.03.2017
Beiträge
125.504
Die kritische Lücke CVE-2026-98432 im Linux-Kernel betrifft potenziell Millionen von Routern, denn fast alle Heimrouter laufen im Kern unter Linux. Einen Patch gegen diese kritische Sicherheitslücke gibt es bislang nur von wenigen Herstellern. Für die meisten Nutzer ist die Lage dennoch beherrschbar und abgemildert, solange der Router oder gehostete Dienste aus dem Internet nicht erreichbar ist/sind.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Für alle die einen Linux Router nutzen: ab Kernel 6.18.60 ist die Lücke geschlossen
 
Und für alle Großeltern wo das Enkelkind den Fernzugriff auf der Fritte aktiviert hat, oops.
 
@FM4E :
Als Ergänzung ggf. für den Artikel:
--> Patch für betroffene RouterOS v7-Versionen ist bereits vorhanden und RouterOS v6 war nie betroffen.
 
Update ist drin :)

News-Update:

"Bereits gestern hat MikroTik ein Advisory zu dieser Sicherheitslücke veröffentlicht. Betroffen sind alle Versionen von RouterOS 7 in der Stable-, Long-Term- und Development-Variante. Geschlossen wird die Sicherheitslücke mit Version 7.25.1 (Stable), 7.24.6 (Long-Term) und 7.26 Beta 5 (Development). RouterOS in Version 6 ist laut MikroTik nicht betroffen."
 
Was soll man wie immer machen als auf ein Update zu warten?

Asus scheint mir in letzter Zeit aber kein Fettnäpfchen auszulassen.
 
Asus baut Fettnäpfchen. :fresse: Bei Routern sollte man um die Marke wirklich einen großen Bogen machen. Ist aber bei TPLink und co. auch nicht anders, sofern man die Kisten eben nicht gleich auf OpenWRT o.Ä. umflasht.

 
Bei der Herstellerübersicht fehlt Lancom (Seit Sommer Rohde & Schwarz)
Aktuellestes Betriebssystem LCOS 11.00.0043 RC1 .
Version 10.94 ist für ein paar ältere Modelle.

Was ist mit der Kernelversion, so wie es @LuxSkywalker angesprochen hat?

Ich finde hier eine Übersicht mit Kernelversionen.
https://flaviocopes.com/linux-tcp-cve-2026-98432/#kernel-version



Edit 05.11.2026: auf der Homepage von Lancom steht nu der Vermerk, daß man von folgenden Sicherheitslücken nicht betroffen ist:

Sicherheitslücken in PHP – „PHP2Shell“ (CVE-2026-109618 und CVE-2026-109619)
Die Hard- und Softwareprodukte von R&S Networks and Cybersecurity sind von diesen Sicherheitslücken nicht betroffen.

Jedoch fehlt eine Angabe zur hier erwähnten neuen Sicherheitslücke, CVE-2026-98432.
 
Zuletzt bearbeitet:
Ist doch Blödsinn, im Prinzip sind alle Linux-Systeme betroffen. Wie verwundbar sie wirklich sind, ist bis jetzt ziemlich unklar geblieben.

Naja, die Schande ist ja nicht von einer Lücke im Linuxkernel betroffen zu sein. Die Schande ist, wie die Hersteller darauf reagieren. Und da stimme ich @Mr.Mito mit seiner Auflistung schon zu.

Es sind aktuell extrem unsichere Zeiten für alle und alles was am Internet hängt. Grade beim Router kann ich nur jedem Empfehlen auf Nummer sicher zu gehen.
 
Naja, die Schande ist ja nicht von einer Lücke im Linuxkernel betroffen zu sein. Die Schande ist, wie die Hersteller darauf reagieren. Und da stimme ich @Mr.Mito mit seiner Auflistung schon zu.

Es sind aktuell extrem unsichere Zeiten für alle und alles was am Internet hängt. Grade beim Router kann ich nur jedem Empfehlen auf Nummer sicher zu gehen.
Ich verstehe das schon, auf der anderen Seite warum sollte ein Hersteller einräumen angreifbar zu sein?
 
Ich verstehe das schon, auf der anderen Seite warum sollte ein Hersteller einräumen angreifbar zu sein?
Es zeugt nicht gerade von Vertrauen, wenn ein Hersteller offene Sicherheitslücken verschweigt.
 
Es zeugt nicht gerade von Vertrauen, wenn ein Hersteller offene Sicherheitslücken verschweigt.
Ich kann natürlich auch ein Schild aufhängen, Tür ist aktuell nicht verschleißbar.
Beitrag automatisch zusammengeführt:

Ist das vertrauenswürdiger?
 
Ja, ist es. Das Ding sit doch: Die bösen wissen es ohnehin. Den guten soltlest du es verraten. "Mach deine Fernwartung Fritzbox aus, weil".
 
Ja, ist es. Das Ding sit doch: Die bösen wissen es ohnehin. Den guten soltlest du es verraten. "Mach deine Fernwartung Fritzbox aus, weil".
Fritzbox hat je nach model verschiedene Kernels im Einsatz. Ältere Modell laufen unter umständen auf 4.19 oder 3.X.. heißt diese wären nicht betroffen.
 
Ich kann natürlich auch ein Schild aufhängen, Tür ist aktuell nicht verschleißbar.
Beitrag automatisch zusammengeführt:

Ist das vertrauenswürdiger?
Wenn diese Tür bei der Bekanntgabe des Defekts bereits repariert ist und wieder abschließbar ist, dann passt es und erzeugt Transparenz und Vertrauen.
 
Richtig ätzend ist für mich, das ich die letzten Jahrzehnte einen riesen Bogen um alles von AVM gemacht habe und freie Firmware auf anderer Hardware genutzt habe.
Jetzt mit dem Umzug weg von DSL und Glasfaser hin zu Docsis habe ich MEHRFACH darum gebeten keine Fritzbox sondern nur ein Modem zu erhalten.
"Klar der Mediaserver Plus kann als Modem genutzt werden", "cool dann nehm ich den, vielen Dank".

Und was ist der "Mediaserver Plus" als ich den zu Hause auspacke? Fritzbox 6660 Cable :shot:.
Wird Zeit das ich die Konfigurationsdatei manipuliere und mal schaue wie sich der "Modembetrieb" da umsetzen lässt. Habe ein maximal ungutes Gefühl mit der CVE, obwohl ich den "offiziellen" Weg mit exposed Host für meine Router dahinter nutze.
 
Zuletzt bearbeitet:
Ich kann natürlich auch ein Schild aufhängen, Tür ist aktuell nicht verschleißbar.
Folgendes Beispiel:
Du hast ne Wohnungstür vom Hersteller YXZ.
Du schließt regelmäßig ab und meinst, dass deine Wohnung geschützt ist.

Jetzt findet der Hersteller raus, dass die Türe nach 1000x abschließen sich zwar noch schließen lässt, aber nicht zuverlässig verriegelt.
(das ist der Fall, wenn das alles ne Eigenentwicklung ist)

Der Hersteller hat jetzt 2 Optionen:
1. er kommuniziert das, ne Art Rückrufaktion, und stellt einen Reparatursatz bereit
2. er hält einfach die Backen, weil zuviel Aufwand, das passt schon

Und jetzt wird es spannend.
Ein Einbrecher findet das früher oder später aus, dass er da gar nichts groß machen muss, ganz easy kommt er rein.
Das spricht sich irgendwann rum, erst bei den bösen Jungs und dann auch allgemein.
Du erfährst also als letztes davon und kannst erst dann reagieren.

Noch spannender ist es dann, wenn der Hersteller allgemein gültige Standardteile einsetzt (das ist in dem Fall hier der Kernel) und man weiß, dass diese Standardteile das Problem haben.

Jetzt hat der Hersteller 2 Optionen:
1. er kommuniziert, dass er diese Standardteile einsetzt, macht ne Art Rückrufaktion, und stellt einen Reparatursatz bereit
2. er verschweigt einfach, dass er diese Standardteile einsetzt, weil zuviel Aufwand, das passt schon

Und die Einbrecher finden raus, dass der Hersteller YXZ die selben Standardteile einsetzt wie Hersteller ABC.
-> Was also bei ABC klappt (was man schon rausgefunden hat), funktioniert automatisch auch bei YXZ.

usw. usf.

Und jetzt kommst du.
Was wäre die bei deiner Tür wichtiger?
1. dass du über das Problem Bescheid weißt, in dem du entsprechend Informiert wurdest (Wichtig: der Hersteller weiß ja nicht, wer alles seine Türen hat, er kann da also nur die Allgemeinheit informieren)
2. du findest raus, nachdem man dir die Bude ausgeräumt hat, dass deine Tür das Problem aufweist und der Hersteller sagt dir dann ins Gesicht, ja, das wussten wir, aber hier ist dein Reparaturkit


Dieses Vorgehen ist seit Jahrzehnten anerkannt.
Die Lücken werden du erst mit dem Hersteller diskutiert (sofern er das nicht selber rausfindet), dann kann er das fixen und dann wir allgemein informiert, dass es da ein Problem gibt und wie die jeweilige Lösung aussieht.
Die Angreifer wissen das früher oder später eh. Was der "Gute" rausfindet, findet der "Böse" auch raus. Die "Bösen" sind ja keine Friseure, die verstehen ihr Handwerk mindestens genauso gut wie die "Guten".
 
Bei TP-Link Omada ist die Lücke auch schon eine weile gestopft.
 
Das eigentliche Problem sind wie immer weniger der Kernel als die Hersteller, viele Router bekommen nach zwei, drei Jahren gar keine Updates mehr. Wer Fernzugriff oder Portfreigaben eingerichtet hat, sollte die bis zum Patch wenigstens abschalten.
 
Das alles nicht lustig, am Ende hockt noch jemand in der Wlan Glühbirne oder so und übernimmt dann den router von innen.
 
Was ist eigentlich mit all den NAS-Geräten? Bei denen ist der Zugriff von außen doch normal, und meines Wissens basieren alle NAS-Betriebssysteme auf Linux....
 
Zuletzt bearbeitet:
Wenn diese Tür bei der Bekanntgabe des Defekts bereits repariert ist und wieder abschließbar ist, dann passt es und erzeugt Transparenz und Vertrauen.
Der aktuelle Stand: Es handelt sich nicht um einen Zero-Day. Der Patch wurde bereits vor der CVE-Veröffentlichung bereitgestellt, Anthropic hat seinen Exploit-Code nicht veröffentlicht, und bis zum 30. Oktober wurden keine Ausnutzungen in freier Wildbahn gemeldet; außerdem ist der Fehler nicht im KEV-Katalog der CISA aufgeführt. Debian, Oracle UEK, die meisten unterstützten SUSE-Versionen und einige Amazon-Linux-Kernel sind bereits gepatcht. Red Hat und Ubuntu haben noch keinen gepatchten Kernel ausgeliefert und auch noch keinen Termin genannt. Der rebootless-Patch von KernelCare für Debian 13 ist bereits verfügbar, und Patches für EL 8, 9 und 10 werden derzeit erstellt, ohne auf Red Hat zu warten.
Bisher ist nicht bekannt ob jemals jemand diese Lücke genutzt hat und ganz so einfach ist es auch nicht. Treibende Kraft ist das MPTCP aktiv ist.

Siehe: https://tuxcare.com/de/blog/cve-2026-98432-linux-tcp-remote-root/

Ich finde für keinen Zero Day ein bisschen zu weit hoch gekocht.
Beitrag automatisch zusammengeführt:

Was ist eigentlich mit all den NAS-Geräten? Bei denen ist der Zugriff von außen doch normal, und meines Wissens basieren alle NAS-Betriebssysteme auf Linux....
Wichtig ist das eben MPTCP, wenn das nicht aktiv ist funktioniert der Angriff nicht. Nachtrag: (Zumindest die Spekulation dahinter)
Beitrag automatisch zusammengeführt:

Das alles nicht lustig, am Ende hockt noch jemand in der Wlan Glühbirne oder so und übernimmt dann den router von innen.
Es gibt noch keinen echten PoC. Es hat noch niemand den Exploit außerhalb KI Labor scheinbar wirklich verifiziert.
 
Zuletzt bearbeitet:
Was ist eigentlich mit all den NAS-Geräten? Bei denen ist der Zugriff von außen doch normal, und meines Wissens basieren alle NAS-Betriebssysteme auf Linux....
Nein.
Der Zugriff von außen ist bei NAS nicht normal.
Den Zugriff aus dem Internet müsstest du explizit in der Firewall deines Routers freischalten, damit ein NAS aus dem Internet erreichbar ist.
Ist es aus dem Internet nicht erreichbar, kann die Sicherheitslücke im Linux-Kernel nur aus dem eigenen Netzwerk ausgenutzt werden.
 
Genau das ist bei vielen NASsen aber der Fall! Jedenfalls wenn man es als persönliche Cloud oder als Server (für Daten oder Webites etc.) benutzt. Da geht der Zugriff logischerweise über eine Portfreigabe im Router und DynDNS. Ob man dafür MyFritz verwendet oder die DynDNS des NAS dürfte unerheblich sein.
 
Bei Synology und QNAP läuft der Fernzugriff für die meisten Leute aber über QuickConnect bzw. myQNAPcloud, da hängt das NAS nicht direkt mit offenem Port im Netz. Wer wirklich Ports durchreicht, sollte sowieso schauen, dass das NAS Updates bekommt, mit oder ohne diese Lücke.
 
Genau das ist bei vielen NASsen aber der Fall! Jedenfalls wenn man es als persönliche Cloud oder als Server (für Daten oder Webites etc.) benutzt. Da geht der Zugriff logischerweise über eine Portfreigabe im Router und DynDNS. Ob man dafür MyFritz verwendet oder die DynDNS des NAS dürfte unerheblich sein.
Wer sowas macht, hat schon lange die Kontrolle über alles verloren.

Man greif auf ein NAS über einen VPN-Tunnel zu.
Sprich also, das externe Endgerät wählt sich in das eigene Netzwerk ein und ist am Ende eigentlich ein interner Teilnehmer.

Ich greife weltweit auf mein NAS (und andere Systeme) zu und hab dahingehen gar kein Problem.
Sicherheitslücken können immer nur so ausgenutzt werden, als wäre ich eh direkt im eigenen Netzwerk, wo das System steht.

Und ja, das ist sicherlich so komfortabel, aber am Ende würde ich mir eh immer überlegen, wie viel ich über externe Systeme mache.
Das trifft auf die App->NAS Zugriffe zu, aber auch für Zugriffe, die über externe Knotenpunkte wie z.B. bei QNAP oder auch Syno zu.
Je weniger man mit externen Systemen zu tun hat, desto besser ist das, das gilt gleichermaßen für nach extern exposte Systeme, die bei einem Lokal stehen.
(bei mir ist nur VPN nach außen freigegeben, sonst nix)

Wer wirklich Ports durchreicht, sollte sowieso schauen, dass das NAS Updates bekommt, mit oder ohne diese Lücke.
Das ist nämlich genau der springende Punkt. Geräte, die internetfacing sind, sollten immer aktuell gehalten werden.
Das wird dann zum Problem, wenn der Hersteller seinen Support für das Gerät nach x Jahren eingestellt hat.
Wer also nen 10 Jahres altes NAS betreibt (für das in der Regel der Support abgelaufen ist) und das von außen erreichbar hat, sollte sich wirklich überlegen, was er da tut.
Gerade bei einem NAS, wo dann noch hin und wieder schützenswerte (persönliche) Daten abgelegt sind.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh