OpenWrt-Sicherheitsupdate: Was hinter der 24.07-Meldung wirklich steckt

Wer in den vergangenen Tagen über eine angebliche Veröffentlichung von OpenWrt 24.07 gestolpert ist, sollte kurz innehalten. Eine stabile Version mit dieser Nummer taucht in den offiziellen Release-Listen des Projekts schlicht nicht auf. Was es gibt, ist deutlich relevanter für alle, die ihre Router, Firewalls oder VPN-Gateways selbst betreiben: ein Sicherheits-Release für den älteren Stable-Zweig und eine aktuelle Hauptversion, die inzwischen produktiv im Feld läuft. Zeit, die Faktenlage sauber zu sortieren – und zu klären, was das für Homelab- und Self-Hosting-Setups mit Router-Linux tatsächlich bedeutet.

Eine Meldung, die so nicht stimmt

Kursierende Berichte zu „24.07“ dürften auf eine Verwechslung zurückgehen, vermutlich mit der tatsächlichen Versionsnummer 24.10. Ein Blick in die offizielle Release-Übersicht des Projekts zeigt: Der Sprung in der Nummerierung geht von der 24.10-Serie direkt zur aktuellen 25.12-Serie. Eine 24.07-Stable hat es nie gegeben. Das ist kein Weltuntergang, aber es zeigt, wie schnell sich fehlerhafte Versionsangaben in der Tech-Berichterstattung festsetzen – gerade bei einem Projekt, dessen Nutzerbasis aus Administratoren besteht, die genau wissen wollen, welchen Kernel sie auf ihrer Firewall laufen haben.

Für die Einordnung lohnt sich ein Blick auf die offizielle Release-Liste auf GitHub, die alle Stable-Zweige mit Changelogs und CVE-Fixes dokumentiert. Wer dort nach 24.07 sucht, findet nichts. Wer nach 24.10 und 25.12 sucht, findet dagegen ziemlich viel – und genau darüber lohnt sich zu reden.

Was tatsächlich Stand ist: 24.10.7 und die 25.12er-Serie

Die reale Faktenlage sieht so aus: Die 24.10-Serie befindet sich mittlerweile im sogenannten Security-Maintenance-Modus. Das Projekt schließt dort noch Sicherheitslücken, entwickelt aber keine neuen Funktionen mehr. Das jüngste Service-Release dieses Zweigs trägt die Nummer 24.10.7 und bringt vor allem Patches gegen zwei Kernel-Schwachstellen mit sich. Parallel dazu läuft die 25.12-Serie als aktuelle Hauptversion, mit laufender Feature-Pflege und vollem Security-Support.

Für Router-Linux-Nutzer heißt das konkret: Wer noch auf 24.10.x sitzt, sollte das Service-Release zeitnah einspielen, sich aber schon jetzt einen Migrationsplan zurechtlegen. Nach den aktuellen Ankündigungen des Projekts endet der Sicherheitssupport für die 24.10-Reihe im Laufe des Herbstes 2026. Wer danach weiterhin auf diesem Zweig bleibt, fährt ein System ohne Patches – und das auf einem Gerät, das an vorderster Front im Netzwerk sitzt.

Einen guten Überblick über die Versionsgeschichte bietet der Wikipedia-Eintrag zur Distribution, der die Stable-Zweige chronologisch auflistet. Persönlich finde ich es sinnvoll, dass das Projekt inzwischen so transparent kommuniziert, welcher Zweig noch aktiv gepflegt wird und welcher auslaufen wird. Das ist mehr Planungssicherheit, als man von vielen Hersteller-Firmwares bei OEM-Routern je bekommt.

Release-Zyklen und die Suche nach Langzeitstabilität

Im Vergleich zu klassischen Server-Distributionen, bei denen oft Planungshorizonte von fünf Jahren und mehr geboten werden, tickt die Welt der Router-Firmware deutlich schneller. Das liegt in der Natur der Sache: Hardware-Treiber für WLAN-Chipsätze, Switch-ASICs und kryptografische Bibliotheken entwickeln sich rasant. Ein statischer Langzeit-Support-Zweig, wie man ihn aus der Enterprise-Welt kennt, wäre bei OpenWrt ein Sicherheitsrisiko, da neue Netzwerkstandards kontinuierlich angepasst werden müssen. Das Projekt setzt stattdessen auf ein Modell aus aktuellen Stable-Releases und einem nachgelagerten Maintenance-Fenster. Wer OpenWrt produktiv einsetzt, muss diesen Rhythmus in seine Wartungsfenster integrieren. Ein Router ist eben kein Gerät, das man einmal aufsetzt und dann vergisst, sondern ein aktiver Teil der Infrastruktur, der regelmäßige Zuwendung verlangt. Wer aus Bequemlichkeit Jahre auf einem alten Branch verweilt, handelt sich zwangsläufig technische Schulden ein.

Kernel-Patches gegen zwei ernste Bugs

Der eigentliche Kern des Service-Releases 24.10.7 ist ein Kernel-Update auf Version 6.6.138. Damit schließt das Projekt eine Schwachstelle im IPsec-ESP-Codepfad, die in Fachkreisen unter dem Namen „Dirty Frag“ kursiert. Eine zweite Lücke, intern „Copy Fail“ genannt, wurde bereits mit einer vorherigen Kernel-Version behoben und ist in 24.10.7 ebenfalls enthalten. Beide Bugs betreffen zentrale Netzwerkpfade des Linux-Kernels und sind damit nicht irgendein Nischenproblem, sondern potenziell relevant für jedes System, das verschlüsselten Traffic verarbeitet.

Wer sich schon einmal mit dem Sicherheits-Update auf 24.10.7 beschäftigt hat, wird merken: Das ist kein Kosmetik-Patch. IPsec-Bugs im ESP-Pfad haben das Potenzial, aus der Ferne ausgenutzt zu werden. Einblicke in die tieferliegenden Mechanismen liefert etwa unsere Analyse zum Linux-Kernel-Update gegen den Dirty-Frag-Patch, das die Systematik hinter solchen Netzwerk-Schwachstellen aufschlüsselt. Für ein Router-Betriebssystem, das explizit als Basis für VPN-Gateways beworben wird, ist das der Grund, warum dieses Update Priorität hat.

Zusätzlich wurden Sicherheitskorrekturen in dnsmasq eingespielt, dem Dienst, der auf den meisten OpenWrt-Installationen DNS und DHCP bereitstellt. DNS-Bugs werden oft unterschätzt, dabei ist der Dienst zentral für praktisch jede Verbindung, die ein Gerät im Netzwerk aufbaut. Ein Fehler dort kann sich in Cache-Poisoning oder Denial-of-Service-Szenarien auswirken – deutlich mehr als nur ein kosmetisches Risiko.

Die Technik hinter Dirty Frag: Warum IPsec-Fragmentierung so heikel ist

Um die Dringlichkeit des Patches zu verstehen, hilft ein Blick auf die Funktionsweise von IPsec im ESP-Modus (Encapsulating Security Payload). Wenn Pakete die MTU einer Netzwerkstrecke überschreiten, müssen sie fragmentiert werden. Der Linux-Kernel kümmert sich um das Zerteilen und spätere Wiederzusammensetzen dieser Fragmente. Bei „Dirty Frag“ lag der Fehler genau in dieser Reassemblierungslogik. Ein Angreifer konnte gezielt manipulierte, überlappende Fragmente an den VPN-Endpunkt senden. Der Kernel reservierte Speicher für den Zusammenbau, der unter bestimmten Umständen nicht korrekt freigegeben wurde. Das Resultat: Ein klassischer Denial-of-Service (DoS), der das Gateway ohne Warnung in die Knie zwingt. In Zeiten, in denen automatisierte Scanner das gesamte öffentliche Adressraum kontinuierlich nach verwundbaren Endpunkten abtasten, ist ein ungepatchter IPsec-Stack im WAN-Bereich eine Einladung für Botnetze.

Neue Sicherheitsfunktionen: Firewall, Krypto und Standardkonfiguration

Über die reinen Kernel-Fixes hinaus hat sich in den vergangenen Release-Zyklen einiges an der Sicherheitsarchitektur der Distribution getan. Die Default-Firewall-Regeln wurden in den aktuellen Zweigen restriktiver gestaltet, sodass ein frisch geflashtes Gerät weniger offene Angriffsflächen bietet als noch vor einigen Jahren. Kryptobibliotheken wurden aktualisiert, was direkt auf VPN-Performance und Verschlüsselungsstärke wirkt, etwa bei WireGuard- oder OpenVPN-Verbindungen, die viele Nutzer für den Fernzugriff auf ihr Heimnetz einsetzen.

Wer selbst OpenVPN unter Linux betreibt oder ein OpenWrt-Wireguard-Setup als Basis für ein Homelab nutzt, profitiert von diesen Anpassungen unmittelbar. Gerade WireGuard hat sich in der Community als Standardweg etabliert, weil es sich in wenigen Zeilen Konfiguration einrichten lässt und deutlich schlanker arbeitet als klassisches OpenVPN. Trotzdem gilt: Ein sauber konfiguriertes VPN nützt wenig, wenn der darunterliegende Kernel eine offene Flanke im Verschlüsselungscode hat. Genau deshalb sind Kernel- und Krypto-Updates in Kombination der eigentliche Sicherheitsgewinn dieses Zyklus, nicht ein einzelnes Feature.

WireGuard, OpenVPN und der Praxis-Check

In der Praxis bedeutet das für Selfhoster: Nach einem Update auf die aktuelle Firmware lohnt sich ein kurzer Check der laufenden VPN-Tunnel. Ein Blick mit ip addr oder dem klassischen ifconfig-Äquivalent auf der Router-Shell zeigt, ob die WireGuard-Schnittstelle nach dem Reboot wieder korrekt hochgekommen ist. Wer mit mehreren Standorten arbeitet, etwa einem Homelab-Server per Site-to-Site-Tunnel, sollte die Handshake-Zeiten der WireGuard-Peers direkt nach dem Update prüfen – ein einfacher, aber oft übersehener Schritt.

DSA: Der heimliche Migrations-Haken bei Switch-Topologien

Wer von älteren OpenWrt-Versionen auf die aktuellen Zweige migriert, stolpert fast unweigerlich über ein Thema, das in reinen Security-Release-Notes oft zu kurz kommt: die Distributed Switch Architecture (DSA). Das Projekt hat die Art und Weise, wie Switch-Chips in Routern angesprochen werden, grundlegend umgestellt. Weg vom alten swconfig-Framework, hin zu DSA, das Switch-Ports als eigenständige, virtuelle Netzwerkinterfaces im Kernel behandelt. Für den Endanwender bedeutet das: Das klassische /etc/config/network-Layout ändert sich drastisch. VLANs werden nicht mehr als abstrakte Tags auf einem einzigen Switch-Port definiert, sondern als eigene Bridge-Interfaces. Wer bei einem Upgrade einfach seine alte Konfigurationsdatei blind wiederherstellt, riskiert, dass das Gerät nach dem Reboot nicht mehr über das LAN erreichbar ist. Ein Factory-Reset mit anschließender manueller Neuerfassung der Topologie ist bei einem Major-Release oft der sauberere Weg.

Was das für Homelab- und Self-Hosting-Setups bedeutet

Für alle, die einen Router mit freier Firmware als Fundament für eigene Netzwerk-Infrastruktur nutzen, ist die aktuelle Lage kein Grund zur Panik, aber ein klarer Handlungsauftrag. Wer auf dem älteren Zweig sitzt, sollte das Sicherheits-Release zeitnah einspielen und parallel prüfen, ob die eigene Hardware bereits von der aktuellen Hauptversion unterstützt wird. Gerade bei älteren Routern kann das ein Flaschenhals sein, weil nicht jedes Gerät auf Dauer mit neuen Kernel-Versionen und Treibern versorgt wird.

Meine persönliche Einschätzung: Genau hier zeigt sich der eigentliche Wert von freier Router-Firmware gegenüber Hersteller-Software. Bei den meisten OEM-Geräten bekommt man irgendwann gar keine Updates mehr, während ein offen entwickeltes System wie dieses die Lebenszeit der Hardware spürbar verlängert – vorausgesetzt, man aktualisiert konsequent. Wer das nicht tut, verschenkt genau den Vorteil, für den man sich die eigene Firmware überhaupt erst installiert hat.

Für Setups mit eigenem VPN-Gateway, Ad-Blocking per DNS-Filter oder segmentiertem WLAN für IoT-Geräte gilt: Diese Funktionen laufen meist über Zusatzpakete, die von der Basis-Firmware abhängen. Ein Kernel-Bug im Netzwerkstack betrifft dann nicht nur die Firewall selbst, sondern potenziell jedes Paket, das darüber läuft. Genau deshalb sollte die Update-Frequenz auf einem Router höher priorisiert werden als auf einem gewöhnlichen Desktop-Rechner – ein Router ist schließlich die erste Instanz, die jeder Datenpaket im Heimnetz durchläuft.

Hinzu kommt der Aspekt der Sichtbarkeit. Moderne Router-Firmwares bieten zunehmend bessere Integrationen für Monitoring-Stacks. Wer etwa Syslog-Forwarder auf dem Router installiert, um den Traffic-Fluss im Homelab zu visualisieren, profitiert von aktuelleren Kerneln, da diese effizientere Network-Namespaces unterstützen. Ein veralteter Kernel limitiert hier nicht nur die Sicherheit, sondern auch die Diagnosemöglichkeiten, wenn im Netzwerk einmal Latenzen im VLAN-Routing auftreten.

Migrationspfad: Vom auslaufenden Zweig zur aktuellen Stable

Wer jetzt vor der Entscheidung steht, ob ein Umstieg auf die aktuelle Hauptversion sinnvoll ist, sollte ein paar praktische Punkte abarbeiten. Zunächst: Konfiguration sichern, und zwar vollständig, nicht nur die Netzwerk-Einstellungen. Ein sysupgrade mit Backup-Option ist Standard, ersetzt aber keine externe Sicherung der Config-Dateien. Zweitens: Paketkompatibilität prüfen. Nicht jedes Zusatzpaket aus dem alten Repository ist eins zu eins auf dem neuen Zweig verfügbar, gerade bei Nischenpaketen für spezielle VPN- oder Monitoring-Zwecke.

Drittens: Hardware-Support gegenchecken. Die Release-Notes der jeweiligen Version listen unterstützte Zielplattformen auf, und gerade bei älteren MIPS-basierten Routern kann es sein, dass der Support irgendwann ausläuft, während x86-basierte Setups oder aktuelle ARM-Router weiterhin volle Unterstützung erhalten. Wer ohnehin über neue Hardware nachdenkt, sollte das in die Kaufentscheidung einpreisen, statt sich nach dem Kauf zu wundern.

Ein Hostname-Wechsel nach der Migration ist oft ein guter Zeitpunkt, um die Netzwerk-Dokumentation aufzuräumen – ein set system hostname in der Konfiguration kostet wenig Zeit, sorgt aber in gemischten Homelab-Umgebungen mit mehreren Geräten für deutlich weniger Verwechslungen beim Blick in Log-Dateien oder DHCP-Leases.

Hardware-Frage: Welche Router eignen sich überhaupt

Ein Punkt, der in der Debatte um Router-Linux gern untergeht: Nicht jede Hardware ist gleich gut geeignet. Geräte von Herstellern wie GL.iNet werden von Haus aus mit einer OpenWrt-nahen Firmware ausgeliefert und bekommen entsprechend zügig Updates, während klassische Consumer-Router von AVM, etwa aus der Fritzbox-Reihe, in aller Regel nicht offiziell unterstützt werden und stattdessen auf eigene, geschlossene Firmware setzen. Wer eine Fritzbox als reinen Internet-Zugangspunkt betreibt und dahinter einen dedizierten Router mit freier Firmware schaltet, fährt in vielen Fällen sicherer als bei einem reinen Ein-Geräte-Setup.

Bei der Kaufentscheidung für einen neuen Router mit Blick auf freie Firmware lohnt sich ein Check der Community-Kompatibilitätsliste vor dem Kauf, nicht danach. Genügend Flash-Speicher und RAM sind entscheidend, weil neuere Kernel-Versionen tendenziell mehr Ressourcen brauchen als ältere Releases. Ein Gerät, das für den alten Zweig noch komfortabel lief, kann bei der aktuellen Hauptversion knapp werden – ein Detail, das in Kaufempfehlungen für Router mit freier Firmware oft zu kurz kommt.

Ein oft übersehener Faktor ist zudem die thermische Stabilität unter Last. Neue Kernel-Features wie verbessertes Power-Management oder hardwarebeschleunigte Kryptografie entlasten die CPU spürbar. Das führt in kleinen, passiv gekühlten Gehäusen, wie sie im Homelab-Schrank oft anzutreffen sind, zu niedrigeren Temperaturen und damit zu einer längeren Lebensdauer der Flash-Bausteine.

Was bleibt?

Die eigentliche Geschichte hinter der fehlerhaften Versionsangabe ist unspektakulär, aber lehrreich: Router-Betriebssysteme sind längst kein Nischenthema für Bastler mehr, sondern Rückgrat vieler Homelab- und Self-Hosting-Setups, bei denen Netzwerksicherheit direkt von der Update-Disziplin der Betreiber abhängt. Ob 24.07, 24.10 oder 25.12 – am Ende zählt weniger die Versionsnummer als die Frage, ob das Sicherheits-Update tatsächlich eingespielt wurde. Wie oft prüfen Sie eigentlich, welche Firmware-Version auf Ihrem Router tatsächlich läuft? Genau diese fünf Minuten am Terminal entscheiden am Ende darüber, ob ein Kernel-Bug im IPsec-Pfad zum theoretischen Risiko bleibt oder zur echten Angriffsfläche wird.