Mastodon Mastodon Mastodon Mastodon

CVE-2026-53921 in odhcpd: Remote Code Execution auf OpenWrt-Routern

Foto des Autors

CyberSecureFox Editorial Team

Veröffentlicht:

Das OpenWrt-Projekt hat die Version 24.10.8 veröffentlicht, die die kritische Schwachstelle CVE-2026-53921 (CVSS 3.1: 9.8) behebt – ein Stack-Buffer-Overflow im Daemon odhcpd, der DHCPv6-Anfragen verarbeitet. Ein nicht authentifizierter Angreifer mit Netzwerkzugang zum UDP-Port 547 kann ein speziell präpariertes DHCPv6-REQUEST-Paket senden und damit den Stack-Puffer überschreiben, was auf typischer Embedded-Hardware mit hoher Wahrscheinlichkeit zur Ausführung beliebigen Codes mit root-Rechten führt. Öffentlicher Exploit-Code in Python ist bereits verfügbar. Nutzer des 24.10-Zweigs müssen auf 24.10.8, Nutzer des 25.12-Zweigs auf 25.12.5 aktualisieren.

Technische Anatomie von CVE-2026-53921

Laut dem offiziellen Advisory betrifft die Schwachstelle zwei unabhängige Overflow-Pfade in der Verarbeitung von DHCPv6-Anfragen. In beiden Fällen füllen speziell präparierte IA-Optionen einen festen 512-Byte-Stack-Puffer vollständig, woraufhin der Code Antwortdaten ohne Prüfung des verbleibenden Speicherplatzes anhängt.

Der erste Exploit-Pfad erfordert die vorherige Anlage von fünf IA_NA-Bindings über ein SOLICIT-Paket, der zweite wird durch ein einziges präpariertes REQUEST ausgelöst. Beide sind mit funktionsfähigen PoC-Skripten in Python dokumentiert.

Die Kritikalität wird dadurch verschärft, dass odhcpd mit root-Rechten läuft und Embedded-Hardware, auf der OpenWrt typischerweise betrieben wird, in der Regel keine Schutzmechanismen wie Stack-Canaries und ASLR besitzt. Dadurch wird der Übergang von einem Buffer-Overflow zur vollständigen Codeausführung zu einem realistischen Szenario statt zu einer rein theoretischen Möglichkeit.

Betroffen sind alle Versionen von odhcpd bis einschließlich Commit e432dd6, die die Funktionen dhcpv6_ia_handle_IAs() und build_ia() enthalten. Die Korrektur erfolgt durch eine Prüfung der verbleibenden Kapazität des Antwortpuffers vor dem Hinzufügen von Daten.

Bemerkenswertes Detail: Zwischen Advisory und Release Notes gibt es Abweichungen in der Klassifizierung. Das Advisory fasst beide Overflow-Pfade unter CVE-2026-53921 zusammen, während die Hinweise zum Release 24.10.8 das RECONF_ACCEPT-Overflow als separates Problem hoher Kritikalität ohne eigene CVE-Nummer hervorheben. Ebenso beschreiben die Release Notes den Angriffsvektor als „netzwerkbenachbart“ (Adjacent), während der CVSS-Vektor im Advisory AV:N (Network) verwendet. Keine der Quellen erläutert diese Diskrepanz.

Weitere Schwachstellen im Release 24.10.8

Zusätzlich zur Hauptschwachstelle behebt der Release eine ganze Reihe von Problemen in standardmäßig aktivierten Diensten:

  • odhcpd: Schreibzugriffe außerhalb des Puffers, Use-after-free, Memory-Leak, Denial-of-Service, Lesezugriffe außerhalb des Stacks, Spoofing über einen Neighbor-Discovery-Proxy
  • uhttpd: drei Schwachstellen für HTTP request smuggling
  • CVE-2026-62948: Hostname-Injection über DHCPv6, die zu stored XSS beim Aufruf der Lease-Seite in LuCI führt
  • CVE-2026-62947: Path Traversal in cgi-io, das das Lesen beliebiger, für root zugänglicher Dateien ermöglicht. Erfordert eine authentifizierte Session mit Upload-Berechtigung und einem entsprechenden File-Access-Template – es handelt sich nicht um anonymes Datei-Lesen

LuCI-Schwachstellen: Patches noch nicht übernommen

Parallel zum Release veröffentlichte Hacker House die Ergebnisse eines Audits von LuCI und uhttpd mit KI-unterstütztem Fuzzing. Identifiziert wurden Command Injection, Path Traversal und XSS in optionalen LuCI-Komponenten. Im Zuge der Vorbereitung der Fixes entdeckte OpenWrt zusätzlich eine weitere stored-XSS-Schwachstelle und das Fehlen eines CSRF-Schutzes.

Zentrale Findings laut Pull Request #8878:

  • luci-app-commands: Das Pipe-Symbol umging die Liste zulässiger Argumente und erlaubte so die Ausführung von Befehlen mit root-Rechten. OpenWrt stellte fest, dass dieser Pfad ohne Session-Cookie und ohne CSRF-Token funktioniert, wenn der Administrator einen Befehl sowohl als öffentlich als auch als parameterisiert konfiguriert hat
  • luci-app-ddns: Command Injection über die Einstellung ddns_dateformat und Path Traversal über service_name
  • luci-proto-openvpn: Command Injection über den Parameter keytype und Path Traversal über key-directory
  • luci-app-olsr: Ein bösartiger Knoten im Mesh-Netz kann einen Hostnamen mit Skript angeben, das im Browser des Administrators ausgeführt wird, wenn dieser die OLSR-Nachbarseite aufruft

Wichtig im Kontext: Diese Schwachstellen sind keine universell ausnutzbaren, nicht authentifizierten RCE-Pfade, die jeden OpenWrt-Router betreffen. Der nicht authentifizierte Pfad über luci-app-commands setzt die Installation der optionalen Anwendung und die bewusste Konfiguration eines öffentlichen, parameterisierten Befehls durch den Administrator voraus. Die übrigen Command-Execution-Pfade erfordern authentifizierten Zugriff auf LuCI. Stand 28. Juli waren beide Pull Requests (#8878 und ddns-scripts) noch offen und nicht in den Hauptzweig gemerged.

KI bei Erkennung und Behebung

Der Fall ist durch den umfangreichen Einsatz von KI auf beiden Seiten des Prozesses bemerkenswert. Hacker House beschreibt eine vierstufige „Inference-Fuzzing“-Methodik: Das Modell Qwen 3.6 35B Heretic generiert einen breiten Pool potenzieller Schwachstellen, anschließend filtert ein Modell mit höherer Genauigkeit (laut den Forschern Anthropic Claude Opus 4.6 für Open-Source-Projekte) False Positives heraus. Die abschließende Verifikation erfolgt manuell. Auf Seiten von OpenWrt tragen mehrere Commits im Pull Request das Label „Assisted-by: Claude:claude-opus-5“, und der automatisierte Review verweist auf den Einsatz von Claude Code.

Empfehlungen

  • Sofort die Firmware über den OpenWrt Firmware Selector auf OpenWrt 24.10.8 oder 25.12.5 aktualisieren
  • Separat installierte Pakete aktualisieren – sie werden nicht automatisch mit der Firmware aktualisiert
  • Die Konfiguration von luci-app-commands prüfen: sicherstellen, dass kein Befehl gleichzeitig als öffentlich (public=1) und parameterisiert (param=1) konfiguriert ist
  • Nicht benötigte optionale LuCI-Anwendungen entfernen, insbesondere luci-app-bmx7, luci-app-olsr, luci-app-commands
  • Delegierte LuCI-Berechtigungen überprüfen und den Zugriff auf cgi-io einschränken
  • Die Migration auf den 25.12-Zweig bis September 2026 planen – dem Ende des Security-Supports für den 24.10-Zweig

Stand 28. Juli waren weder CVE-2026-53921 noch die anderen beschriebenen Schwachstellen im CISA-KEV-Katalog verzeichnet, und die offiziellen Materialien von OpenWrt meldeten keine Ausnutzung in freier Wildbahn. Das Vorhandensein von öffentlichem PoC-Code für eine kritische Schwachstelle in einem Dienst, der mit root-Rechten auf Hardware ohne ASLR läuft, macht das Zeitfenster bis zum Beginn aktiver Ausnutzung jedoch minimal. Das Firmware-Update sollte in Stunden, nicht in Tagen erfolgen.


CyberSecureFox Editorial Team

Die CyberSecureFox-Redaktion berichtet über Cybersecurity-News, Schwachstellen, Malware-Kampagnen, Ransomware-Aktivitäten, AI Security, Cloud Security und Security Advisories von Herstellern. Die Beiträge werden auf Grundlage von official advisories, CVE/NVD-Daten, CISA-Meldungen, Herstellerveröffentlichungen und öffentlichen Forschungsberichten erstellt. Artikel werden vor der Veröffentlichung geprüft und bei neuen Informationen aktualisiert.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.