← Zur Übersicht aller Beiträge
BeyondTrust Remote Support: Kritische Zero-Day-Lücke wird aktiv ausgenutzt
CVE-2026-102764 betrifft alle BeyondTrust-Remote-Support-Versionen bis 26.2.3. SaaS-Instanzen wurden gepatcht; selbst betriebene Appliances benötigen den Patch BT26-05-RS oder zunächst ein Upgrade auf mindestens 24.3.1.
BeyondTrust Remote Support: Kritische Zero-Day-Lücke wird aktiv ausgenutzt
CVE-2026-102764 betrifft alle BeyondTrust-Remote-Support-Versionen bis 26.2.3. SaaS-Instanzen wurden gepatcht; selbst betriebene Appliances benötigen den Patch BT26-05-RS oder zunächst ein Upgrade auf mindestens 24.3.1.
BeyondTrust warnt vor einer kritischen Lücke in Remote Support, die bereits als Zero-Day ausgenutzt wurde. CVE-2026-102764 erreicht nach CVSS 4.0 einen Wert von 9,3. Betroffen sind nach Herstellerangaben alle Versionen bis einschließlich 26.2.3. Unter geeigneten Bedingungen kann ein entfernter Angreifer Dateioperationen auf der Appliance ausführen.
Die Meldung ist unmittelbar betriebsrelevant, weil Fernwartungssysteme privilegierten Zugriff bündeln. Google Threat Intelligence und Mandiant warnten laut Reuters vor einer möglichen breiten Ausnutzung. Eine erfolgreiche Attacke könne Zugangsdaten offenlegen, beliebige Dateien hochladen und die Kontrolle über den Host ermöglichen. Reuters ordnet beobachtete Aktivitäten einem mutmaßlich mit China verbundenen Akteur zu; diese Zuordnung ist eine Einschätzung der Sicherheitsforscher, keine technisch notwendige Voraussetzung für das Risiko.
SaaS und Eigenbetrieb erfordern unterschiedliche Nachweise
Der Patch ist für die Versionslinien 24.3.1 bis 26.2.3 vorgesehen. Wer eine ältere Version als 24.3.1 betreibt, muss laut Hersteller zuerst auf eine neuere unterstützte Version wechseln. Die einfache Feststellung „Version kleiner als 26.2.3“ reicht daher nicht für die Maßnahmenplanung; ältere Systeme benötigen einen Upgrade-Pfad, bevor der konkrete Patch angewendet werden kann.
Fernwartungszugänge priorisiert prüfen
Organisationen sollten zunächst klären, ob Remote Support als SaaS oder eigene Appliance betrieben wird. Für SaaS ist die Herstellerangabe zur Korrektur ein wichtiger Nachweis, sollte aber um die eigene Prüfung von Konten, Sitzungen und Integrationen ergänzt werden. Im Eigenbetrieb sind installierte Version, Patch-ID und Zeitpunkt der Aktualisierung zu dokumentieren.
Zusätzlich gehören administrative Konten, API-Zugänge, Servicekonten und angebundene Verzeichnisdienste in die Analyse. Weil die gemeldeten Folgen Zugangsdaten und Dateiuploads umfassen, ist bei verdächtigen Befunden eine reine Softwareaktualisierung nicht ausreichend. Dann müssen Schlüssel und Kennwörter nach einem abgestimmten Incident-Verfahren rotiert und betroffene Systeme forensisch bewertet werden.
Patchen beendet nicht automatisch die Untersuchung
Die Herstellerkorrektur schließt die bekannte Schwachstelle. Sie entfernt aber keine bereits angelegten Konten, hochgeladenen Dateien oder entwendeten Zugangsdaten. Betreiber sollten deshalb den Zeitraum vor dem Patch anhand verfügbarer Appliance-, Identitäts- und Netzwerkprotokolle prüfen. Eine unauffällige Schnellprüfung ist kein Beleg, dass nie ein Zugriff stattgefunden hat; sie kann jedoch die Entscheidung über weitere Maßnahmen priorisieren.
BeyondTrust erklärt, seine Remote-Support-SaaS-Kunden bereits am 9. Oktober gepatcht zu haben. Für selbst betriebene Installationen gilt das nicht automatisch. Dort muss der Patch BT26-05-RS manuell eingespielt werden, wenn automatische Aktualisierungen nicht aktiv sind.
BeyondTrust warnt vor einer kritischen Lücke in Remote Support, die bereits als Zero-Day ausgenutzt wurde. CVE-2026-102764 erreicht nach CVSS 4.0 einen Wert von 9,3. Betroffen sind nach Herstellerangaben alle Versionen bis einschließlich 26.2.3. Unter geeigneten Bedingungen kann ein entfernter Angreifer Dateioperationen auf der Appliance ausführen.
Die Meldung ist unmittelbar betriebsrelevant, weil Fernwartungssysteme privilegierten Zugriff bündeln. Google Threat Intelligence und Mandiant warnten laut Reuters vor einer möglichen breiten Ausnutzung. Eine erfolgreiche Attacke könne Zugangsdaten offenlegen, beliebige Dateien hochladen und die Kontrolle über den Host ermöglichen. Reuters ordnet beobachtete Aktivitäten einem mutmaßlich mit China verbundenen Akteur zu; diese Zuordnung ist eine Einschätzung der Sicherheitsforscher, keine technisch notwendige Voraussetzung für das Risiko.
SaaS und Eigenbetrieb erfordern unterschiedliche Nachweise
Der Patch ist für die Versionslinien 24.3.1 bis 26.2.3 vorgesehen. Wer eine ältere Version als 24.3.1 betreibt, muss laut Hersteller zuerst auf eine neuere unterstützte Version wechseln. Die einfache Feststellung „Version kleiner als 26.2.3“ reicht daher nicht für die Maßnahmenplanung; ältere Systeme benötigen einen Upgrade-Pfad, bevor der konkrete Patch angewendet werden kann.
Fernwartungszugänge priorisiert prüfen
Organisationen sollten zunächst klären, ob Remote Support als SaaS oder eigene Appliance betrieben wird. Für SaaS ist die Herstellerangabe zur Korrektur ein wichtiger Nachweis, sollte aber um die eigene Prüfung von Konten, Sitzungen und Integrationen ergänzt werden. Im Eigenbetrieb sind installierte Version, Patch-ID und Zeitpunkt der Aktualisierung zu dokumentieren.
Zusätzlich gehören administrative Konten, API-Zugänge, Servicekonten und angebundene Verzeichnisdienste in die Analyse. Weil die gemeldeten Folgen Zugangsdaten und Dateiuploads umfassen, ist bei verdächtigen Befunden eine reine Softwareaktualisierung nicht ausreichend. Dann müssen Schlüssel und Kennwörter nach einem abgestimmten Incident-Verfahren rotiert und betroffene Systeme forensisch bewertet werden.
Patchen beendet nicht automatisch die Untersuchung
Die Herstellerkorrektur schließt die bekannte Schwachstelle. Sie entfernt aber keine bereits angelegten Konten, hochgeladenen Dateien oder entwendeten Zugangsdaten. Betreiber sollten deshalb den Zeitraum vor dem Patch anhand verfügbarer Appliance-, Identitäts- und Netzwerkprotokolle prüfen. Eine unauffällige Schnellprüfung ist kein Beleg, dass nie ein Zugriff stattgefunden hat; sie kann jedoch die Entscheidung über weitere Maßnahmen priorisieren.
Quellen
Transparenz: Konzept, Auswahlkriterien und inhaltliche Vorgaben stammen von Christian Hohlfeld. Recherche und Formulierung wurden nach diesen Vorgaben mit KI-Werkzeugen unterstützt. Redaktionell geprüft und freigegeben von Christian Heinrich Hohlfeld am .