Short answer
Trigger.dev said on 1 November 2026 that an attacker gained unauthorized access to environment variables for a subset of organizations. It says the exploit has been blocked and that affected account owners were emailed, but it has not given a count, a root cause or a time window.
If you think your details were included, start with our checklist on what to do after a data breach.
Key facts
| Organization | Trigger.dev |
|---|---|
| Incident type | Data breach |
| Status | Confirmed by the organization |
| Sector | Developer platform and workflow automation |
| Country | Not stated in the notice |
| Disclosed | 2026-11-01 |
| People or records affected | A subset of organizations. Trigger.dev has not said how many |
What data was exposed
- Environment variables for a subset of customer organizations
- Any API keys, database credentials or tokens that customers stored in those variables
What happened
Trigger.dev, a cloud platform for building background jobs and AI agent workflows, disclosed a security incident in a post dated 1 November 2026. It says an attacker gained unauthorized access to environment variables for a subset of organizations, that the exploit has been blocked, and that impacted account owners were emailed with steps to take. The Register reported the disclosure on 2 November.
What is not known
Both the company post and the press report leave key questions open. Trigger.dev has not said how many organizations were affected, who they are, what the exploit was, or when the attacker first got in. When The Register asked for more information, the company declined and told the reporter to wait for a full incident report. Trigger.dev pointed readers to a status page incident that it said it would update.
Why environment variables matter
Developers often keep API keys, database passwords and service tokens in environment variables, so a platform that runs your jobs usually holds them. The Register notes that stolen variables could let an attacker reach connected services. It also notes that features such as automated retries, elastic scaling and webhooks for services like Stripe, Supabase and Slack could widen the effect. The article lists several well-known customers but does not say any of them were affected, and we do not suggest they were.
What to do
Without a published list of exposed variables, the safest reading is to rotate the secrets you stored on the platform. Prioritize anything that can spend money or read customer data. Then check provider logs for use you did not make.
If you were emailed, check the message came from Trigger.dev by opening the dashboard yourself. Attackers like to copy breach notices.
For the general steps, see our data breach checklist and the guide to phishing messages. Similar notices were issued by Railway and Northflank in recent weeks.
Scams to watch for after this breach
Criminals use breach news as cover. Expect messages that mention the incident, quote real details, or offer help.
- Emails posing as Trigger.dev that tell you to log in or paste keys into a form to 'check exposure'.
- Charges on AI, payment or cloud accounts made with stolen keys, followed by fake refund contacts.
- Extortion messages that cite a leaked credential to pressure you into paying.
What to do if you are affected
- 01Rotate every secret you stored as a Trigger.dev environment variable, starting with payment, database and AI provider keys.
- 02Rotate your Trigger.dev API keys and personal access tokens.
- 03Check provider billing and audit logs for use you do not recognize and contact the provider directly if you find any.
- 04Use the mitigation steps in the email sent to account owners, and verify that email by going to Trigger.dev yourself instead of using its links.
- 05Watch the Trigger.dev status page for the full incident report it has promised.
Frequently asked questions
How many Trigger.dev customers were affected?
Unknown. Trigger.dev says only a subset of organizations was affected and has not given a number. The Register asked for more detail and was told to wait for a full incident report.
Was the attack stopped?
Trigger.dev says the exploit used in the attack has been blocked. It has not described the exploit or when the attacker first gained access.
Do I have to rotate my secrets if I was not emailed?
Trigger.dev has not said that unaffected organizations are safe from every exposure. Rotating secrets stored as environment variables is a low-cost precaution until the full report arrives.
Can I self-host instead?
The Register notes that Trigger.dev is open source and can be self-hosted, which some organizations may consider. That is a choice about risk, not a fix for this incident.
Sources
- Trigger.dev customer environment variables exposed, Trigger.dev, 2026-11-01
- Trigger.dev discloses security incident, The Register, 2026-11-02
This post summarises public reporting as of 2026-11-06. Details of live incidents change; we update posts when the organization or regulators publish new facts. Spot an error? See our editorial and corrections policy.