Trigger.dev Authorization and Injection Flaws

Authentication bypass in Trigger.dev self-hosted v4 deployments (npm trigger.dev <=4.5.5) allows unauthenticated attackers to forge magic-link tokens and log in as any email address when the default MAGIC_LINK_SECRET from hosting/docker/.env.example is still in use. Publicly available exploit code exists; successful exploitation can expose or modify tenant data, and may escalate to full infrastructure compromise because default Postgres, Redis, and ClickHouse credentials are reachable from runner containers on the same Docker network. The issue is limited to Docker Compose deployments that never rotated the example secrets and left WHITELISTED_EMAILS unset; the hosted SaaS and instances with regenerated secrets or an email allowlist are not affected.

Trigger.dev self-hosted and cloud deployments through version 4.7.6 expose a supervisor workload API endpoint (attempts/start) that performs no ownership check, letting a caller act on runs and snapshots belonging to other deployments. Exploitation is not anonymous: an attacker must already hold a legitimate low-privilege run/snapshot pair and must reach the supervisor over an adjacent network segment, after which they can read resolved environment variables and run JWTs or start, complete, and suspend other tenants' runs. There is no public exploit code or confirmed active exploitation (no CISA KEV), and the vendor advisory GHSA-jc26-22qp-cgqj is the authoritative reference; risk concentrates in multi-tenant or hosted installations where untrusted workloads share a supervisor, while single-tenant self-hosted setups with no third-party workloads are materially less exposed.

Cross-site request forgery in Trigger.dev before 4.5.2 lets an attacker mint a Personal Access Token for a logged-in victim and then collect it from the unauthenticated /api/v1/token endpoint, resulting in full account takeover. The flaw affects Trigger.dev deployments running versions prior to 4.5.2 and requires only that the victim have an active authenticated session and be lured into opening a crafted /account/authorization-code/<code> URL. No public exploit identified at time of analysis; the vendor advisory GHSA-58mc-m3qq-6qrh and the VulnCheck advisory provide further detail, and upgrading to 4.5.2 addresses the vulnerable flow.

Trigger.dev before 4.6.0 exposes each environment's root TRIGGER_SECRET_KEY and other plaintext secrets through the GET /api/v1/projects/:projectRef/envvars endpoint, so an attacker holding a restricted read:envvars API key can escalate beyond that key's intended read-only scope. The affected environments are staging, production, and preview, and successful exploitation lets the attacker trigger tasks and mint admin public JWTs; exploitation requires a valid scoped key rather than anonymous access. This is a genuine priority rather than a high-score/low-real-risk issue, and no public exploit identified at time of analysis.

Path traversal in Trigger.dev's api/v1/packets and api/v2/packets presigned-URL endpoints lets any holder of a single valid API key escape its tenant object-key prefix and read or overwrite other tenants' run payloads and outputs. Tracked as CVE-2026-114083 and rated 8.6 under CVSS 4.0 (assessed 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), the flaw affects releases before 4.5.0-rc.3 and requires authenticated, low-privilege tenant access with no user interaction and no named non-default configuration. No KEV listing or public exploit code was reported in the available intelligence, and real-world impact is concentrated on shared or multi-tenant deployments, since single-tenant self-hosted instances have no other tenants' objects to reach.

Unauthenticated remote attackers can bypass Socket.IO authentication on self-hosted Trigger.dev webapps before 4.5.4 because the /coordinator namespace authenticates against a source-published default COORDINATOR_SECRET ('coordinator-secret') that is absent from the self-hosting docs, .env.example, and Helm values, so operators who never overrode it ship the published value. With that value an attacker can emit READY_FOR_EXECUTION to pull a run's decrypted environment variables (V1/marqs deployments, provided an internal runId is known) or send TASK_RUN_FAILED_TO_RUN, TASK_RUN_COMPLETED, CHECKPOINT_CREATED and similar events to tamper with arbitrary runs. No public exploit code or confirmed active exploitation was identified at time of analysis; exposure is confined to self-hosted deployments left on the default secret, and Trigger.dev Cloud is not implicated by this self-host default-configuration issue.

Trigger.dev's dashboard run replay endpoint lets an attacker who knows or enumerates a run friendlyId replay another organization's task run into an environment of the attacker's choosing, potentially exposing task payloads and executing the task with the victim's secrets. The vendor CVSS 4.0 score is 8.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N), with an independent CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N; the CVSS PR:N designation suggests unauthenticated access, although the GHSA's 'any authenticated user' wording means authentication requirements are not definitively confirmed. Publicly available exploit code exists (a PoC POST request is included in the GHSA), but no CISA KEV entry or confirmed active exploitation appears in the supplied data.

Cross-tenant SQL injection in Trigger.dev's TSQL/TRQL query compiler (versions up to and including 4.5.5) allows any authenticated customer holding a valid API key to read other organizations' analytics data from the shared ClickHouse backend through the customer-facing POST /api/v1/query endpoint. The compiler applies its allowlists, identifier escaping, and per-tenant WHERE guard everywhere except the window-function name, which is concatenated raw into the generated SQL, so a backtick-quoted identifier can smuggle a raw subquery that sits outside the tenant guard. Exploitation requires authentication (PR:L) and a multi-tenant deployment for maximum impact; no public exploit code identified at time of analysis, and the issue is fixed in 4.5.6.

SQL injection in Trigger.dev before 4.5.6 lets an authenticated caller holding a project API key with read:runs scope read TaskRun records, including payloads and metadata, across organizations on a multi-tenant self-hosted instance by supplying malicious SQL in the tags query parameter of /realtime/v1/runs. The flaw is high severity but operationally meaningful primarily where multiple organizations share the same self-hosted deployment; single-tenant or SaaS-isolated deployments do not expose foreign tenant data in the same way. No public exploit identified at time of analysis.

Missing authentication in the Trigger.dev CLI MCP server (cli-v3 3.0.0 through 4.5.3) exposes the /sse and /messages endpoints to adjacent-network attackers or malicious web pages while a developer runs 'trigger dev --mcp'. An unauthenticated attacker able to reach the bound port can issue MCP tools/call requests that use the developer's locally stored access token to trigger tasks, cancel runs, list runs, and retrieve run logs; exploitation is limited to active MCP-mode development sessions, and no public exploit was identified at time of analysis.

Trigger.dev prior to 4.7.0 fails to enforce ownership checks on the parentRunId supplied to batch-creation endpoints, allowing authenticated holders of unrestricted environment API keys to suspend, indefinitely block, or inject errors into runs they do not own, including cross-organization or production runs on shared deployments. The flaw is rated CVSS 7.2 and is an IDOR-style missing authorization issue (CWE-639); no public exploit code or CISA KEV entry was identified at time of analysis. Risk is concentrated in multi-tenant or shared instances where foreign run IDs are reachable, and is materially lower in isolated single-tenant deployments.

Trigger.dev before 4.6.0 fails to enforce organization scoping in the waitpoint token wait endpoint, allowing an authenticated attacker who holds any valid secret API key to supply another organization's run ID and make that run block indefinitely on a waitpoint the victim cannot complete; the same path can also inject resume data into the targeted run. This is an IDOR-class authorization flaw (CWE-639) affecting default multi-tenant deployments prior to 4.6.0, with the greatest practical impact on shared instances where keys from one organization can reference another organization's runs. No public exploit identified at time of analysis.

Cross-organization schedule deletion and disabling in Trigger.dev before 4.5.6 allows authenticated users with their own project schedule route to target another organization's IMPERATIVE cron schedule by supplying the victim schedule's friendlyId to delete or disable actions. The flaw is a CWE-639 authorization bypass/IDOR in DeleteTaskScheduleService and SetActiveOnTaskScheduleService, which resolve the friendlyId without scoping it to the caller's organization; exploitation requires authentication and knowledge or enumeration of the victim's friendlyId, and impact is limited to schedule integrity/availability with no data disclosure. No public exploit was identified at the time of analysis, and CISA KEV does not list this CVE.

Trigger.dev deployments before 4.6.2 return environment-wide S2 stream credentials to any caller who presents a public token with session write access and initializes session input, letting that narrowly scoped token reach every stream in the environment. With the leaked credential, an attacker talks to the S2 storage API directly to append to, create, or trim other sessions' and runs' streams, forging job output or permanently deleting records. Integrity and availability are both assessed high while confidentiality is unaffected, and exploitation is gated on possession of a valid session-write-capable public token (authenticated, PR:L) with no public exploit code or CISA KEV entry identified at time of analysis.

Tenant isolation bypass in Trigger.dev releases before 4.7.3 lets an authenticated user read run metadata and payloads belonging to other tenants by submitting crafted queries to POST /api/v1/query that reference tables through the 'FROM {database.table}' placeholder syntax, including inside subqueries. Only confidentiality is affected - the flaw exposes data but does not allow modification, deletion, or code execution - so the practical exposure is concentrated in shared SaaS or multi-tenant self-hosted deployments, while single-tenant installations have no other tenant data to disclose. Authentication with a valid account is required (CVSS PR:L), no public exploit code has been identified at time of analysis, and the issue is not in CISA KEV; the assigned CVSS 4.0 score is 7.1, though an independent CVSS 3.1 assessment places it at 6.5 given the read-only impact.

Improper authorization in Trigger.dev 4.5.0 through 4.6.1 lets authenticated holders of a valid public session token obtain presigned S3 write URLs and overwrite their own session's durable chat snapshot, forging the agent's conversation history. The PUT snapshot-url session endpoint lacks a secret-key-only authorization check, and the affected range ends before 4.6.2. No public exploit code has been identified at the time of analysis, and the independent assessment limits impact to the token holder's own session with no confidentiality, availability, or cross-tenant effect.

Unauthenticated data injection in Trigger.dev before 4.5.5 allows remote attackers to write arbitrary content into a run's realtime stream by POSTing to /realtime/v1/streams/:runId/:streamId. The handler has no auth wrapper and the run lookup is not scoped to a runtime environment, so a known or guessed predictable friendlyId (e.g. run_1234abcd) can reach production streams, though impact is bounded to integrity of stream data with no read access, code execution, or availability loss. No public exploit code identified at time of analysis.

Trigger.dev CLI versions before 4.5.9 can disclose resolved environment secret values when deployment is run with debug logging, because the debug output serializes the build-worker options object with unredacted envVars; this exposes database connection strings and service credentials to anyone who can read the resulting terminal transcript, CI debug log, captured tool output, or support bundle. The assessed impact is confidentiality-only (CWE-532, CVSS:3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N), and exploitation is constrained by the need for debug-level logging and access to retained output; normal non-debug environment listings redact values. Trigger.dev 4.5.9 contains the vendor fix, and no public exploit code is identified at time of analysis.

Trigger.dev before 4.5.6 allows cross-tenant deployment hijacking: an attacker holding any valid environment API key can POST a victim's deployment friendlyId to the background-workers endpoint and re-point an in-progress deployment to a worker in the attacker's environment. The flaw is an IDOR/CWE-639 in createDeploymentBackgroundWorkerV4, which resolves deployments by friendlyId without environment, project, or organization scoping; exploitation requires knowing the victim friendlyId and hitting the deployment while it is still in progress. Vendor patch 4.5.6 is available, and no public exploit identified at time of analysis.

Cross-tenant run replay in Trigger.dev versions before 4.5.0 allows any authenticated tenant holding a valid API key to replay another customer's run into their own runtime environment and read the victim's task payload. The api.v1.runs.$runParam.replay route resolves runs by friendlyId alone without scoping the lookup to the caller's environment, so exploitation requires knowledge of the victim's specific friendlyId rather than being broadly enumerable. Impact is bounded to confidentiality (payload disclosure, no integrity or availability effect) and is most relevant in shared or multi-tenant hosted deployments; the vendor has released a fix in 4.5.0, and no public exploit code has been identified at time of analysis.

Server-side request forgery in Trigger.dev before 4.5.10 allows authenticated project members with webhook configuration rights to bypass the platform's SSRF protections and direct alert-channel webhooks at internal services hosted in the 198.18.0.0/15 benchmarking range. Exploitation is bounded: responses are not returned to the attacker, so impact is limited to blind internal probing and limited state-changing POST requests (CVSS 4.0 5.3, PR:L, VC:L/VI:L). No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue only matters for deployments that route reachable internal services in that CIDR.

Cross-site request forgery in Trigger.dev webapp before 4.5.12 lets an attacker who knows a target organization ID trick an already-authenticated member into opening an unredeemed /integrations/slack/callback URL, causing the organization's Slack alert integration to connect to an attacker-controlled workspace. The flaw is a CWE-352 session-binding failure in the organization-level Slack OAuth state handling; exploitation requires user interaction and an already-authenticated member, and impact is limited to hijacking operational alert delivery rather than full account compromise. There is no CISA KEV entry, no public exploit identified at time of analysis, and the vendor has released 4.5.12.

Blind server-side request forgery in Trigger.dev (all versions up to and including 4.5.1, fixed in 4.5.2) lets an authenticated tenant with permission to create or edit a WEBHOOK alert channel supply an arbitrary URL that the multi-tenant webapp server later POSTs to when an alert fires. Because the URL is persisted with no host allowlist or private-IP/metadata blocklist and the server-side fetch follows redirects, a tenant can coerce the server into probing internal hosts and ports through a delivery success/timing oracle, issue state-changing POSTs to internal services, or reach IMDSv1 via a redirect to 169.254.169.254. Exploitation requires a valid account or project PAT and the ability to fire an alert such as a deployment or run failure; the attack is blind and POST-only (the body is a fixed HMAC-signed alert payload), so it does not yield arbitrary GET-based data exfiltration, and impact is markedly higher on cloud hosts with reachable IMDSv1 and no egress filtering. No public exploit tooling was identified at time of analysis, though the upstream advisory documents a reproduction proven against a self-hosted instance.

Cross-environment authorization bypass in Trigger.dev before 4.5.6 lets holders of lower-trust environment secret keys (dev, preview, or CI) cancel in-progress production deployments inside the same project. The cancel path resolves deployments through DeploymentService.getDeployment, which filters on projectId only and never on environmentId, so a key that is refused with a 404 when reading a production deployment through the correctly environment-scoped GET route can still abort it while it sits in PENDING, INSTALLING, BUILDING, or DEPLOYING state. Impact is moderate (CVSS 5.3, authenticated with PR:L): the flaw cannot cross project boundaries, cannot read or exfiltrate deployment data, and only cancels rather than modifies or creates deployments; no public exploit code was identified at time of analysis, and the issue is fixed in 4.5.6.

Cross-site request forgery in Trigger.dev before 4.5.6 lets remote attackers terminate an authenticated user's session by luring them to the GET-based /logout endpoint, causing loss of unsaved work. The victim must be logged in and must load an attacker-controlled, URL-encoded link; no data is read or modified. Vendor-released patch 4.5.6 is available, and no public exploit identified at time of analysis.

Trigger.dev before 4.5.12 allows holders of a read-only, capability-restricted user-actor token to create production alert channels through the legacy personal access token helper, redirecting deployment and error alerts to attacker-controlled webhooks. The flaw requires an already-issued low-privileged UAT and affects only deployments on versions prior to 4.5.12; impact is limited to low confidentiality and integrity with no availability effect. No public exploit identified at time of analysis, and the vendor has released a fixed version.

Trigger.dev before 4.5.2 allows authenticated project members to set unvalidated alert-channel webhook URLs, enabling blind server-side request forgery against loopback, internal, or cloud metadata endpoints. An attacker with a project account can create such an alert channel and trigger alerts to probe internal service reachability and cause signed POST requests to be sent to attacker-chosen destinations, although response bodies are not returned to the attacker. This is a medium-severity issue (CVSS 4.0 base 5.3; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) with a limited risk profile; no public exploit identified at time of analysis.

Trigger.dev versions 4.5.0 through 4.5.x expose a delegated user-actor token through the Dashboard Agent input proxy, which persists the token in browser-readable session input records at payload.metadata.userActorToken. An attacker who already holds a chat's public session token can query the input records endpoint to recover that credential and replay it to exchange for an environment JWT, yielding low-privilege read access within the targeted environment; the CVSS 4.0 base score is 5.1 and the assessed CVSS 3.1 vector indicates network-reachable, low-privilege, user-interaction-dependent confidentiality impact only. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the issue is fully remediated in 4.6.0.

Trigger.dev before 4.5.12 permits an authenticated project member to prematurely complete another member's DEVELOPMENT-environment waitpoint by knowing the victim's friendly waitpoint ID and submitting a crafted completion request, bypassing the per-user ownership check. The impact is low and limited to integrity of a pending development waitpoint; production environments are not affected. No public exploit was identified at the time of analysis, and a vendor patch is available.