External risk intelligence

Trigger.dev Worker Linking Vulnerability Allows Deployment Hijacking

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-73656

The vulnerability exists within a public-facing API endpoint (/api/v1/deployments/) of a platform designed for building and deploying workflows. Such API surfaces are commonly exposed to the internet to facilitate remote interaction with the managed platform, making this deployment pattern a standard, internet-facing service.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability has been identified in the Trigger.dev platform, affecting how AI agents and workflows are managed and deployed. This issue could allow unauthorized actors to link external background workers to a victim's deployment, potentially leading to disruptions or unauthorized control over deployed services. The primary concern is to confirm if your organization utilizes this platform and is exposed to this specific risk.

Unauthorized control over deployed workflows.
Matters due to platform's workflow management capabilities.
Confirm relevance and exposure of this platform.

Attack Path

How an attacker could exploit the issue

An attacker with legitimate API access to one project could target another project's deployment. By manipulating the API call to include a different project's deployment ID, the attacker can associate their own background worker with the victim's deployment, forcing it into a "DEPLOYING" state. This ability to control a victim deployment's state can lead to significant disruption.

Requires authenticated API access.
Triggers by manipulating deployment identifiers.
Allows attacker control over victim deployment state.

Live Threat

Current exploitation, exposure, and threat context

A user with API access to one project could manipulate deployments in other projects by linking an attacker-controlled background worker to a victim deployment, potentially changing its status from BUILDING to DEPLOYING. This could disrupt normal service operations for the affected deployments.

Victim deployment status.
Unauthorized background worker linkage.
Service operations disruption.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Trigger.dev platform's API allows attackers to manipulate deployments by linking their own background workers to victim deployments, potentially causing a critical impact. Infrastructure and platform teams are likely responsible for managing the Trigger.dev environment. The immediate first step is to identify all instances of Trigger.dev, assess their reachability and criticality, and then locate the accountable owners to prioritize remediation efforts.

Platform and Infrastructure teams own resolution.
Verify affected Trigger.dev deployment reachability.
Plan remediation based on exposure and criticality.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Trigger.dev?

Trigger.dev is a specialized platform designed for developers to build, manage, and deploy event-driven background workflows and AI agents. It functions as an orchestration layer, allowing users to automate complex processes by executing code in response to events. Because it handles the deployment and lifecycle of these automated workers, the platform acts as a central hub for organizational automation.

What does CVE-2026-73656 mean for my workflows?

This vulnerability is an authorization flaw, specifically classified as an improper authorization and an unauthorized access to data issue (CWE-862 and CWE-639). It means the platform fails to verify that a user has permission to interact with a specific project. An attacker can essentially trick the system into allowing them to link their own external background worker to a deployment belonging to a different project, effectively hijacking that deployment's operational state.

How is this vulnerability triggered?

An attacker triggers this by submitting a request to a specific API endpoint using a deployment ID from a project they do not own. Because the system selects the deployment based solely on that identifier without checking if it belongs to the authenticated user's environment, the malicious association is accepted. It is important to note that simply having access to the platform is not enough; the attacker must already possess a valid API key and know the specific deployment ID of the target.

Is my Trigger.dev instance at risk?

According to Halo Surface Signal, this vulnerability resides in a public-facing API endpoint commonly used for remote management, making it highly likely to be internet-accessible. You should care if your Trigger.dev instance is exposed to the internet or accessible by external parties, as this increases the potential for unauthorized actors to manipulate your deployment states and disrupt your background workers.

How do I secure my environment?

The most effective first step is to update your Trigger.dev platform to version 4.5.6 or later, which resolves the authorization oversight. Before updating, work with your infrastructure teams to identify all instances of the platform currently running, determine their network reachability, and ensure that only authorized personnel have valid API keys for your projects.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.