Trigger.dev says an attacker used customer root API keys to reach environment variables for 0.66% of customers

Trigger.dev published a security disclosure on November 1, 2026, and a follow-up incident report on November 6. The November 1 disclosure said an attacker gained unauthorized access to environment variables for a subset of organizations, that Trigger.dev had blocked the exploit, and that it had emailed impacted account owners with mitigation steps.

The November 6 report says Trigger.dev became aware of the incident on November 1 after infrastructure alerts for anomalous activity, identified the activity as malicious, and blocked the attacker and mitigated the attack vector. It says it cannot yet comment on the specific attack vector, and that it will aim to share that when it believes it can do so responsibly. It says it has engaged cybersecurity incident response experts and notified law enforcement.

What was reachable

The report says the attacker obtained Trigger.dev customer root API keys for some customer environments. A customer root API key, it says, gives full access to that environment's settings, including its environment variables. In some of those environments, the attacker listed recent runs, deployments and schedules. The report says those calls return data that includes run IDs, deployment IDs, schedule IDs, task names, run idempotency keys, run status, run tags, deployment metadata, deployment error, schedule external id, and run metadata. It says it found no evidence that the attacker accessed any other customer data, any services, any of Trigger.dev's production databases, or any customer dashboard accounts. It says 0.66% of all customers were affected.

What Trigger.dev asks you to do

Trigger.dev says impacted customers received an email on November 1 at approximately 21:36 UTC and again on November 2 at 20:27 UTC, and see a notification banner in their Trigger.dev dashboard. Those notifications name the environments involved. It says customers who have not received an impact notification were not affected.

For impacted customers, Trigger.dev recommends regenerating Trigger.dev API keys (it says all exposed Trigger.dev API keys have been revoked) and rotating credentials in the affected environments, including database passwords, third-party API keys and access tokens, by revoking the previous credentials with their providers. It says webhook signing secrets were not exposed and do not need to be rotated. It says self-hosted deployments were not impacted, and still recommends self-hosters run in single-tenant mode by setting WHITELISTED_EMAILS to only accounts they control.

Trigger.dev also says it rotated its own internal credentials, reviewed API access logs across customer environments, applied risk-based automated account restrictions, and released IP whitelisting for scoped API keys plus OIDC support.

Our advice, not Trigger.dev's: when you rotate a secret that lived in a Trigger.dev environment variable, revoke it at the service that issued it before or as you set the new value and redeploy. Changing the value in Trigger.dev alone does not revoke the old key at its source. Then check that provider's usage and access logs from late October 2026 onward.