BeyondTrust Zero-Day: Warum ein Patch allein nicht reicht
BeyondTrust hat am 15. Oktober eine kritische Lücke in „Remote Support" gemeldet. Sie steckt in einer Fernwartungssoftware, die in vielen Unternehmen die Königstür zum gesamten Netz ist. Genau das macht den Fall unangenehm: Ausgenutzt wurde die Lücke laut Hersteller schon seit August, also über Wochen, bevor ein Patch existierte.

Was tatsächlich passiert ist
Am 15. Oktober 2026 veröffentlichte BeyondTrust ein Advisory zu einer kritischen Schwachstelle in seinem Produkt Remote Support (RS). Die unter CVE-2026-102764 geführte Sicherheitslücke beruht auf einer unzureichenden Validierung des Ursprungs von Nachrichten in einer internen Messaging-Komponente. Unter bestimmten Voraussetzungen können Angreifer dadurch Dateioperationen auf einer betroffenen Appliance durchführen. BeyondTrust bewertet sie mit einem CVSSv4-Score von 9,3 von 10 als kritisch.
Laut BeyondTrust und der Google Threat Intelligence Group wurde die Schwachstelle bereits seit August als Zero-Day ausgenutzt. Verschiedene Indikatoren deuten den Angaben zufolge auf einen mutmaßlich China-nahen Akteur hin, der als ARMORY CASTLE, UNC5221 beziehungsweise WARP PANDA geführt wird. Das BSI hat den Hinweis am 15. Oktober mit der Kritikalität „sehr hoch" eingestuft. Patches, die die Lücke schließen, wurden veröffentlicht.
Meine Einordnung
Fernwartungswerkzeuge sind das bequemste Einfallstor, das ein Unternehmen haben kann. Auf so einer Appliance endet nicht nur ein Support-Tunnel, dort laufen Zugangsdaten, Sitzungen und oft ein Backend, das in die Domäne hineinschaut. Wer dort hineinkommt, muss sich nicht mehr durch eine Firewall arbeiten, er ist schon drin. Und weil das Werkzeug die Arbeit von IT-Dienstleistern überhaupt erst möglich macht, hängen daran sehr oft gleich mehrere Firmen gleichzeitig.
Der naheliegenden Lesart „Patch einspielen, dann ist es erledigt" widerspreche ich hier deutlich. Eine Schwachstelle, die seit Monaten aktiv ausgenutzt wird, ist kein reines Patch-Thema. Wenn ein Angreifer wochenlang Dateioperationen auf der Appliance ausführen konnte, dann ist die richtige erste Frage nicht „ist der Patch drauf?", sondern „war jemand drin?". Patchen ist Aufräumen, Beweissicherung ist Ermittlungsarbeit, und beides muss man in der richtigen Reihenfolge tun. Wer sofort patcht und rebootet, löscht häufig genau die Logspuren, die man braucht.
In meinen Projekten sehe ich zwei wiederkehrende Muster. Erstens die Fernwartung, die direkt aus dem Internet erreichbar ist, mit einem gemeinsam genutzten Admin-Konto für mehrere Dienstleister und ohne zweite Faktor-Authentifizierung. Zweitens die fehlende Trennung: Die Support-Appliance steht logisch so, dass ein Tunnel gleich das ganze Netz sieht, vom Fileserver bis zum ERP. Beides ist kein BeyondTrust-Problem, das ist ein Architekturproblem. Ein externer Zugang, der beliebig lange und beliebig weit hineinreicht, bleibt ein Risiko, ganz unabhängig davon, welches Produkt dort betrieben wird.
Was mich an solchen Meldungen zusätzlich stört: Der Mittelstand erfährt davon meist durch den Dienstleister oder gar nicht. Die eigene Sicht auf „welche Fernwartungssoftware ist bei uns im Einsatz, in welcher Version und wer hat sie noch?" fehlt häufig komplett. Dabei genügt eine simple Liste. Wer sie nicht hat, kann auch nicht bewerten, ob ihn eine Meldung überhaupt betrifft.
Was Sie jetzt konkret tun können
1. Bestand klären. Verschaffen Sie sich Klarheit, welche Fernwartungsprodukte im Einsatz sind, ob Remote Support darunter ist und in welcher Version. Fragen Sie das schriftlich beim IT-Dienstleister ab.
2. Patchstatus prüfen und patchen. Gleichen Sie den Stand gegen das Advisory ab und spielen Sie die bereitgestellten Patches ein. Lassen Sie sich die Version nach dem Update bestätigen, nicht nur zusagen.
3. Kompromittierung prüfen, bevor geräumt wird. Sichern Sie Logs, vergleichen Sie mit den im Advisory genannten Indikatoren und suchen Sie nach ungewöhnlichen Dateioperationen im fraglichen Zeitraum seit August.
4. Zugang härter stellen. Nehmen Sie die Fernwartung aus dem offenen Internet, stellen Sie sie hinter VPN oder einen Zero-Trust-Zugang und erzwingen Sie individuelle Konten mit zweitem Faktor statt eines geteilten Admin-Logins.
5. Trennen. Sorgen Sie dafür, dass ein Fernwartungstunnel nur die Systeme erreicht, die er wirklich braucht. Und lassen Sie sich von jedem Dienstleister bestätigen, welche Ihrer Systeme er über welchen Zugang betreut.
Wenn Sie den Verdacht auf eine Kompromittierung haben oder Ihr Dienstleister die Fragen nicht belastbar beantwortet, ist das ein Fall für die professionelle Forensik. Hier selbst zu experimentieren, kostet am Ende mehr. Wenn Sie Ihren Fernwartungs- und Angriffsflächen-Bestand grundsätzlich aufräumen wollen, schauen Sie sich meine Leistungen unter /it-security/ an oder nehmen Sie direkt Kontakt auf.
Quellen
- BSI, „Version 1.0: BeyondTrust Remote Support – Zero-Day Schwachstelle seit mindestens August ausgenutzt", 15.10.2026 — https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297832-1032.html
Häufige Fragen
Was ist CVE-2026-102764 genau?
Eine Schwachstelle in der internen Messaging-Komponente von BeyondTrust Remote Support. Ursache ist eine unzureichende Prüfung der Nachrichtenherkunft, wodurch Angreifer Dateioperationen auf der betroffenen Appliance ausführen können. Das BSI stuft sie als „sehr hoch" ein.
Muss ich als Kunde eines IT-Dienstleisters auch etwas tun?
Ja. Die Appliance kann in Ihrem Netz stehen, während der Dienstleister sie betreibt. Die Verantwortung für Ihr Netz bleibt bei Ihnen. Lassen Sie sich schriftlich Auskunft über Produkt, Version, Patchstand und Zugangswege geben.
Reicht es, den Patch einzuspielen?
Nicht zwangsläufig. Weil die Lücke seit August ausgenutzt wurde, sollten Sie parallel prüfen, ob es im fraglichen Zeitraum Auffälligkeiten gab. Erst sichern, dann patchen — nicht umgekehrt.
Eigene Einordnung, keine Rechtsberatung. Quellen: BSI, „Version 1.0: BeyondTrust Remote Support – Zero-Day Schwachstelle seit mindestens August ausgenutzt", 15.10.2026 — https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297832-1032.html