Threat database

Trigger.dev versions before 4.5.6 are affected by a cross-site request forgery (CSRF) vulnerability. This flaw allows remote attackers to log out authenticated users by tricking them into clicking a specially crafted GET request to the /logout endpoint. The attack results in session termination and potential loss of unsaved work.

Trigger.dev before 4.5.0 performs no authentication or organization check in the action handler of the dashboard run replay route (resources.taskruns.$runParam.replay) and looks up the run by friendlyId alone. A remote attacker who knows a victim's run friendlyId can replay it into an environment of their choosing, exposing the victim's task payload or running the task again with the victim's secrets.

Trigger.dev versions before 4.5.0 have an authorization bypass vulnerability in the api.v1.runs.$runParam.replay route. The system looks up runs by friendlyId without restricting the lookup to the caller's runtime environment. An attacker with any tenant's API key who knows a victim's run friendlyId can replay that run in their own environment and access the victim's task payload.

Trigger.dev versions before 4.5.2 have a cross-site request forgery (CSRF) vulnerability in the CLI authorization-code flow. This flaw allows an attacker to cause a logged-in user to mint a Personal Access Token (PAT) without consent by visiting a crafted URL. The attacker can then retrieve the victim's PAT from an unauthenticated API endpoint and potentially take over the user's account.

Trigger.dev versions before 4.5.4 contain a vulnerability due to a hardcoded default secret in the /coordinator Socket.IO namespace. This allows unauthenticated attackers to connect using the published coordinator-secret value. Exploitation can lead to retrieval of decrypted run environment variables and tampering with arbitrary runs via specific event emissions.

Trigger.dev before 4.5.6 self-hosted Docker Compose deployments using the default secrets from hosting/docker/.env.example allow authentication bypass because the hardcoded MAGIC_LINK_SECRET lets anyone forge valid magic link tokens. Unauthenticated attackers can log in as any email address, then reach Postgres, Redis, and ClickHouse with default credentials from runner containers on infrastructure networks, compromising all tenant data.

Trigger.dev versions before 4.5.5 have a missing authentication vulnerability in the realtime streams POST handler. This flaw allows unauthenticated attackers to send POST requests to specific endpoints with predictable run identifiers, enabling injection of arbitrary data into any environment's realtime stream, including production environments.

Trigger.dev through 4.7.6 contains a missing authentication vulnerability in the supervisor workload server that allows workloads to manipulate runs belonging to other deployments without ownership verification. Attackers with network access and a valid run/snapshot pair can call the attempts/start endpoint to obtain resolved environment variables and run JWTs, or start, complete, and suspend other tenants' runs.

Trigger.dev versions before 4.5.6 have an SQL injection vulnerability in the /realtime/v1/runs endpoint. This flaw allows authenticated attackers with any project API key having read:runs scope to manipulate the tags query parameter, bypassing tenant isolation and accessing TaskRun records, including payloads and metadata, across all organizations on the same self-hosted instance.

Trigger.dev versions before 4.5.0-rc.3 have a path traversal vulnerability in the api/v1/packets and api/v2/packets endpoints. Authenticated tenants can exploit this by using unsanitized filename segments containing ../ sequences to escape their object key prefix. This allows them to obtain presigned GET or PUT URLs and read or overwrite other tenants' run payloads and outputs.

Trigger.dev before 4.6.2 contains an authorization vulnerability that allows public-token holders with session write access to obtain environment-wide S2 stream credentials via session input initialization. Attackers can use the credential directly against the storage API to append, create, or trim other session and run streams, forging output or permanently deleting records.

Trigger.dev versions before 4.5.6 contain an SQL injection vulnerability in the TSQL query compiler. This flaw arises because window-function names are concatenated into generated ClickHouse SQL queries without proper allowlisting or escaping. Authenticated users can exploit this by submitting specially crafted identifiers to the POST /api/v1/query endpoint, enabling injection of raw subqueries that bypass tenant-specific data restrictions and potentially exfiltrate analytics data from other organizations.

Trigger.dev before 4.5.2 contains a blind server-side request forgery vulnerability that allows authenticated project members to make the server send requests by setting unvalidated alert-channel webhook URLs. Attackers can create alert channels pointing to loopback, internal, or cloud metadata addresses, then trigger alerts to probe internal service reachability and send signed POST requests.

Trigger.dev versions before 4.5.6 have an authorization bypass vulnerability that allows users with lower-trust environment API keys (such as dev, preview, or CI keys) to cancel deployments in other environments within the same project. This occurs because the DeploymentService.getDeployment method scopes lookups only by projectId, not by environment or key trust level.

Trigger.dev versions before 4.5.6 have an authorization bypass vulnerability in the DeleteTaskScheduleService and SetActiveOnTaskScheduleService. This flaw allows authenticated users to delete or disable schedules belonging to other organizations by exploiting user-controlled keys. Attackers can misuse their own project's schedule route with a victim's schedule friendlyId to affect other organizations' cron schedules.

Trigger.dev before 4.5.6 contains an authorization bypass vulnerability in createDeploymentBackgroundWorkerV4 that resolves a WorkerDeployment by friendlyId alone, without environment, project, or organization scoping. Attackers holding only their own environment API key can POST to the deployment background-workers endpoint with a victim's deployment ID to re-point that in-progress deployment at a worker in the attacker's environment.

Trigger.dev versions before 4.5.2 contain a blind server-side request forgery (SSRF) vulnerability. Authenticated tenants can exploit this by setting an unvalidated webhook alert channel URL, causing the server to send POST requests to internal hosts. This can be used to interact with internal services or cloud metadata endpoints, potentially triggering state-changing requests or accessing IMDSv1 via redirects.

Trigger.dev before 4.5.12 contains an authorization bypass vulnerability that allows holders of capability-restricted user-actor tokens to create alert channels by using the legacy personal access token helper. Attackers with a read-only UAT can POST to the project alertChannels endpoint to create production webhook channels, routing future deployment and error alerts to attacker-controlled infrastructure.

Trigger.dev versions before 4.5.10 contain a server-side request forgery (SSRF) vulnerability. Authenticated project members can bypass webhook SSRF protections by targeting the non-global 198.18.0.0/15 benchmarking IP range. This allows attackers to configure alert-channel webhooks to internally routed services within this range, enabling blind internal probing and limited state-changing POST requests.

Trigger.dev CLI versions before 4.5.9 have an information disclosure vulnerability where sensitive environment variables are logged in debug deployment logs without redaction. This exposure allows attackers with access to terminal transcripts, CI debug logs, or support bundles to recover sensitive data such as database connection strings and service credentials. The vulnerability has a CVSS 4.0 base score of 6.8, indicating medium severity.