For: developers and teams that run tasks or jobs on Trigger.dev and keep API keys, database connection details or cloud credentials in their environments. This article is based on Trigger.dev's blog posts and status page, and does not cover attack techniques.
Follow-up published: this article is updated as the organisation publishes more
- Who is affected
developers and teams that run tasks or jobs on Trigger.dev and keep API keys, database connection details or cloud credentials in their environments.
- Confirmed so farSee the table ↓
- Share of customers affected
- Root API keys
- Environment variables
1 more
- Lists and metadata of runs, deployments and schedules
- Not yet confirmed
- The attack vector (the company is withholding it to protect the investigation and customers)
- When the unauthorized access began and for how long
- The actual number of affected customers
1 more
- Whether the obtained information was actually misused
- What to do nowSee the steps ↓
- Check for a notification: both the email and the dashboard banner
- If affected, regenerate your Trigger.dev API keys
- If affected, rotate the credentials in the environment
3 more
- Check usage, logs and billing at the issuers
- Redeploy with the new values and confirm your tasks run
- Set spend limits and split keys into small ones
- Where to verify (source)All sources ↓
- Trigger.dev, blog, incident report (November 6, 2026)
- Last checked
- As of November 7, 2026 (JST)
Follow-up plans and what we checked
The company published a report on November 6. It covers the attacker being blocked, the share of customers affected, what was obtained and what customers should do. It says it will share the attack vector when it can do so responsibly. When we checked on November 7, 2026 (JST), no further update had been posted.
What Trigger.dev users should do today
Check for a notification: both the email and the dashboard banner
The company says affected customers were emailed on November 1 (about 21:36 UTC) and November 2 (20:27 UTC), and see a notification banner in the dashboard. First check whether your organization's owner received the email, including the spam folder, and whether the dashboard shows a banner.
The company says customers who received no impact notification were not affected. If you are not sure, it asks you to write to help@trigger.dev from your account email address, and says support for this incident is prioritized.
If affected, regenerate your Trigger.dev API keys
The company says the attacker obtained root API keys, and it has revoked the potentially impacted keys for affected environments. Instructions for regenerating them were emailed to affected customers. If CI or an app still uses an old key, replace it with the new one.
The company has released IP restrictions for scoped API keys and OIDC support. Use them when you reissue keys, if they fit your setup.
If affected, rotate the credentials in the environment
This covers database passwords, third-party API keys, access tokens and similar items in the affected environment. Do it in this order: revoke the old credential at the issuing service (AI provider, cloud, database, payment, email), create a new one, set it in Trigger.dev and redeploy. Editing or deleting a variable in Trigger.dev does not stop a copy someone already has.
The company says environment variables are stored encrypted at rest and decrypted just in time for run execution. But a root key gives full access to an environment's settings, including its environment variables, so it is safest to treat those in an affected environment as taken.
Check usage, logs and billing at the issuers
In the sources we read, the company does not state when the unauthorized access began, so, as this site's rule of thumb, look back at least to late October and keep the window wide. At each issuing service, open usage, access logs, the key list and billing for requests you do not recognise, unusual models or regions, and a sudden rise in cost.
For databases, also look for connections from unfamiliar sources and jobs you do not normally run. If you find suspicious use, report it to the issuer and replace the other secrets in that environment too.
Redeploy with the new values and confirm your tasks run
After setting the new values, redeploy and confirm that running and scheduled tasks work with them. Because the old keys are now revoked, a missed variable makes a task fail. Use the failures to find which variable is still stale.
Set spend limits and split keys into small ones
At AI providers and clouds, set a monthly budget cap and an alert. Give each key one purpose and the narrowest permissions, and use separate keys per app and per environment. A smaller key limits what a leak costs. For the basics of keeping keys out of code and logs, see what's actually dangerous about .env and API keys.
What happened (from Trigger.dev's announcements)
The following is based on the company's November 6 report, its November 1 blog post and the status page entry. The November 6 report was published as a follow-up to the first disclosure.
November 1
The company becomes aware of the incident. Infrastructure alerts flag anomalous activity; it judges it malicious, blocks the attacker and mitigates the attack vector. First disclosure on the blog.November 1, about 21:36 UTC
First email to affected customers.November 1, 22:50 UTC
The status page entry with the same title is created.November 2, 20:27 UTC
Second email to affected customers.November 6, 12:27 UTC
The status page entry is marked "Resolved" and links to the November 6 report.November 6
The company publishes a fuller report: 0.66% of customers affected, root API keys obtained, what was returned, and what customers should do.November 7
This site rechecks. No further update has been posted.
What the company says
0.66% of customers. Root API keys obtained, environment variables accessed, run, deployment and schedule data returned
Not stated
The attack vector (withheld), start date, actual customer count, whether it was misused
If affected: regenerate API keys, then revoke and replace the environment's credentials at the issuers.
- Impact
- 0.66% of all customers. The attacker obtained root API keys for some customer environments and accessed their environment variables
- What was returned
- In some environments, lists of recent runs, deployments and schedules: IDs, task names, run idempotency keys, run status, tags, deployment metadata and errors, schedule external IDs and run metadata
- Not found
- No evidence that other customer data, other services, its own production databases or customer dashboard accounts were accessed (company)
- Company response
- Blocked the attacker and mitigated the vector, rotated internal credentials as a precaution, reviewed logs, notified affected customers, revoked potentially impacted API keys, applied risk-based automated account restrictions, engaged incident response experts, notified law enforcement
- Not disclosed
- The attack vector (to protect the investigation and customers), start date, actual customer count, whether anything was misused
What is known and what is not
The state as of November 7, 2026 (JST). Items marked "not stated" are not in the company's report as we read it; they are not confirmed as safe.
| Item | What the company says | Status |
|---|---|---|
| Share of customers affected | 0.66% of all customers | Confirmed (company) |
| Root API keys | Obtained by the attacker for some customer environments | Leak confirmed (company) |
| Environment variables | The attacker gained unauthorized access | Affected (company) |
| Lists and metadata of runs, deployments and schedules | Returned in some environments | Leak confirmed (company) |
| Other customer data, other services, its own production databases, dashboard accounts | No evidence they were accessed | Not confirmed (company) |
| Webhook signing secrets | Not exposed | Not included (company) |
| Self-hosted deployments | Not impacted | Not included (company) |
| Customers with no notification | Not affected | Company statement |
| The attack vector | Withheld to protect the investigation and customers; to be shared when it can be done responsibly | Under investigation (withheld by company) |
| When the access began and for how long | Not stated in the report as we read it | Not stated |
| Actual number of affected customers | Share only (0.66%) | Not stated |
| Misuse of the obtained information | Not stated | Not stated |
How to read this: whether the credentials in the variables were used is still unknown
The company separates what was obtained from what it has no evidence was accessed. It does not say whether credentials kept in the environment variables were actually used. If you were affected, do not wait for confirmation that they were not; revoke them at the issuer first.
What access to environment variables can lead to
In general, secrets accessed in environment variables can be misused as follows. This does not mean all of it has happened here.
- AI service API keys: someone else sends requests on your account and you receive the bill, or the key is resold
- Database passwords and connection strings: reading or changing your app's data, including your own users' records
- Cloud and payment keys: creating resources or making calls that cost money
- Signing keys: accepting forged requests, or forging sessions
The run and deployment metadata that was returned here (task names, tags, errors) is not a secret in itself, but it hints at which services you use and how. That can be used to craft targeted, convincing messages.
A background-job platform holds, by its nature, the credentials for many outside services in one place. If the variables of one platform are seen, keys for several services can be at risk at once. For other cases involving environment variables and secrets, see Northflank, Zeabur and Railway. They are separate cases, and none has been confirmed to share a cause with this one.
For operators: lessons from what the company disclosed
These points come from the facts the company published. They are not a further judgement of Trigger.dev.
- A near-root key reaches the whole environment's settings. The company says obtaining root API keys gave access to environment variables. Split platform keys by purpose, and use the narrowing options the company has released, such as IP restrictions and OIDC, where you can.
- Notices arrive by email and in the dashboard. Make the owner address a shared mailbox that still works when a person leaves, keep it out of spam filtering, and check the dashboard banner regularly.
- Keep secrets you hand to a platform quick to replace. Decide per issuer how to revoke and reissue, and split keys by environment and purpose, so you can act on the day a notice arrives.
- Give variable-held secrets the narrowest permissions. If a platform's variables are seen, the damage depends on what each key can do.
Sources (public records)
The facts in this article are based on the public information below. The attack vector and cause, which the company has not disclosed, are not speculated about.
- Trigger.dev, blog, incident report (November 6, 2026) — trigger.dev/blog/security-incident-report-nov-2026
- Trigger.dev, blog, "Security Disclosure: Sunday November 1st" (November 1, 2026) — trigger.dev/blog/security-incident-nov-2026
- Trigger.dev, status page, "Security Disclosure: Sunday November 1st" (created November 1, 2026, 22:50 UTC; marked resolved November 6, 12:27 UTC, with a link to the November 6 report) — status.trigger.dev/incident/1110434
Update history
2026-11-07: Added the company's November 6 report: 0.66% of customers affected, root API keys and environment variables obtained, run, deployment and schedule data returned, attack vector withheld. The steps now centre on checking for a notification (email and dashboard banner), regenerating API keys and rotating the environment's credentials; added that webhook signing secrets were not exposed and self-hosted deployments were not impacted. 2026-11-05: First version. Based on Trigger.dev's blog and status page as of November 5, 2026.
Read next
- Other incidents involving environment variables and secrets: Northflank security incident / Railway environment variables possibly exposed / Zeabur security incident
- A newer developer-platform case: unauthorized access to Chainstack production systems / OpenCode Console breach
- Keeping keys safe: what's actually dangerous about .env and API keys / stolen API keys and account bans
- Other 2026 incidents: Data breaches and cyberattacks of 2026