Trigger.dev published a security incident report on Sunday confirming that an intruder reached environment variables belonging to a subset of its customers. The company says the method used has been blocked and that affected organizations have been contacted.
It has not said which customers were hit, and a spokesperson declined to elaborate beyond pointing to a fuller report to come.
Why the secrets matter more here than elsewhere
Environment variables are where teams park API keys, database strings and webhook signing secrets. Trigger is a platform for running durable TypeScript workflows and AI agents, promising retries, elastic scaling and tasks that survive redeploys and crashes. Credentials lifted from it can reach whatever the customer wired into those tasks.
The blast radius grows with the platform’s own feature set. Trigger recently added webhooks for Stripe, Supabase and Slack, so a stolen signing key or token may open doors beyond the workflow runtime itself. Listed customers include Emporio Armani, GovSignals and Cal.com, though none has been identified as affected.
What to do if you run workloads there
Treat every secret in the project as burned. Rotate provider keys, database credentials, webhook signing secrets and any tokens stored as build-time variables rather than only the ones flagged by the vendor. Review audit logs for the window before disclosure for unfamiliar deployments or triggered runs.
The longer-term answer is the one Trigger makes easy: the project is open source and self-hostable, which puts the secret store on infrastructure you already control. Teams that keep the hosted service should scope each credential narrowly enough that a leak cannot escalate.
