Triggerdotdev
Monthly
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-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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
Trigger.dev before 4.6.0 allows an authenticated low-privilege user to bind an arbitrary GitHub App installation to their own organization, because the platform does not verify that the user controls that installation. By replaying a valid OAuth state cookie and supplying sequential GitHub App installation identifiers, an attacker can gain unauthorized access to the victim's repositories in multi-tenant or shared self-hosted deployments where multiple organizations connect GitHub Apps. Exploitation requires winning a timing race and is not push-button; no public exploit code or active exploitation has been identified at time of analysis.
Missing authorization on the run replay API endpoint in Trigger.dev before 4.5.2 allows authenticated attackers to inject task runs into environments belonging to other organizations or projects. By replaying their own historical runs into victim environments, attackers can consume victim compute resources and permanently pollute that organization's run history and audit logs. No public exploit has been identified at time of analysis, but the vulnerability is trivially exploitable by any authenticated platform user against any other tenant.
Path traversal in Trigger.dev's packet presign API routes (versions 4.4.2 through 4.4.x) allows a holder of any valid project API key to escape the intended packets/<projectRef>/<env>/ object-store prefix by injecting .. sequences into the caller-controlled filename parameter. On multi-organization self-hosted deployments, this enables cross-tenant reads and overwrites of offloaded task payloads and outputs. No public exploit code or CISA KEV listing exists at time of analysis; the CVSS 8.1 (High) rating reflects high confidentiality and integrity impact reachable by any authenticated project member without elevated privileges.
Cross-tenant path traversal in Trigger.dev versions 4.4.2 through pre-4.5.0-rc.5 allows any authenticated tenant holding a valid environment API key to obtain presigned AWS S3 URLs scoped to another tenant's object-store keys, enabling unauthorized read and write access to task payloads. The flaw combines user-controlled packet path keys written directly into URL.pathname without dot-segment rejection and a stub ownership check (findResource: async () => 1) that unconditionally returns truthy for any requested resource. No public exploit code has been identified at time of analysis, though the mechanism is straightforward to reproduce from the CVE description alone, and the vendor has released a fix in v4.5.0-rc.5.
Cross-tenant authorization bypass in Trigger.dev before 4.5.6 lets a caller holding a valid API key for one project act on another project's deployment. Because CreateDeploymentBackgroundWorkerServiceV4.call() looks up the deployment by friendlyId with no environmentId/tenant predicate, an attacker can attach an attacker-controlled background worker to a victim project's deployment and force it from BUILDING to DEPLOYING. No public exploit identified at time of analysis; the flaw is an insecure-direct-object-reference (IDOR) affecting the deployments API.
Account takeover in Trigger.dev before 4.5.2 allows an unauthenticated remote attacker to hijack any existing user account that has not yet linked a Google OAuth identity, by presenting a Google profile whose email is unverified but matches the victim's registered address. The `addGoogleStrategy()` function in `apps/webapp/app/services/googleAuth.server.ts` omits the `email_verified` assertion before calling `findOrCreateGoogleUser()`, causing the server to bind the attacker's Google `authIdentifier` to the victim's account when the conditional `existingEmailUser && !existingUser` is satisfied. No public exploit has been identified at time of analysis, but the fix is available in v4.5.2 and the attack requires no Trigger.dev credentials.
Prototype pollution in Trigger.dev's run metadata API (versions 3.3.8 through 4.5.5) lets any authenticated tenant corrupt the shared Node.js webapp process's Object.prototype by supplying crafted path keys to the PUT /api/v1/runs/:runId/metadata endpoint. The root cause is the unsanitized use of attacker-supplied operation.key values passed directly to JSONHeroPath.set() in packages/core/src/v3/runMetadata/operations.ts without filtering __proto__, constructor, or prototype segments. A single exploiting tenant can corrupt Prisma ORM queries, poison Prometheus metric labels, break other tenants' worker authentication, and cause a process-wide denial of service - making this a multi-tenant isolation failure with scope-changed impact. No public exploit code or CISA KEV listing has been identified at time of analysis.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Server-side request forgery in Trigger.dev before 4.5.2 allows authenticated organization members to register webhook alert channel URLs targeting internal network services, loopback addresses, or cloud provider metadata endpoints such as the AWS IMDSv1 service. When an alert is delivered, the Trigger.dev server issues an outbound POST request to the attacker-controlled URL without any URL validation or SSRF filtering, exposing internal infrastructure to probing and potentially yielding cloud IAM credentials. The vendor released v4.5.2 as a security hardening release that introduces URL sanitization via a `sanitizeHttpUrl` utility; no public exploit code or CISA KEV listing has been identified at time of analysis.
Cross-tenant run replay in Trigger.dev 4.4.2-4.5.0-rc.3 allows any authenticated API key holder to replay task runs belonging to other tenants by supplying a victim's run `friendlyId` to the replay endpoint, which performs no tenant isolation check. This unauthorized replay consumes victim compute resources and re-executes side effects such as outbound API calls, webhook triggers, and database writes. A secondary chained code path further allows attacker-controlled payload bytes - planted via a separate object-store path-traversal - to become input to the victim task when `payloadType: application/store` is in use. No public exploit has been identified at time of analysis, and this CVE is not listed in CISA KEV.
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-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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
Trigger.dev before 4.6.0 allows an authenticated low-privilege user to bind an arbitrary GitHub App installation to their own organization, because the platform does not verify that the user controls that installation. By replaying a valid OAuth state cookie and supplying sequential GitHub App installation identifiers, an attacker can gain unauthorized access to the victim's repositories in multi-tenant or shared self-hosted deployments where multiple organizations connect GitHub Apps. Exploitation requires winning a timing race and is not push-button; no public exploit code or active exploitation has been identified at time of analysis.
Missing authorization on the run replay API endpoint in Trigger.dev before 4.5.2 allows authenticated attackers to inject task runs into environments belonging to other organizations or projects. By replaying their own historical runs into victim environments, attackers can consume victim compute resources and permanently pollute that organization's run history and audit logs. No public exploit has been identified at time of analysis, but the vulnerability is trivially exploitable by any authenticated platform user against any other tenant.
Path traversal in Trigger.dev's packet presign API routes (versions 4.4.2 through 4.4.x) allows a holder of any valid project API key to escape the intended packets/<projectRef>/<env>/ object-store prefix by injecting .. sequences into the caller-controlled filename parameter. On multi-organization self-hosted deployments, this enables cross-tenant reads and overwrites of offloaded task payloads and outputs. No public exploit code or CISA KEV listing exists at time of analysis; the CVSS 8.1 (High) rating reflects high confidentiality and integrity impact reachable by any authenticated project member without elevated privileges.
Cross-tenant path traversal in Trigger.dev versions 4.4.2 through pre-4.5.0-rc.5 allows any authenticated tenant holding a valid environment API key to obtain presigned AWS S3 URLs scoped to another tenant's object-store keys, enabling unauthorized read and write access to task payloads. The flaw combines user-controlled packet path keys written directly into URL.pathname without dot-segment rejection and a stub ownership check (findResource: async () => 1) that unconditionally returns truthy for any requested resource. No public exploit code has been identified at time of analysis, though the mechanism is straightforward to reproduce from the CVE description alone, and the vendor has released a fix in v4.5.0-rc.5.
Cross-tenant authorization bypass in Trigger.dev before 4.5.6 lets a caller holding a valid API key for one project act on another project's deployment. Because CreateDeploymentBackgroundWorkerServiceV4.call() looks up the deployment by friendlyId with no environmentId/tenant predicate, an attacker can attach an attacker-controlled background worker to a victim project's deployment and force it from BUILDING to DEPLOYING. No public exploit identified at time of analysis; the flaw is an insecure-direct-object-reference (IDOR) affecting the deployments API.
Account takeover in Trigger.dev before 4.5.2 allows an unauthenticated remote attacker to hijack any existing user account that has not yet linked a Google OAuth identity, by presenting a Google profile whose email is unverified but matches the victim's registered address. The `addGoogleStrategy()` function in `apps/webapp/app/services/googleAuth.server.ts` omits the `email_verified` assertion before calling `findOrCreateGoogleUser()`, causing the server to bind the attacker's Google `authIdentifier` to the victim's account when the conditional `existingEmailUser && !existingUser` is satisfied. No public exploit has been identified at time of analysis, but the fix is available in v4.5.2 and the attack requires no Trigger.dev credentials.
Prototype pollution in Trigger.dev's run metadata API (versions 3.3.8 through 4.5.5) lets any authenticated tenant corrupt the shared Node.js webapp process's Object.prototype by supplying crafted path keys to the PUT /api/v1/runs/:runId/metadata endpoint. The root cause is the unsanitized use of attacker-supplied operation.key values passed directly to JSONHeroPath.set() in packages/core/src/v3/runMetadata/operations.ts without filtering __proto__, constructor, or prototype segments. A single exploiting tenant can corrupt Prisma ORM queries, poison Prometheus metric labels, break other tenants' worker authentication, and cause a process-wide denial of service - making this a multi-tenant isolation failure with scope-changed impact. No public exploit code or CISA KEV listing has been identified at time of analysis.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Server-side request forgery in Trigger.dev before 4.5.2 allows authenticated organization members to register webhook alert channel URLs targeting internal network services, loopback addresses, or cloud provider metadata endpoints such as the AWS IMDSv1 service. When an alert is delivered, the Trigger.dev server issues an outbound POST request to the attacker-controlled URL without any URL validation or SSRF filtering, exposing internal infrastructure to probing and potentially yielding cloud IAM credentials. The vendor released v4.5.2 as a security hardening release that introduces URL sanitization via a `sanitizeHttpUrl` utility; no public exploit code or CISA KEV listing has been identified at time of analysis.
Cross-tenant run replay in Trigger.dev 4.4.2-4.5.0-rc.3 allows any authenticated API key holder to replay task runs belonging to other tenants by supplying a victim's run `friendlyId` to the replay endpoint, which performs no tenant isolation check. This unauthorized replay consumes victim compute resources and re-executes side effects such as outbound API calls, webhook triggers, and database writes. A secondary chained code path further allows attacker-controlled payload bytes - planted via a separate object-store path-traversal - to become input to the victim task when `payloadType: application/store` is in use. No public exploit has been identified at time of analysis, and this CVE is not listed in CISA KEV.