Trigger.dev Platform Breach: What Teams With Secrets in Trigger.dev Should Do Now

Status: Contained per the vendor. Trigger.dev says it has blocked the exploit, and its status page lists the incident as Resolved. The investigation is ongoing, and Trigger.dev says it will follow up with more details. Attribution: none published. Disclosed 1 November 2026: blog post at 22:33 UTC and status page entry at 22:50 UTC (2 November, 00:33 and 00:50 Cyprus/Nicosia time, UTC+2).

Executive Summary

Trigger.dev is a hosted platform that runs background jobs and AI agent workflows written in TypeScript. On 1 November 2026 it disclosed a security incident. CTO Eric Allam's security disclosure and the matching status page entry say four things:

Trigger.dev has blocked the exploit used in the attack.
Its investigation found exposure across a subset of organizations, not every customer.
For those organizations, the attacker gained unauthorized access to environment variables.
Trigger.dev has emailed all impacted account owners with steps to mitigate.

Trigger.dev has not published a root cause, an exposure window, the number of affected organizations or any indicators of compromise. A company spokesperson told The Register to wait for a full incident report. This advisory does not fill those gaps with guesses.

Environment variables on a platform like this usually hold credentials for other services: AI model providers, databases, cloud accounts, payment processors, messaging tools. So the practical risk sits with those other services. If your organization is in the affected subset, the most important step is to rotate every secret that was stored in Trigger.dev at the provider that issued it. Changing the value inside Trigger.dev alone is not enough, because the old key keeps working at its source until you revoke it there.

For third-party risk teams the questions are simple. Which of your suppliers run jobs or AI workflows on Trigger.dev? Were they notified? Have they rotated at the source?

What Happened

Trigger.dev's blog post is titled "Security Disclosure: Sunday November 1st." It is dated 1 November 2026 and signed by CTO Eric Allam. The page metadata gives a publication time of 22:33 UTC. The full text is short:

There has been a security incident at Trigger.dev. We've blocked the exploit used in this attack, but our investigation has identified exposure across a subset of organizations. The attacker gained unauthorized access to environment variables for these organizations. We have emailed all impacted account owners with steps to mitigate.

The same text appears on Trigger.dev's public status page. The entry is timestamped 1 November 2026 at 22:50 UTC, lists API as the affected service, is marked Resolved, and ends with "We will follow up with more details." When we checked again on 3 November at 08:13 Cyprus/Nicosia time (UTC+2), neither page had been updated.

The Register reported the incident on 2 November (16:44 UTC). According to The Register, Trigger.dev declined to give further details, and a company spokesperson told the outlet to wait for a full incident report. The Register also noted that Trigger.dev has not said which organizations were affected. Its article describes, as general context, how exposed credentials could be used against connected services. These are possibilities the outlet raises. Trigger.dev has not reported any of them.

What has not been disclosed:

How the attacker got in (no root cause or vulnerability published).
When access began or how long it lasted (no exposure window).
How many organizations or projects are in the affected subset.
Which variables were read, and whether variables marked as Secret were treated differently.
Whether any exposed credential has been misused.
Who was behind the attack.

We will update this advisory if Trigger.dev publishes the follow-up it has promised.

Technical Information

What "environment variables" means on Trigger.dev. According to Trigger.dev's environment variables documentation, each project stores variables per environment: local development, staging, preview and production. Tasks read them at runtime through process.env. In practice this is where teams put API keys and connection strings, so that background jobs can call model providers, databases, storage buckets, payment APIs and messaging tools.

A few documented details matter for scoping your response:

Secret-marked variables. A variable can be marked as a Secret when it is created. Its value is then hidden in the dashboard. That controls dashboard display. Trigger.dev has not said whether Secret-marked variables were in or out of scope in this incident, so do not assume they were spared.
Variables synced from elsewhere. Trigger.dev can pull secrets from other systems: a native Secret Sync with Infisical, the syncEnvVars build extension for any secrets manager, and a Vercel sync extension. The value in Trigger.dev is therefore often a copy of a secret that lives in your secrets manager or hosting platform. Rotating the copy does nothing if the original still works.
Programmatic access. Trigger.dev's SDK and REST API include functions to list, retrieve, create, update and delete environment variables. Any Trigger.dev API key or personal access token that can call those functions is a route to the same values. Some teams also keep the credentials of their own secrets manager (for example, a sync client ID and secret) as Trigger.dev variables. Put both kinds of credential on your review list.

Earlier advisories are not a root cause. Trigger.dev publishes GitHub security advisories for its open-source code. When we checked on 3 November, the most recent was dated 20 October 2026, and none mentions this incident. Trigger.dev has not linked the breach to any earlier advisory, so this post does not either.

What this is not. No CVE has been assigned or referenced for this incident, so there is no CVSS score or KEV listing to use. Treat it as a supplier incident that exposed credentials, not as a software vulnerability you patch.

Affected Product Versions

Affected: Trigger.dev's hosted cloud platform, for a subset of organizations that Trigger.dev has identified and emailed. The status page names the API service.
Not stated: the size of the subset, or which projects and environments inside an affected organization were exposed.
Self-hosted Trigger.dev: the disclosure does not mention self-hosted deployments, and no self-hosted release or patch has been tied to this incident. Nothing published so far suggests that self-hosted instances are affected. Because the vendor has not said so explicitly, confirm with your own team.
SDK, CLI and package versions: no version range has been published. This is a platform-side incident, not a vulnerable package you upgrade.

If your organization's Trigger.dev account owner did not receive an email, you are probably not in the affected subset. The disclosure does not give a way to confirm this independently. If you are unsure, ask Trigger.dev directly through its contact page.

Workaround and Mitigation

There is no patch for customers to apply. Trigger.dev says the exploit is already blocked on its side. The work for customers is credential hygiene.

If you received Trigger.dev's notification email:

Follow the vendor's email first. Those mitigation steps have not been published, and they may be specific to your organization.
List every secret that was stored in Trigger.dev, across all projects and all environments (dev, staging, preview, production). Include values synced from Vercel, Infisical or another secrets manager.
Rotate each secret at the provider that issued it. Revoke the old key at the AI model provider, cloud account, database, payment processor, email or messaging service, then issue a new one. Only after that, update the new value in Trigger.dev and in any secrets manager that syncs to it. A key replaced only inside Trigger.dev stays valid wherever it came from.
Rotate access paths into Trigger.dev too. Review and rotate Trigger.dev API keys and personal access tokens, plus any secrets-manager credentials you stored as Trigger.dev variables.
Order by impact. Start with credentials that can spend money or reach data quickly: AI provider keys, cloud and infrastructure keys, payment keys, database credentials, signing keys and webhook secrets.
Check provider-side logs for activity you do not recognize on the rotated credentials: new API usage, unexpected regions or IPs, new users or keys, spending spikes. Without a published window, start from when each secret was created or last rotated.

If you did not receive an email: you are probably out of scope. Using this incident as a reason to review what you keep in Trigger.dev is still sensible, and rotating your highest-value keys at the source is low-cost insurance.

For everyone: subscribe to Trigger.dev's status page for the follow-up, and enable multi-factor authentication on Trigger.dev accounts. Trigger.dev's security page says MFA is supported.

Indicators of Compromise

Trigger.dev has not published any indicators of compromise. There are no IP addresses, user agents, request patterns or timestamps for customers to search for, and we will not invent any.

Until the vendor publishes specifics, use your own providers' logs and look for:

API calls made with a rotated credential after you revoked it (these will fail, but they show that someone is trying).
Usage of AI provider, cloud or payment keys from sources outside your normal job infrastructure.
New keys, users, webhooks or OAuth grants that nobody on your team created in the services those secrets unlock.

These are general signs that a credential was misused. They are not indicators Trigger.dev has published for this incident.

What to Do With This Vendor Today (TPRM)

Trigger.dev is a dependency of your suppliers as much as of your own engineers. Product teams use it to run background jobs and AI agents. Those jobs need keys to your vendors' databases, AI providers, cloud accounts and, sometimes, to systems that hold your data. A supplier that stored those keys in Trigger.dev may now hold credentials that were exposed, even though the supplier itself was not breached.

Send these questions to software and SaaS suppliers that run background jobs, scheduled tasks or AI workflows for you:

Do you use Trigger.dev, directly or through a subcontractor, for anything that touches our data or our integrations? If so, is it the hosted cloud platform or a self-hosted deployment?
Did your Trigger.dev account owner receive the 1 November 2026 incident email? A plain yes or no is enough to triage.
If yes, which secrets were stored there, and have they been rotated at the issuing provider? Ask for confirmation that the old credentials were revoked at the source, not just replaced in Trigger.dev, and whether any of them grant access to our tenant, API or data.
Have you reviewed provider-side logs for those credentials, and have you found anything? Ask them to commit to telling you if Trigger.dev's follow-up report changes the scope.
Does your contract or incident policy cover breaches at your subprocessors? Check whether Trigger.dev is on their subprocessor list, and what notification timeline they commit to when a subprocessor reports exposure.

Where you are the Trigger.dev customer, apply the same questions internally and record the answers next to the supplier record.

Our platform validates vendor claims against live attack-surface signal and chases findings to closure under your approval.

Need help working through background-job / AI-workflow SaaS suppliers that may have stored environment secrets in Trigger.dev? Our team can help you prioritize them and track their answers. Talk to an expert

Sources

Trigger.dev, "Security Disclosure: Sunday November 1st" (1 Nov 2026): https://trigger.dev/blog/security-incident-nov-2026
Trigger.dev status page, incident 1110434: https://status.trigger.dev/incident/1110434
Trigger.dev status page, incident history: https://status.trigger.dev/incidents
Trigger.dev docs, Environment Variables: https://trigger.dev/docs/deploy-environment-variables
Trigger.dev docs, Self-hosting overview: https://trigger.dev/docs/self-hosting/overview
Trigger.dev security page: https://trigger.dev/security
Trigger.dev GitHub security advisories: https://github.com/triggerdotdev/trigger.dev/security/advisories
The Register, "Thieves pilfer environment variables from Trigger AI workflow tool" (2 Nov 2026): https://www.theregister.com/security/2026/11/02/cloud-hosted-ai-workflow-tool-has-environment-variables-snatched-in-security-incident/5306998