CVE-2026-15409: CVSS 10.0 in SonicWall SMA1000 aktiv ausgenutzt

SonicWall hat am 14. Juli 2026 zwei Schwachstellen in seinen SonicWall SMA1000-Appliances offengelegt, die nach Herstellerangaben bereits aktiv ausgenutzt wurden. CVE-2026-15409 ist eine Server-Side Request Forgery (SSRF), die SonicWall mit dem Höchstwert CVSS 10.0 einstuft. CVE-2026-15410 ist eine Path Traversal, über die sich Befehle als root ausführen lassen – sie erreicht CVSS 7.2. Betroffen sind die Modelle 6210, 7210 und 8200v CMS in allen Hypervisor-Varianten, konkret die Firmware-Stände 12.4.3-03245, 12.4.3-03387, 12.4.3-03434 sowie 12.5.0-02283, 12.5.0-02624 und 12.5.0-02800. Fix-Versionen stehen mit 12.4.3-03453 und 12.5.0-02835 bereit, jeweils plus höhere Stände.

SonicWall SMA1000: Ein Schutzschild mit Zugang nach innen

Die SMA-1000-Serie ist eine Fernzugriffslösung für On-Prem-, Cloud- und Hybrid-Rechenzentren. Verwaltet wird sie über den Central Management Server (CMS); laut SonicWall-Produktseite skaliert die Reihe auf bis zu eine Million VPN-Nutzer. Damit sitzen diese Appliances genau an der Grenze zwischen Internet und internem Netz – sie sind die Pforte, nicht ein System im hinteren Teil der Infrastruktur. Wer sie kompromittiert, hat nicht bloß einen Randfall erwischt, sondern die Instanz, die den Zugang kontrolliert.

Dass ausgerechnet dieses Schutzschild zur Angriffsfläche wird, ist kein Einzelfall. Die Cybersicherheitsagentur Baden-Württemberg hat Management-Konsolen von SonicWall bereits früher als bevorzugtes Ziel beschrieben – damals ging es um die ältere Lücke CVE-2025-23006. Die aktuellen Schwachstellen sind ein separates Problem: SonicWall bezeichnet sie ausdrücklich als unabhängig von anderen gemeldeten Lücken seiner Produkte.

Die Angriffskette: /wsproxy, Erlang und Root-Ausführung

CVE-2026-15409 sitzt in einer Websocket-Proxy-Funktion unter dem Pfad /wsproxy der Anwendung „SonicWall WorkPlace" auf dem Standard-Port 443. Die Funktion erlaubt einen netcat-ähnlichen TCP-Tunnel zu beliebigen Hosts und Ports. Wird der host-Parameter auf localhost gesetzt, erreicht ein Angreifer lokale Dienste – etwa die Erlang-Anwendung auf localhost:1050 oder den ctrl-service auf localhost:8188. Rapid7 hat gegen den Erlang-Prozess einen Exploit entwickelt, der laut dem Analyse-Team ohne Authentifizierung Codeausführung ermöglicht, weil der Cookie-Wert hartkodiert ist.

CVE-2026-15410 bildet die zweite Stufe: eine Path Traversal im remove_hotfix-Workflow des ctrl-service. Über die Web-Konsole oder direkt über Port 8188 kann ein Angreifer mit Zugriff auf diesen internen Dienst beliebige Betriebssystem-Befehle als root ausführen. Als Beispiel nennt Rapid7 einen Request auf rollbackConfirm.action mit dem Parameter hotfix=../../../../../tmp/1234.sh. Das System setzt die Datei auf ausführbar, startet sie und rebootet anschließend typischerweise.

Wichtig für die Eingrenzung: Die Lücke betrifft nach Rapid7-Angaben nicht die SSL-VPN-Funktionalität von SonicWall-Firewalls und nicht die Produktlinie SMA 100 Series. Wer nur solche Systeme im Einsatz hat, ist von diesen beiden CVEs nicht betroffen – das schließt andere offene Punkte auf diesen Geräten aber nicht aus.

Patch-Stand, Zeitlinie und KEV-Eintrag

Die Fixes sind verfügbar: Version 12.4.3-03453 und höher sowie 12.5.0-02835 und höher, Bezug über mysonicwall.com. SonicWall schreibt in seiner Product Notice zu den SMA-1000-Schwachstellen, die Lücken seien als aktiv ausgenutzt bestätigt. Laut Rapid7 standen beide CVEs zum Zeitpunkt der Analyse im Known-Exploited-Vulnerabilities-Katalog von CISA – was die Frist für betroffene Betreiber faktisch verkürzt.

Bemerkenswert ist der zeitliche Ablauf. Das Rapid7-MDR-Team beobachtete die gezielte Ausnutzung bereits vor der offiziellen Offenlegung durch SonicWall – also als Zero-Day im wörtlichen Sinn. Das BSI hat seine Warnung mehrfach aktualisiert: zunächst am 16. Juli 2026 mit den Rapid7-Details und dem veröffentlichten Proof-of-Concept zu CVE-2026-15409, verbunden mit der Einschätzung, dass eine Ausnutzung durch weitere Akteure durch das öffentliche PoC wahrscheinlich ist. Am 22. Juli 2026 folgte ein zweites Update mit Erkenntnissen von Volexity vom 17. Juli: Die dort beschriebenen Angriffe wurden mindestens seit dem 22. Juni 2026 beobachtet, inklusive zusätzlicher IoCs, Analysen infizierter Appliances und einer Zuordnung. Wer die betroffenen Firmware-Stände trotz Patch-Verfügbarkeit noch fährt, muss von einer Exposition über mehrere Wochen ausgehen.

IoCs prüfen: Handlungscheckliste für Admins

Vor dem Patch ist die Kompromittierungsprüfung zu setzen – denn ein Patch entfernt keinen bereits platzierten Zugang. SonicWall nennt konkrete Indikatoren:

extraweb_access.log mit Requests auf /__api__/login oder /__api__/logout und HTTP-Status 200
extraweb_access.log mit Requests auf /wsproxy und verdächtigen host-Parametern (HTTP 101)
ctrl-service.log mit Einträgen zu „hotfix removal" samt Path-Traversal-Namen
/var/lib/unit/conf.json mit Routen für /__api__/login und /__api__/logout

Bei einem Fund empfiehlt der Hersteller: Hardware re-imagen, virtuelle Instanzen neu deployen, Administrator-Passwörter ändern und TOTP-Tokens zurücksetzen. Konfigurationsbackups sind nur dann brauchbar, wenn sie vor Installation der Dezember-Hotfix-Versionen (12.4.3-03245, 12.5.0-02283) entstanden sind. Diese Reihenfolge ist unbequem, aber sie ist der Unterschied zwischen „gepatcht" und „sauber".

Fazit: Fernzugriff bleibt das lohnendste Ziel

Die Kombination aus maximalem SSRF-Score und einer zweiten Stufe, die direkt Root-Rechte liefert, ist kein theoretisches Szenario – sie wurde beobachtet, bevor der Hersteller überhaupt öffentlich warnte. Das Muster wiederholt sich branchenweit: Fernzugriffs- und Management-Appliances stehen im Netz, haben tiefe Rechte in der internen Infrastruktur und werden seltener gepatcht als Endgeräte, weil jeder Reboot einen Wartungsfenster-Beschluss erfordert.

Für Admins heißt das: Firmware-Stand prüfen, auf 12.4.3-03453 beziehungsweise 12.5.0-02835 oder höher heben, Logs gegen die genannten IoCs durchsehen und den Management-Zugang der Appliances so weit einschränken, wie es der Betrieb erlaubt. Ein CVSS-Score von 10.0 allein sagt nichts über das eigene Risiko – die Frage ist, ob das Gerät erreichbar ist und wie lange es ungepatcht blieb.

Quellen