6. September 2026 · Security-Advisory · SonicWall · Perimeter · Schwachstellenmanagement

SonicWall SMA1000: kritische Lücken, aktiv ausgenutzt

Zwei Schwachstellen in SonicWall SMA1000, eine mit CVSS 10.0, werden aktiv ausgenutzt. Betroffene Versionen, die Hotfixes – und warum Patchen allein nicht genügt.

Am 1. September 2026 hat SonicWall Hotfixes für zwei Schwachstellen in den SMA1000-Appliances veröffentlicht. Einen Tag später warnte CERT-AT: Beide werden bereits aktiv ausgenutzt, das PSIRT des Herstellers beobachtet die Ausnutzung selbst. Einen Workaround gibt es nicht – nur den Hotfix.

Die schwerere der beiden Lücken trägt einen CVSS-Wert von 10.0. Das ist der Maximalwert, und er wird selten vergeben.

Die beiden Schwachstellen

CVE-2026-83548 ist eine Server-Side Request Forgery im Work-Place-Interface, bewertet mit CVSS 10.0. Der Hersteller ordnet sie als unbeabsichtigte Proxy-Funktion ein (CWE-441); sie lässt sich ohne vorherige Anmeldung auslösen.

CVE-2026-83549 ist eine Command Injection mit CVSS 7.8. CERT-AT beschreibt sie als Schwachstelle, die authentifizierte Administratoren betrifft – isoliert betrachtet also die deutlich harmlosere der beiden.

Gefährlich ist die Kombination. Fachberichte beschreiben, dass sich beide verketten lassen: CVE-2026-83548 verschafft unauthentifizierten Zugriff auf Funktionalität, über die anschließend CVE-2026-83549 ausgenutzt und damit Betriebssystembefehle ohne vorherige Anmeldung ausgeführt werden können. Diese Verkettung stammt aus der Berichterstattung, nicht aus dem CERT-AT-Text – der die zweite Lücke für sich genommen als administratorgebunden führt. Für die Priorisierung macht das keinen Unterschied: Eine der beiden ist ohnehin unauthentifiziert und mit 10.0 bewertet.

Wer betroffen ist

Betroffen sind die Modelle 6210, 7210 und 8200v in diesen Ständen:

  • 12.4.3-03453 (platform-hotfix) und älter
  • 12.5.0-02835 (platform-hotfix) und älter

Fehlerbereinigt sind:

  • 12.4.3-03526 (platform-hotfix) und höher
  • 12.5.0-02952 (platform-hotfix) und höher

Ein Wort zur Einordnung, das wir uns nicht sparen wollen: SMA1000 ist die größere der beiden SonicWall-SMA-Linien und war lange die Enterprise-Variante. Das hat sich verschoben. Die kleinere SMA-100-Serie erreichte am 31. Oktober 2025 vorzeitig das Support-Ende; SonicWall kündigte an, die Geräte zu diesem Termin abzuschalten, und verwies Kunden auf die Cloud-Lösung Cloud Secure Edge. Damit ist die SMA 1000 die einzige verbliebene SMA-Appliance-Linie – wer den Appliance-Weg beibehalten wollte, landete bei ihr.

Wie viele deutsche Mittelständler diesen Weg tatsächlich gegangen sind, lässt sich nicht belegen – das ist ein plausibler Mechanismus, kein Nachweis, und die veröffentlichten Expositionszahlen stammen von verschiedenen Anbietern mit unterschiedlichen Zählkriterien und sind untereinander nicht vergleichbar. Prüfen Sie es also im eigenen Inventar, statt sich auf eine Größenklasse zu verlassen. Wenn Sie keine SMA1000 betreiben, ist der erste Teil dieses Beitrags für Sie erledigt. Der zweite nicht.

Was jetzt zu tun ist

  • Den Hotfix einspielen, ohne auf ein Wartungsfenster zu warten. Es gibt keinen Workaround, und die Ausnutzung läuft. Wie dringend, zeigt ein Blick über den Atlantik: Die US-Behörde CISA nahm beide Lücken am 2. September in ihren Katalog bekannt ausgenutzter Schwachstellen auf und setzte den Bundesbehörden eine Frist bis zum 5. September.
  • Den exakten Build feststellen, nicht den Versionszweig. „Wir sind auf 12.4.3“ beantwortet die Frage nicht – zwischen -03453 und -03526 liegt genau der Unterschied, auf den es ankommt.
  • Von einer möglichen Kompromittierung vor dem Patch ausgehen. Der Hotfix schließt die Lücke; er macht nicht rückgängig, was vorher passiert sein kann. Prüfen Sie Konfiguration, angelegte Konten und Protokolle auf Auffälligkeiten – SonicWall bietet dafür ausdrücklich die Unterstützung des eigenen Supports an.
  • Zugangsdaten und Sitzungen erneuern. SonicWall verlangt das im eigenen Advisory für den Fall gefundener Kompromittierungsspuren: alle Benutzer- und Administrator-Passwörter ändern, TOTP-Token zurücksetzen und die Appliance neu aufsetzen. CERT-AT greift das nicht auf. Wir empfehlen den Passwort- und Token-Wechsel darüber hinaus auch ohne Fund – wer über ein VPN-Gateway hereinkommt, kommt an Anmeldedaten; ein gepatchtes Gerät mit weiterhin gültigen Zugangsdaten ist nur halb saniert.
  • Die Exposition prüfen. Verwaltungsoberflächen gehören nicht ins Internet, auch nicht „vorübergehend“.
  • Die Meldelage klären. Wenn Sie unter NIS-2 fallen und sich ein Verdacht erhärtet, hängt an dem Fund eine Frist.

Wenn das Einspielen aus betrieblichen Gründen nicht sofort möglich ist, bleibt nur, die Erreichbarkeit einzuschränken: den Zugriff auf das Portal auf bekannte Quellnetze begrenzen, nicht benötigte Dienste der Appliance abschalten und die Anmeldeversuche engmaschig beobachten. Das ist kein Ersatz für den Hotfix und auch kein Workaround im Sinne des Herstellers – es verkleinert nur das Fenster. Planen Sie das Einspielen parallel dazu, nicht danach.

Warum Patchen allein nicht genügt

Diesen Satz muss man niemandem abkaufen – er stammt aus dem BSI-Lagebericht 2025: „Bei Schwachstellenausnutzungen reicht daher alleiniges Patchen üblicherweise nicht aus, um Geräte wieder sicher betreiben zu können.“ Im Lagebericht 2024 war das noch die Ausnahme – dort hieß es, in einzelnen Fällen reiche Patchen allein nicht aus. Ein Jahr später ist daraus der Regelfall geworden.

Der Grund liegt in der Bauart dieser Geräte. Das BSI hat ihn bereits im Lagebericht 2024 beschrieben: Methoden zur Protokollierung und Angriffserkennung seien auf Perimetersystemen „zum Teil beschränkt oder nicht üblich“, sodass Angriffe „nicht so gut erkennbar sind wie etwa auf Client-Systemen“. Angreifer installieren dort typischerweise Webshells, die passiv auf eine Verbindung von außen warten – möglich, „da Perimetersysteme per definitionem aus dem Internet erreichbar sind“.

Damit steht ein VPN-Gateway an der ungünstigsten Stelle des Netzes: maximal exponiert und minimal beobachtet. Auf einem Notebook läuft eine Endpoint-Erkennung, die verdächtiges Verhalten meldet. Auf einer geschlossenen Appliance läuft in aller Regel nichts dergleichen. Wer dort erst nach dem Patch nachsieht, hat oft keine Daten mehr, in denen er nachsehen könnte.

Praktisch folgt daraus dreierlei. Erstens: Perimetergeräte gehören ins Inventar mit Versionsstand und Verantwortlichem – nicht in die Kategorie „läuft seit Jahren“. Zweitens: Ihre Protokolle gehören von der Appliance weg auf ein zentrales System, solange sie noch existieren. Und drittens: Nach einem Vorfall an dieser Stelle ist die Frage nicht „ist gepatcht?“, sondern „was war zwischen Bekanntwerden und Patch möglich, und wie schließen wir das aus?“.

Der Trend zu Angriffen auf Perimetersysteme setzt sich nach Einschätzung des BSI fort. Diese Meldung ist also kein Einzelfall, sondern ein Muster – und die Vorbereitung darauf ist die eigentliche Arbeit.

Wie sector7 unterstützt

Für Umgebungen, die wir betreuen, halten wir Versions- und Lifecycle-Stände der Netzwerk- und Security-Komponenten nach und prüfen die von außen erreichbare Angriffsfläche in wiederkehrenden Scans – damit die Frage „sind wir betroffen?“ nicht erst am Tag des Advisories gestellt wird. Bei aktiv ausgenutzten Lücken übernehmen wir für betreute Umgebungen das kontrollierte Einspielen über die Standorte hinweg, schrittweise und mit definiertem Rückfallweg, und prüfen im selben Zug auf Spuren einer vorherigen Kompromittierung. Mehr dazu unter Cyber Security und Netzwerk & Connectivity.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0