The trigger.dev self-hosted deployment using version 4 and the default Docker Compose setup with secrets from hosting/docker/.env.example is vulnerable due to hardcoded cryptographic secrets. The MAGIC_LINK_SECRET is used by [email protected] for AES encryption of authentication tokens. Since the secret is known and session validation is disabled by default, attackers can forge magic link tokens to authenticate as any email address without email delivery. User accounts are auto-created when WHITELISTED_EMAILS is unset. The infrastructure services (Postgres, Redis, ClickHouse) use default or no authentication and are accessible from runner containers on the infrastructure network. This chain of issues results in complete infrastructure compromise, including data access, secret decryption, and potential manipulation of job queues and Docker images.

An attacker can gain unauthenticated access to the trigger.dev self-hosted instance by forging magic link tokens, leading to automatic user creation and session hijacking. This access extends to infrastructure services such as Postgres, Redis, and ClickHouse, which have default or no authentication, allowing full data access and manipulation. The attacker can decrypt encrypted secrets using the known ENCRYPTION_KEY, access all tenant data and API keys, and potentially push backdoored Docker images and manipulate job queues. The overall impact is complete infrastructure compromise.

A patch is available for this vulnerability. Users should update trigger.dev to version 4.5.6 or later where this issue is fixed. Additionally, avoid deploying with default secrets from hosting/docker/.env.example. Replace all hardcoded secrets with unique, strong secrets and configure authentication for infrastructure services such as Redis and Postgres. Restrict network access to infrastructure containers and enable session validation features if applicable.