SimpleHelp MFA-Bypass mit Höchstwert 10.0 aktiv ausgenutzt

7 Min. Lesezeit

Am 29. Juni setzte die US-Behörde CISA eine Frist auf den 2. Juli. Drei Tage für alle, die einen SimpleHelp-Server im Netz haben. Der Grund ist eine Lücke mit CVSS-Wert 10.0, dem Maximum. CVE-2026-48558 hebelt die Anmeldung komplett aus, Multi-Faktor inklusive, ohne dass der Angreifer ein einziges Passwort braucht.

Verwandt:Adaptive MFA als Zero-Trust-Hebel  /  Wann die Meldefrist-Uhr tickt

Was CVE-2026-48558 wirklich aushebelt

Der Fehler sitzt an einer Stelle, die in jedem Sicherheits-Grundkurs vorkommt. SimpleHelp akzeptiert bei aktiver OIDC-Anmeldung die Identity-Token, ohne ihre kryptografische Signatur zu prüfen. In der Schwachstellen-Systematik ist das CWE-347, improper verification of a cryptographic signature. Übersetzt heißt das: Der Server glaubt jedem Ausweis, den man ihm hinhält, ohne das Wasserzeichen zu kontrollieren.

Ein nicht authentifizierter Angreifer aus dem Internet baut sich also einen Token, der behauptet, zu einer berechtigten Technician-Gruppe zu gehören. SimpleHelp winkt ihn durch und legt bei Bedarf sogar ein neues Techniker-Konto an. Voraussetzung ist eine Konfiguration, die in der Praxis verbreitet ist: OIDC aktiv, eine an den Provider gekoppelte TechnicianGroup und die Option „Allow group authenticated logins“ eingeschaltet.

Und die zweite Verteidigungslinie, das MFA? Die greift hier nicht. Selbst wenn der Server MFA für Techniker erzwingt, darf ein Techniker beim ersten Login seinen zweiten Faktor selbst hinterlegen. Der Angreifer nutzt genau dieses Fenster und registriert seine eigene Authenticator-App. Das Schloss ist neu, den Schlüssel hat er selbst geschnitten.

Warum ausgerechnet RMM-Server das lohnende Ziel sind

SimpleHelp ist ein Remote-Monitoring-and-Management-Werkzeug. IT-Dienstleister und interne Admin-Teams steuern darüber aus der Ferne die Rechner ihrer Kunden oder Standorte. Wer diesen Server übernimmt, sitzt nicht in einem Netz. Er sitzt am Verteilerkasten zu vielen.

Genau das macht die Lücke für Managed-Service-Provider im DACH-Raum so unangenehm. Ein einzelner kompromittierter RMM-Server öffnet potenziell den Weg zu Cloud-Konsolen, DevOps-Pipelines und den Zugangsdaten dahinter. Der Angreifer braucht keinen Kunden einzeln zu knacken. Er nimmt den Dienstleister und erbt dessen Reichweite.

Wie groß die exponierte Fläche ist, hat Horizon3.ai untersucht. Von rund 14.000 im Internet erreichbaren SimpleHelp-Servern waren nach ihren Zahlen im Juni 2026 etwa 7,2 Prozent mit der verwundbaren OIDC-Variante konfiguriert. Das klingt nach einer kleinen Quote. Bei einem Werkzeug, das per Definition tief in fremden Netzen sitzt, ist jeder dieser Server einer zu viel.

Die Angreifer bringen zwei neue Schädlinge mit

Am 29. Juni schlug die Adversary Pursuit Group von Blackpoint Cyber Alarm. Sie beobachtete, wie ein bislang unbekannter Akteur die Lücke gegen einen öffentlich erreichbaren SimpleHelp-Server einsetzte, eine Technician-Session übernahm und darüber Schadsoftware ausrollte.

Zwei Familien tauchten dabei zum ersten Mal auf. TaskWeaver ist ein stark verschleierter Node.js-Loader, der als harmlose jquery.js getarnt daherkommt. Er lädt in der zweiten Stufe Djinn Stealer nach, einen Infostealer, der Windows, macOS und Linux abgreift. Ein Stealer auf einem RMM-Server ist der schlechteste anzunehmende Fall: Er erntet genau die Zugangsdaten, mit denen der Dienstleister überall sonst hineinkommt.

Sofort prüfen, ob Sie schon einen Gast haben

Ein Patch schließt die Tür. Er sagt Ihnen nicht, ob vorher schon jemand hereinspaziert ist. Deshalb gehört der Kompromittierungs-Check vor oder parallel zum Update. Horizon3.ai nennt konkrete Stellen.

In der Oberfläche: Unter Administration → Technicians das Zahnrad öffnen und „Show Group Authenticated Users“ aktivieren. Danach die Liste durchgehen. Jeder unbekannte Name oder jede fremde Mail-Adresse ist ein Alarmzeichen.

In den Logs: Die Server-Protokolle liegen unter Administration → Server Logs und im Dateisystem unter /opt/SimpleHelp/logs/server.log sowie in den datierten Unterordnern. Nach Einträgen suchen wie Registering technician login for [unbekannte-mail] und Configuration save requested in Verbindung mit unbekannten Technikern. Das ist die Signatur einer frisch angelegten Fremd-Session.

Was jetzt auf die To-do-Liste gehört

Die Reihenfolge zählt. Erst Exposure senken, dann sauber patchen, dann forensisch aufräumen.

• Patchen: Auf SimpleHelp 5.5.16 aktualisieren, im 6.0-Zweig auf RC2 oder die finale 6.0. Der Hersteller hat die Fehler bereits Ende Mai geschlossen.
• Sofortmaßnahme, wenn der Patch klemmt: OIDC vorübergehend deaktivieren und unter Administration → Login Security IP-Restriktionen für die Techniker-Anmeldung setzen.
• Exposure prüfen: Gehört der RMM-Server wirklich ans offene Internet? In den meisten Umgebungen reicht ein Zugang über VPN oder eine feste IP-Allowlist.
• Konten auditieren: Alle Technician-Accounts gegen die eigene Soll-Liste abgleichen, Fremdeinträge entfernen und deren MFA-Registrierungen zurücksetzen.
• Prozess härten: Jede Authentifizierungs-Integration daraufhin prüfen, ob sie Token-Signaturen wirklich validiert. Die Lücke hier ist ein Muster, kein Einzelfall.

Für Betreiber im Anwendungsbereich von NIS2 hat der Fall eine zweite Dimension. Ein erfolgreicher Zugriff auf einen RMM-Server, der Kundennetze steuert, ist ein meldepflichtiger Sicherheitsvorfall. Die 24-Stunden-Uhr läuft ab Kenntnis, nicht ab Feierabend. Wer den Kompromittierungs-Check ernst nimmt, weiß im Zweifel früher, ob er melden muss.

Häufige Fragen

Bin ich betroffen, wenn ich SimpleHelp ohne OIDC betreibe?

Der beschriebene Bypass hängt an der OIDC-Anmeldung mit gruppenbasiertem Login. Wer OIDC nicht nutzt, ist von diesem konkreten Pfad nicht betroffen. Trotzdem gilt die Update-Empfehlung, weil die gepatchten Versionen die Schwachstelle grundsätzlich schließen und die Angriffsfläche bekannt ist.

Reicht der Patch oder brauche ich zusätzlich eine Forensik?

Der Patch verhindert künftige Zugriffe. Er entfernt keinen Angreifer, der vorher schon drin war. Bei aktiv ausgenutzten Lücken gehört die Kompromittierungs-Prüfung immer dazu: fremde Technician-Konten, auffällige Log-Einträge und nachgeladene Dateien wie eine untergeschobene jquery.js.

Warum hilft mein erzwungenes MFA hier nicht?

Weil SimpleHelp Technikern erlaubt, ihren zweiten Faktor beim ersten Login selbst zu hinterlegen. Der Angreifer legt über den Auth-Bypass eine neue Technician-Identität an und registriert dafür sein eigenes MFA. Die Pflicht besteht formal, schützt aber nicht vor einem Konto, das der Angreifer selbst erzeugt hat.

Was haben TaskWeaver und Djinn Stealer mit der Lücke zu tun?

Sie sind die beobachtete Nutzlast. Nach der Übernahme der Technician-Session wurde TaskWeaver als getarnter Node.js-Loader ausgerollt, der Djinn Stealer nachlädt. Der Stealer greift Zugangsdaten auf Windows, macOS und Linux ab. Auf einem RMM-Server bedeutet das den Zugriff auf die Schlüssel zu vielen weiteren Systemen.

Die CISA-Frist war der 2. Juli. Betrifft mich das als deutsches Unternehmen?

Die Frist bindet formal US-Bundesbehörden über die Binding Operational Directive. Die Dringlichkeit gilt aber unabhängig von der Behörde: Eine aktiv ausgenutzte Lücke mit CVSS 10.0 auf einem RMM-Server ist überall ein Sofortfall. Für NIS2-pflichtige Betreiber kommt die Meldepflicht bei einem tatsächlichen Vorfall hinzu.

Mehr aus dem MBF Media Netzwerk

Quelle Titelbild: Unsplash / FlyD

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik