FreeScout: Anonyme Account-Übernahme über `/user-setup` mit leerem `invite_hash`

Auf MySQL und MariaDB matcht ein einzelnes Leerzeichen (%20) den leeren invite_hash bereits aktivierter Konten, sodass ein nicht authentifizierter Angreifer E-Mail und Passwort des Kontos mit der niedrigsten ID (typischerweise Agent oder Administrator) setzt und sich anmeldet.

Advisory-ID: TP-2026-010
Produkt: FreeScout (weit verbreitetes Open-Source-Helpdesk- und Shared-Inbox-System)
Schwachstellentyp: Authentifizierungs-Bypass mit Folge Account-Übernahme (CWE-287, CWE-178, CWE-640)
CVE: CVE-2026-53595
CVSS 3.1: 9.4 (Kritisch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
Betroffene Versionen: < 1.8.224 (nur MySQL/MariaDB)
Behoben in: 1.8.224
Hersteller-Advisory: GHSA-jqj5-r72v-v29g
Gemeldet: 1. Juni 2026

Zusammenfassung

FreeScout ist ein weit verbreitetes Open-Source-Helpdesk- und Shared-Inbox-System. Der Endpunkt zur Einrichtung eingeladener Konten (/user-setup/{hash}/{invite_sent_at}) führt keine eigene Authentifizierung durch und gleicht den übergebenen hash direkt gegen den in der Datenbank gespeicherten invite_hash des Kontos ab. Nach Annahme einer Einladung und beim Login wird dieser invite_hash jedoch geleert, sodass aktivierte Konten einen leeren Wert tragen. Auf MySQL und MariaDB werden bei VARCHAR-Gleichheit nachstehende Leerzeichen ignoriert, weshalb ein einzelnes Leerzeichen (%20) den leeren invite_hash matcht. Die Ablaufprüfung des Zeitstempels greift nicht, weil die Entschlüsselungs-Hilfsfunktion bei einem Fehlschlag die Eingabe unverändert zurückgibt und damit ein Wert wie 9999999999 die Frist aushebelt. So setzt ein nicht authentifizierter Angreifer E-Mail und Passwort des aktivierten Kontos mit der niedrigsten ID und meldet sich an. turingpoint hat den End-to-End-Ablauf live verifiziert und verantwortungsvoll an den Hersteller gemeldet.

Ursache

Die Route POST /user-setup/{hash}/{invite_sent_at} (OpenController@userSetupSave, routes/web.php:30-31) sucht das Konto über den invite_hash und prüft weder eine Session noch eine andere Authentifizierung. Bei der Annahme der Einladung und beim späteren Login wird invite_hash auf einen leeren String gesetzt, sodass aktive Konten keinen Hash mehr tragen. Auf MySQL/MariaDB gilt bei VARCHAR-Vergleichen '' = ' ' als wahr, da nachstehende Leerzeichen bei der Gleichheitsprüfung ignoriert werden. Ein hash aus einem einzelnen Leerzeichen (%20) trifft daher den leeren invite_hash und liefert das aktivierte Konto mit der niedrigsten ID zurück. Die zusätzliche Frist über invite_sent_at läuft ins Leere, weil Helper::decrypt bei einem Entschlüsselungsfehler die Roh-Eingabe unverändert zurückgibt, sodass ein beliebiger Zukunftswert wie 9999999999 die Zeitprüfung besteht (app/Http/Controllers/OpenController.php:56,109,112,118,127-133). PostgreSQL ist nicht betroffen, da dort die Leerzeichen bei VARCHAR-Gleichheit signifikant sind. Der Hersteller hat den Abgleich so korrigiert, dass leere invite_hash-Werte nicht mehr matchen.

Proof of Concept

Ohne Authentifizierung, gegen eine FreeScout-Instanz auf MySQL/MariaDB mit mindestens einem aktivierten Konto:

# 1) Aktiviertes Konto mit der niedrigsten ID über leeren invite_hash adressieren
#    (einzelnes Leerzeichen %20 als hash, Zukunftswert als invite_sent_at)
GET /user-setup/%20/9999999999 HTTP/1.1

# 2) E-Mail und Passwort des getroffenen Kontos überschreiben
POST /user-setup/%20/9999999999 HTTP/1.1
Content-Type: application/x-www-form-urlencoded

[email protected]&password=NeuesPasswort123!&password_confirmation=NeuesPasswort123!

# 3) Mit den vom Angreifer gesetzten Zugangsdaten anmelden
# Kontrolle: dieselbe Anfrage gegen eine PostgreSQL-Instanz matcht den leeren invite_hash nicht.

Live verifiziert auf FreeScout 1.8.223 (MySQL): der anonyme Aufruf adressiert das aktivierte Konto mit der niedrigsten ID, setzt E-Mail und Passwort und ermöglicht die anschließende Anmeldung als dieses Konto.

Auswirkung

  • Vollständige Übernahme des aktivierten Kontos mit der niedrigsten ID (typischerweise ein Support-Agent oder Administrator), ohne Account, Secret oder Benutzerinteraktion.
  • Zugriff auf Postfächer, Konversationen und Kundendaten sowie, bei einem Administrator-Konto, potenziell instanzweite Kompromittierung.
  • Der ursprüngliche Kontoinhaber wird durch die geänderten Zugangsdaten dauerhaft ausgesperrt.
  • Betroffen sind ausschließlich Instanzen auf MySQL oder MariaDB; PostgreSQL-Installationen sind nicht angreifbar.

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