| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 before 4.5.6 contains an authorization bypass vulnerability in DeleteTaskScheduleService and SetActiveOnTaskScheduleService that allows authenticated users to delete or disable other organizations' schedules. Attackers 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 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.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 before 4.5.0-rc.3 contains a path traversal vulnerability in the api/v1/packets and api/v2/packets endpoints that allows authenticated tenants to escape their object key prefix through an unsanitized filename splat segment. Attackers 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.5.6 contains an SQL injection vulnerability in the /realtime/v1/runs endpoint, which concatenates the unescaped tags query parameter into the ElectricSQL shape where clause and defeats the runtimeEnvironmentId tenant guard. Authenticated attackers 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 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 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.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 versions before 4.5.2 fail 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 is a platform for building and deploying fully managed AI agents and workflows. Prior to 4.5.2, addGoogleStrategy() in apps/webapp/app/services/googleAuth.server.ts passes a Google profile email to findOrCreateGoogleUser() in apps/webapp/app/models/user.server.ts without requiring Google's email_verified assertion. When existingEmailUser && !existingUser is true, the flow writes the new Google authIdentifier into the existing email-matched account and returns that user object, allowing an attacker-controlled Google profile with an unverified matching email to take over the account. This issue is fixed in version 4.5.2. |
| Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. From 4.4.2 until 4.5.0-rc.4, `POST /api/v1/runs/:runParam/replay` in apps/webapp/app/routes/api.v1.runs.$runParam.replay.ts uses `prisma.taskRun.findUnique({ where: { friendlyId: runParam } })` without a runtimeEnvironmentId filter, then ReplayTaskRunService in apps/webapp/app/v3/services/replayTaskRun.server.ts replays the selected run in the victim environment. Any valid environment API key can therefore replay another tenant's run by friendlyId, consuming victim resources and repeating side effects; when `payloadType: "application/store"` is used, overrideExistingPayloadPacket() calls conditionallyImportPacket() on existingTaskRun.payload without an integrity check, so payload bytes overwritten through a separate object-store path-traversal vulnerability become attacker-controlled input to the victim task. This issue is fixed in version 4.5.0-rc.4. |
| 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 is the open-source platform for building AI workflows in TypeScript. From 4.4.2 until 4.5.0, the packet presign routes in apps/webapp/app/routes/api.v1.packets.$.ts pass a caller-controlled filename through resolveStoreProtocolForPacketPresign to generatePresignedUrl and generatePresignedRequest in apps/webapp/app/v3/objectStore.server.ts, allowing .. traversal to escape the packets/<projectRef>/<env>/ object-store prefix and enabling a project API key to read or overwrite another organization's offloaded task payloads and outputs on multi-organization self-hosted instances. This issue is fixed in version 4.5.0. |
| Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. From 3.3.8 until 4.5.6, the PUT /api/v1/runs/:runId/metadata endpoint passes attacker-controlled operation.key values to new JSONHeroPath(operation.key).set(newMetadata, value) in packages/core/src/v3/runMetadata/operations.ts 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. This issue is fixed in version 4.5.6. |
| Trigger.dev is a platform for building and deploying fully managed AI agents and workflows. From 4.4.2 until 4.5.0-rc.5, Aws4FetchClient.buildUrl() and Aws4FetchClient.presign() in apps/webapp/app/v3/objectStoreClient.server.ts assign user-controlled packet keys to URL.pathname, while apps/webapp/app/routes/api.v1.packets.$.ts accepts params["*"] without rejecting dot segments and uses findResource: async () => 1 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. This issue is fixed in version 4.5.0-rc.5. |
