Typebot: Account-Übernahme durch anonymes Durchprobieren des Magic-Link-Login-Codes

Der E-Mail-Login von Typebot ersetzt den Standard-Token durch einen sechsstelligen Math.random()-Code, und der Verify-Endpunkt kennt keinerlei Rate-Limit oder Sperre, sodass ein anonymer Angreifer den Code jedes Kontos durchprobieren und sich als das Opfer anmelden kann.

Advisory-ID: TP-2026-050
Produkt: Typebot (Open-Source-Baukasten für Chatbots und Konversationsformulare, self-hosted)
Schwachstellentyp: Account-Übernahme durch unzureichend beschränkte Authentifizierungsversuche (CWE-307) mit schwachem Zufallswert (CWE-330)
CVE: CVE-2026-62862
CVSS 3.1: 9.1 (Kritisch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Hersteller-Advisory: GHSA-4g76-cwmg-gqgw
Betroffene Versionen: Typebot <= 3.17.1
Behoben in: Typebot 3.18.0
Gemeldet: 4. Juni 2026

Zusammenfassung

Typebot ist ein self-hosted Baukasten für Chatbots und Konversationsformulare, dessen Standard-Login ein per E-Mail zugestellter Magic Link ist. Der Nodemailer-Provider ersetzt den kryptografisch starken NextAuth-Standard-Token durch einen sechsstelligen Code aus Math.random(), also einen Wertebereich von nur 900.000 Möglichkeiten mit zehn Minuten Gültigkeit. Der Verify-Endpunkt, der den eingereichten Code prüft, kennt kein Rate-Limit, keine Sperre und keine Versuchsobergrenze, und ein falscher Versuch löscht den echten Token nicht, sodass er innerhalb des Zeitfensters beliebig oft geraten werden kann. Ein anonymer Angreifer, der nur die E-Mail-Adresse des Opfers kennt, stößt die Zustellung an und probiert den Code durch. Bei Erfolg erhält er eine gültige Sitzung und meldet sich als das Opfer an; für eine noch nicht existierende Adresse legt er das Konto vorab an.

Ursache

Der Nodemailer-Provider überschreibt die generateVerificationToken-Funktion von NextAuth mit einem sechsstelligen Math.random()-Wert (packages/auth/src/lib/providers.ts:43-44), der zugleich der rohe Token im Magic Link ist, und der Server hasht den eingereichten Code selbst mit sha256(code+secret), sodass der Angreifer rohe sechsstellige Werte ohne Kenntnis des Secrets einreicht. Der Verify-Callback GET /api/auth/callback/nodemailer besitzt kein Rate-Limit, keine Sperre, keine Versuchsobergrenze und keinen CSRF-Schutz, und ein Fehlversuch entfernt nichts, weil useVerificationToken bei einem P2025-Fehltreffer null zurückgibt (packages/prisma/.../createAuthPrismaAdapter.ts:184-202), sodass der echte Token das ganze Zehn-Minuten-Fenster überlebt. Der einzige Begrenzer oneMinRateLimiter (ein Aufruf pro 60 Sekunden, nextAuth.ts:97-99) sitzt auf dem Sende-Pfad, ist über getIp() an den vom Client gesetzten Header X-Forwarded-For gebunden (getIp.ts) und fehlt ohne REDIS_URL ganz. Weil sich koexistierende Codes nicht gegenseitig entwerten (jede Anmeldung fügt eine neue VerificationToken-Zeile ein), säen rotierende X-Forwarded-For-Werte N gültige Codes gleichzeitig und senken die erwartete Rateanzahl auf etwa 900000/N. Der Magic-Link-Login ist die Standard-Konfiguration der Open-Source-Variante, sobald NEXT_PUBLIC_SMTP_FROM gesetzt ist (providers.ts:25-47); reine OAuth- oder SSO-Installationen sind nicht betroffen.

Proof of Concept

# 1) Login-Code-Zustellung für das Opfer anstoßen (Codes entwerten sich nicht):
POST /api/auth/signin/nodemailer
X-Forwarded-For: <rotierender Wert>
[email protected]

# 2) Sechsstellige Codes ohne Sperre gegen den Verify-Callback durchprobieren:
GET /api/auth/callback/[email protected]&token=<000000..999999>

# Treffer: 302 + Set-Cookie authjs.session-token → Sitzung des Opfers

In der Live-Verifikation auf Version 3.17.1 blieben 600 sequentielle, 1000 parallele und 150 falsche Aufrufe von einer einzigen IP alle bei HTTP 302 ohne jede Drosselung, und der Token blieb erhalten; rotierende X-Forwarded-For-Werte säten fünf gleichzeitig gültige Codes, während dieselbe IP ohne Header nur einen erhielt. Ein frischer, cookie-loser Client mit dem korrekten Code erhielt anschließend Set-Cookie authjs.session-token, und GET /api/auth/session lieferte die E-Mail des Opfers, ohne CSRF-Token und ohne Zutun des Opfers.

Auswirkung

  • Anonyme Übernahme jedes bestehenden Kontos allein aus Kenntnis der E-Mail-Adresse des Opfers.
  • Vollständiger Lese- und Schreibzugriff auf die Konversationsflüsse, Ergebnisse und hinterlegten Integrationen des übernommenen Kontos.
  • Für eine noch nicht registrierte Adresse legt der Angreifer das Konto vorab an und kontrolliert es beim späteren Beitritt des echten Nutzers.
  • Kein Zutun des Opfers, kein CSRF-Token und keine vom Standard abweichende Konfiguration nötig, sobald der Magic-Link-Login aktiv ist.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen