Kurzfassung

LangBot vor Version 4.10.11 erzeugt Passwort-Wiederherstellungsschlüssel mit nur 24 Bit Entropie und schützt den nicht authentifizierten Reset-Endpunkt nicht durch Rate-Limits. Angreifer können bei bekannter Administrator-E-Mail den Schlüsselraum automatisiert durchprobieren und so das Admin-Konto übernehmen. NVD führt CVE-2026-90562 mit CVSS 9.2 nach CVSS 4.0.

Was ist passiert?

Bei LangBot steckt die Schwäche im Ablauf zur Passwort-Zurücksetzung. Das System erzeugt zu kurze Recovery-Keys und akzeptiert viele Anfragen am Reset-Endpunkt, ohne anonyme Zugriffe wirksam zu begrenzen.

Kennt ein Angreifer die E-Mail-Adresse des Administratorkontos, kann er massenhaft parallele Anfragen an den Passwort-Reset senden. Damit lässt sich der vergleichsweise kleine Schlüsselraum praktisch erschöpfen. Gelingt das, setzt der Angreifer das Kennwort des Administrators zurück und erhält vollen Kontozugriff.

Betroffen sind nach der bekannten Produktangabe alle Versionen vor 4.10.11.

Technische Details

Der Kern des Problems ist die Kombination aus zwei Schwächen: zu geringe Entropie bei Wiederherstellungsschlüsseln und fehlende Begrenzung von Anfragen an einem nicht authentifizierten Endpunkt. 24 Bit Entropie entsprechen nur rund 16,7 Millionen möglichen Werten. Das klingt zunächst nach viel, ist für einen öffentlich erreichbaren Web-Endpunkt ohne Rate-Limit aber unter ungünstigen Bedingungen angreifbar, vor allem mit parallelen Requests.

NVD bewertet die Lücke als HIGH mit CVSS 9.2 nach CVSS 4.0. Der Vektor lautet: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Die Einstufung passt dazu, dass kein Login und keine Nutzerinteraktion nötig sind, der Angriff aber Wissen über die Administrator-E-Mail und einen praktikablen Angriffsaufbau voraussetzt.

Die mögliche Auswirkung ist gravierend: Vertraulichkeit, Integrität und Verfügbarkeit des betroffenen Systems können nach einer erfolgreichen Kontoübernahme vollständig kompromittiert werden. Ob LangBot den Reset-Endpunkt standardmäßig ins Internet exponiert oder typischerweise intern betrieben wird, ist nicht mitgeteilt. Genau das entscheidet in der Praxis stark über das reale Risiko.

Wer ist betroffen?

Betroffen sind LangBot-Installationen in Versionen vor 4.10.11.

Für Unternehmen im DACH-Raum ist die Lücke dann besonders relevant, wenn LangBot administrativ über das Internet erreichbar ist oder wenn Dritte den Reset-Endpunkt aus weniger vertrauenswürdigen Netzen ansprechen können. Läuft die Anwendung ausschließlich intern, sinkt das unmittelbare Risiko deutlich, verschwindet aber nicht: Auch interne Angreifer, kompromittierte Clients oder falsch veröffentlichte Dienste kommen als Angriffsweg infrage.

Wer die Administrator-E-Mail leicht erraten kann, etwa durch Standardadressen oder öffentlich bekannte Kontaktpostfächer, erhöht die Angriffsfläche zusätzlich.

Empfohlene Maßnahmen

1. Sofort auf 4.10.11 oder neuer aktualisieren. Das ist die wichtigste Maßnahme, weil sie beide Ursachen adressieren sollte. Höhere Priorität gibt es hier nicht.

2. Reset-Endpunkt bis zum Update abschirmen. Beschränken Sie den Zugriff per Reverse Proxy, Web Application Firewall, VPN oder IP-Allowlist. Ist das kurzfristig nicht möglich, deaktivieren Sie die Passwort-Zurücksetzung vorübergehend, sofern der Betrieb das zulässt.

3. Rate-Limits vorgeschaltet erzwingen. Begrenzen Sie anonyme Anfragen an den Reset-Pfad auf Webserver-, Proxy- oder WAF-Ebene. Achten Sie dabei auf Sperren pro Quell-IP und zusätzlich auf globale Limits, damit verteilte Angriffe nicht ungebremst durchlaufen.

4. Administrator-E-Mail und Konten prüfen. Verwenden Sie keine leicht erratbaren Standardadressen, wenn das Produkt alternative Admin-Identitäten zulässt. Kontrollieren Sie außerdem, ob unerwartete Passwort-Resets, Login-Erfolge oder Änderungen am Administratorkonto protokolliert wurden.

5. Internet-Exposure erfassen. Prüfen Sie aktiv, ob LangBot-Instanzen oder zugehörige Reset-Endpunkte extern erreichbar sind. Gerade bei Test-, Staging- und Alt-Systemen tauchen solche Oberflächen oft unerkannt auf.

6. Zugangsdaten vorsorglich rotieren. Wenn Sie Anzeichen für Missbrauch sehen oder Logdaten fehlen, setzen Sie Admin-Kennwörter zurück und prüfen Sie abhängige API-Schlüssel, Tokens und Integrationen.

Ein Hersteller-Advisory mit Patch-Hinweisen oder offiziellen Abhilfemaßnahmen wurde nicht mitgeteilt.

Einschätzung von CyberSecurity-News.de

Die technische Schwäche ist klar und ungewöhnlich folgenschwer, weil sie direkt auf einen besonders sensiblen Prozess zielt: die Passwort-Wiederherstellung für Administratoren. Dass dafür keine Authentifizierung und keine Nutzerinteraktion nötig sind, macht CVE-2026-90562 operativ relevant.

Die Bewertung mit 9.2 ist nachvollziehbar, auch wenn der Angriff nicht trivial ist. Der Angreifer braucht die Administrator-E-Mail und muss den Schlüsselraum praktisch abarbeiten können. In Umgebungen mit vorgeschalteten Limits, Captcha-Mechanismen oder restriktiver Erreichbarkeit fällt das Risiko deutlich. In frei erreichbaren Installationen ohne zusätzliche Schutzschichten ist die Lücke dagegen ernst.

Die Informationslage bleibt allerdings begrenzt. Es gibt keine mitgeteilten Herstellerdetails dazu, wie genau 4.10.11 die Schwäche behebt, ob weitere Schutzmechanismen ergänzt wurden und ob bereits Angriffe beobachtet wurden. Für Administratoren heißt das: nicht auf Zusatzinformationen warten, sondern Exposition reduzieren und aktualisieren.

Fazit

Wenn Sie LangBot vor 4.10.11 einsetzen, sollten Sie das Update zügig einplanen und den Passwort-Reset-Endpunkt bis dahin abschirmen. Besonders dringlich ist das bei extern erreichbaren Instanzen.

Wer LangBot nur intern betreibt, hat mehr Spielraum, sollte die Schwachstelle aber trotzdem zeitnah beheben und Protokolle auf verdächtige Reset- und Login-Aktivitäten prüfen.

Quellenangabe

Weiterführende technische Informationen bietet der NVD-Eintrag zu CVE-2026-90562.