Trigger.dev vulnerabilities

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 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 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 4.5.0 before 4.6.0 contains an information disclosure vulnerability in the Dashboard Agent input proxy that stores a delegated user-actor token in browser-readable session input records. Attackers holding a chat's public session token can read the records endpoint to recover the token from payload.metadata.userActorToken and replay it for environment JWT exchange.

Trigger.dev before 4.7.3 contains a tenant filtering bypass vulnerability that allows authenticated users to read other tenants' data by using placeholder table syntax in POST /api/v1/query. Attackers can submit queries with FROM {database.table} expressions, including within subqueries, to skip table allowlist and tenant filters and expose run metadata and payloads.

Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. Prior to 4.5.6, POST /api/v1/deployments/:deploymentId/background-workers calls CreateDeploymentBackgroundWorkerServiceV4.call() in apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.ts, where workerDeployment.findFirst() selects a deployment by friendlyId without an environmentId predicate. A caller with a valid API key for one project can submit another project's deployment identifier, link an attacker-owned background worker to the victim deployment, and move the victim deployment from BUILDING to DEPLOYING. This issue is fixed in version 4.5.6.

Trigger.dev before 4.5.6 contains a cross-site request forgery vulnerability that allows remote attackers to log out authenticated users by sending a link to the GET-based /logout endpoint. Attackers can lure victims into clicking an obfuscated, URL-encoded link that terminates their session, causing 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 before 4.5.0 looks up runs by friendlyId alone in the api.v1.runs.$runParam.replay route without scoping the lookup to the caller's runtime environment. An attacker holding any tenant's API key who knows a victim's run friendlyId can replay that run into their own environment and read the victim's task payload.

Trigger.dev before 4.5.2 contains a cross-site request forgery vulnerability in the CLI authorization-code flow because loading /account/authorization-code/<code> mints a Personal Access Token without any consent step. Attackers mint an unauthenticated code, lure a logged-in user to that URL, then retrieve the victim's PAT from the unauthenticated /api/v1/token endpoint to take over the account.

Trigger.dev before 4.5.4 contains a hardcoded default secret vulnerability in the /coordinator Socket.IO namespace that allows unauthenticated attackers to connect using the published coordinator-secret value. Attackers can emit READY_FOR_EXECUTION to retrieve decrypted run environment variables or send TASK_RUN_FAILED_TO_RUN and similar events to tamper with arbitrary runs.

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 before 4.5.5 contains a missing authentication vulnerability in the realtime streams POST handler that allows unauthenticated attackers to inject data into run streams. Attackers can send POST requests to /realtime/v1/streams/:runId/:streamId with a predictable run friendlyId to inject arbitrary data into any environment's realtime stream, including production.

Trigger.dev before 4.5.6 contains an SQL injection vulnerability in the /realtime/v1/runs endpoint. The unescaped tags query parameter is concatenated into the ElectricSQL shape where clause, defeating the runtimeEnvironmentId tenant guard. An authenticated attacker holding any project API key with read:runs scope can append boolean conditions to stream TaskRun records, including payloads and metadata, from every organization on the same self-hosted instance.

Trigger.dev before 4.5.0-rc.3 contains a path traversal vulnerability in the api/v1/packets and api/v2/packets endpoints. Authenticated tenants can escape their object key prefix through an unsanitized filename splat segment. An attacker holding one valid API key can supply ../ sequences 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. An attacker 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 before 4.5.6 contains an SQL injection vulnerability in the TSQL query compiler, which concatenates window-function names into generated ClickHouse SQL without allowlisting or escaping. Authenticated customers can submit a backtick-quoted identifier to POST /api/v1/query that injects a raw subquery outside the per-tenant WHERE guard, exfiltrating other organizations' analytics data.

Trigger.dev before 4.5.6 contains an improper authorization vulnerability that allows holders of lower-trust environment API keys to cancel other environments' deployments because DeploymentService.getDeployment scopes lookups by projectId only. Attackers with a dev, preview, or CI secret key can POST to the deployment cancel endpoint to cancel in-progress production deployments within the same project.

Trigger.dev before 4.5.6 contains an authorization bypass vulnerability in DeleteTaskScheduleService and SetActiveOnTaskScheduleService that allows authenticated users to delete or disable other organizations' schedules. An attacker can send delete or disable actions through their own project's schedule route with a victim schedule friendlyId to destroy other organizations' IMPERATIVE 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. An attacker 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 before 4.5.2 contains a blind server-side request forgery vulnerability that allows authenticated tenants to make the webapp server send POST requests to internal hosts by setting an unvalidated webhook alert channel URL. Attackers can point the webhook at internal services or cloud metadata addresses and trigger alerts to scan internal hosts, send state-changing POSTs, or reach IMDSv1 via redirects.

Trigger.dev before 4.5.10 contains a server-side request forgery vulnerability that allows authenticated project members to bypass webhook SSRF protections by targeting the non-global 198.18.0.0/15 benchmarking range. Attackers can configure alert-channel webhooks pointing at internally routed services in this range, which isUnsafeIPv4 omits, to perform blind internal probing and limited state-changing POST requests.

The Trigger.dev webapp before 4.5.12 contains a cross-site request forgery vulnerability in its organization-level Slack OAuth flow, which uses the organization ID as the OAuth state without binding it to the initiating session. Attackers who know a target organization ID can trick an authenticated member into opening an unredeemed /integrations/slack/callback URL, connecting an attacker-controlled Slack workspace that may receive the organization's operational alerts.

Trigger.dev before 4.5.12 contains an authorization bypass vulnerability that allows authenticated project members to complete another member's DEVELOPMENT environment waitpoint by skipping the per-user environment ownership check. Attackers who know a victim's waitpoint friendly ID can submit type=DATETIME or type=MANUAL with isTimeout to prematurely mark the pending waitpoint completed.

Trigger.dev before 4.6.0 contains an improper authorization vulnerability in the GET /api/v1/projects/:projectRef/envvars endpoint, which returns the environment's root API key as TRIGGER_SECRET_KEY for staging, production, and preview environments. An attacker holding a restricted read:envvars key can obtain the root secret and plaintext secrets, then trigger tasks and mint admin public JWTs.

Trigger.dev before 4.6.0 contains a missing authorization vulnerability in the waitpoint token wait endpoint that allows authenticated attackers to block runs belonging to other organizations. An attacker holding any secret API key can supply a victim run ID with their own waitpoint, causing that run to block indefinitely on a waitpoint the victim cannot complete, and can inject resume data into it.

Trigger.dev 4.5.0 before 4.6.2 contains an improper authorization vulnerability in the PUT snapshot-url session endpoint that allows public session token holders to obtain presigned S3 write URLs. End users can overwrite their own session's durable chat snapshot to forge the agent's conversation history, since the route lacks a secret-key-only check.

Trigger.dev before 4.7.0 contains a missing authorization vulnerability that allows holders of unrestricted environment API keys to block runs they do not own by supplying a foreign parentRunId to batch-creation endpoints. An attacker can send requests to POST /api/v3/batches or POST /api/v2/tasks/batch with resumeParentOnCompletion to suspend, indefinitely block, or inject errors into production or cross-organization runs.

Trigger.dev before 4.6.0 fails to verify that an authenticated user controls a GitHub App installation before binding it to their organization. Attackers can claim another user's GitHub App installation by replaying state cookies and supplying sequential installation identifiers, gaining unauthorized access to the victim's repositories.

Trigger.dev before version 4.5.2 fails to validate environment membership during run replay operations, allowing authenticated attackers to inject task runs into arbitrary environments. Attackers can replay their own runs into other organizations' or projects' environments to consume victim resources and pollute run history.

Trigger.dev before 4.5.2 contains a server-side request forgery vulnerability in webhook alert channel delivery URLs that are fetched without validation or SSRF protection. Authenticated users with organization membership can create alert channels with URLs targeting internal services and metadata endpoints, allowing the server to issue POST requests to restricted resources.

Trigger.dev from version 4.4.2 to 4.5.0 has a vulnerability in packet presign routes where a caller-controlled filename is passed to generate presigned URLs, allowing directory traversal to escape the object-store prefix and enabling a project API key to read or overwrite another organization's offloaded task payloads on multi-organization self-hosted instances.

Trigger.dev from version 4.4.2 to 4.5.0-rc.5 has a vulnerability in Aws4FetchClient.buildUrl() and presign() where user-controlled packet keys are assigned to URL.pathname, and the route accepts params without rejecting dot segments and without per-resource ownership validation. WHATWG path normalization collapses .. segments before signing, allowing a caller with a valid environment API key to obtain presigned URLs for another tenant's object-store keys and read or overwrite task payloads.

Trigger.dev from version 4.4.2 to 4.5.0-rc.4 has a vulnerability in the POST /api/v1/runs/:runParam/replay endpoint. The database query does not filter by runtimeEnvironmentId, allowing any valid environment API key to replay another tenant's run by friendlyId. Additionally, when payloadType "application/store" is used, payload bytes can be overwritten by an attacker, leading to unauthorized actions.

Trigger.dev before version 4.5.2 contains a vulnerability in addGoogleStrategy() that passes a Google profile email to findOrCreateGoogleUser() without requiring Google's email_verified assertion. When an existing email-matched account exists, an attacker can take over the account using an unverified matching email from their own Google profile.

Trigger.dev from version 3.3.8 to 4.5.6 contains a vulnerability in the PUT /api/v1/runs/:runId/metadata endpoint, where operation.key values are passed to new JSONHeroPath(operation.key).set() without rejecting dangerous constructor and prototype path segments. A caller with a normal environment API key can pollute Object.prototype in the shared webapp process, corrupting Prisma queries and Prometheus labels, breaking other tenants' worker authentication, and causing a process-wide denial of service.