Tracecat: Account-Übernahme über unsignierte SAML-Responses in Docker-Compose

In Docker-Compose-Deployments von Tracecat überschreiben leere SAML-Signing-Variablen die sicheren Anwendungs-Defaults und deaktivieren die Signaturprüfung, sodass ein unauthentifizierter Angreifer unsignierte SAML-Responses fälschen und beliebige Konten inklusive Superadmin übernehmen kann.

Advisory-ID: TP-2026-033
Produkt: Tracecat (Open-Source-Security-Automation, self-hosted)
Schwachstellentyp: Fehlende Prüfung der SAML-Signatur (unsignierte SAML-Response akzeptiert) (CWE-347)
CVE: CVE-2026-58490
CVSS 3.1: 9.8 (Kritisch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Betroffene Versionen: <= 1.0.0-beta.48 (nur Docker-Compose-Deployments)
Behoben in: 1.0.0-beta.49
Hersteller-Advisory: GHSA-6g53-h6fh-c3pj
Gemeldet: 3. Juni 2026

Zusammenfassung

Tracecat ist eine Open-Source-Plattform für Security-Automation (SOAR). In Docker-Compose-Deployments wird der SAML-Service-Provider mit want_assertions_signed und want_response_signed aus den Umgebungsvariablen SAML_SIGNED_ASSERTIONS und SAML_SIGNED_RESPONSES konfiguriert. Sind diese Variablen leer, wird die Signaturprüfung deaktiviert. Ein unauthentifizierter Angreifer mit Netzwerkzugriff auf den SAML-ACS-Endpoint kann dadurch eine unsignierte SAML-Response für ein bestehendes Konto fälschen und eine gültige Sitzung erhalten, bis hin zur Übernahme eines Superadmin-Kontos. Fargate- und Helm/Kubernetes-Deployments sind nicht betroffen. turingpoint hat die Schwachstelle verifiziert und gemeldet; der Hersteller hat sie in 1.0.0-beta.49 behoben.

Ursache

Der SAML-ACS-Handler baut den pysaml2-Service-Provider mit want_assertions_signed/want_response_signed aus SAML_SIGNED_ASSERTIONS/SAML_SIGNED_RESPONSES. Der Code-Default ist "true" (in config.py), wird aber in docker-compose.yml durch ${SAML_SIGNED_*} still ausgehebelt: Da die Variablen in .env/.env.example nicht definiert sind, injiziert Compose einen vorhandenen, aber leeren String. "" != "true" schaltet die Signaturprüfung ab. Ein Angreifer stösst über anonymes GET /auth/saml/login einen Request an, fälscht eine unsignierte SAML-Response mit einem email-Attribut des Opfers (eine leere TRACECAT__AUTH_ALLOWED_DOMAINS akzeptiert jede Domain), POSTet sie an den öffentlichen ACS, und saml_callback(associate_by_email=True) meldet ihn im bestehenden Konto an. Der Fix setzt sichere SAML-Signing-Defaults für Docker-Compose.

Proof of Concept

# Schematisch. Docker-Compose-Deployment mit aktiviertem SAML-SSO,
# SAML_SIGNED_ASSERTIONS / SAML_SIGNED_RESPONSES unbesetzt (leerer String).

# 1. Anonym eine SAML-Sitzung anstossen:
GET /auth/saml/login

# 2. Unsignierte SAML-Response fälschen, email-Attribut = Opfer
#    (z. B. der password-erstellte Superadmin), an den öffentlichen
#    ACS-Endpoint POSTen:
POST /auth/saml/acs
Content-Type: application/x-www-form-urlencoded

SAMLResponse=<base64(unsignierte SAML-Response mit [email protected])>

# 3. Der ACS akzeptiert die unsignierte Response (Signaturprüfung aus)
#    und assoziiert per E-Mail mit dem bestehenden Konto:
#    303 See Other
#    Set-Cookie: fastapiusersauth=...

# 4. Mit dem Cookie als Opfer authentifiziert:
GET /api/users/me   ->   {"is_superuser": true, ...}

# Kontrolle: mit SAML_SIGNED_*=true -> 400 "Signature missing".

Auswirkung

  • Unauthentifizierte Fälschung unsignierter SAML-Responses für beliebige bestehende Konten.
  • Übernahme beliebiger Konten inklusive eines password-erstellten Superadmins (pre-existing Account Takeover).
  • Voller Zugriff auf alle Workspaces, Secrets und Workflows der Plattform.
  • Voraussetzung ist lediglich aktiviertes SAML-SSO und Netzwerkzugriff auf den öffentlichen ACS-Endpoint, keine Authentifizierung und keine Nutzerinteraktion.

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