Trigger.dev suffers security incident, exposes customer environment variables

What Trigger.dev confirmed

On Sunday, November 1, 2026, Trigger.dev published a security advisory confirming an incident on the platform. According to the advisory, an attacker gained unauthorized access to environment variables belonging to a subset of customer organizations. The company says it has blocked the exploit used in the attack and states that the investigation has already identified which accounts were exposed.

Owners of affected accounts have already received an email with mitigation instructions, according to the official statement. The company promises to post updates on its status page as the investigation progresses, and says it is available for anyone with questions.

Trigger.dev has not publicly disclosed how many organizations were affected, nor how the attacker obtained initial access. There is also, as of now, no technical post-mortem detailing the attack vector or the exposure window.

Why environment variables are the most valuable target

In job orchestration platforms, environment variables concentrate exactly the kind of data an attacker wants most: API keys from payment providers, tokens for third-party services, database connection strings, and secrets used to validate webhook signatures.

A leak at this level rarely stays confined to the originating platform. It becomes a gateway into any system connected through those credentials, from payment gateways to AI providers. That's why incidents involving .env files or secret vaults are costly even when the attacker never touches the direct victim's own code or database.

For those building with task queues and automations, the risk is even more concentrated. This kind of pipeline tends to bring together, in a single place, integrations with several external APIs at once: Stripe, transactional email services, AI model providers, managed databases. All of that typically lives as a project environment variable within the orchestration platform itself.

What Trigger.dev is, for those who don't use it

Trigger.dev is an open source platform for orchestrating background jobs in TypeScript and Node.js applications: long-running task queues, scheduling, automations, and AI agent orchestration, with an SDK embedded directly in the application code. It's a popular product among startups and small teams precisely because it removes from the product team the complexity of maintaining their own queue and worker infrastructure.

This type of managed service, by definition, handles third-party credentials all the time: storing and injecting secrets into jobs is part of the value the platform delivers. It is also, for that reason, a high-value target for anyone seeking lateral access to other systems.

What remains unclear

As of this article's publication, Trigger.dev had not disclosed:

• The exact attack vector used to exploit the platform.
• How long the attacker had access before the exploit was blocked.
• The number or proportion of customer organizations affected.
• Whether the data was merely accessed or also extracted (exfiltrated) by the attacker.
• The content of the mitigation instructions sent by email to affected users.

This kind of gap is common in initial disclosures: the priority is containing the problem and directly notifying those affected, before publishing a full post-mortem. Anyone maintaining projects on Trigger.dev will only know for certain whether they were affected by checking the email registered to their account, not through the public statement.

What to do now if you run jobs on Trigger.dev

Even without having received direct notice from the company, the safest path for anyone maintaining projects on the platform is to treat the leak as if their own credentials could be compromised:

• Check the email registered as the account owner's: that's how Trigger.dev is notifying those affected.
• Rotate every credential configured as an environment variable in your Trigger.dev projects: API keys, database connection strings, webhook tokens, and secrets for payment and AI providers.
• Audit the logs of connected services for anomalous usage: out-of-pattern calls, unrecognized IP origins, usage spikes outside the normal operating window.
• When reconfiguring integrations, prefer tokens with minimal scope and short expiration, instead of recreating keys with the same broad privileges as before.
• Follow Trigger.dev's status page for updates on the actual scope of the incident.

None of these measures depend on official confirmation that a specific account was affected. Rotating secrets as a precaution costs a few minutes; finding out later that a leaked key turned into fraud in production costs far more.

What this changes about where to keep secrets

Episodes like this one reignite an old architecture debate: how much it's worth concentrating production secrets inside a third-party platform, however convenient the SDK may be. A common alternative is to keep secrets in a dedicated vault (such as Vault, AWS Secrets Manager, or an equivalent service) and inject only what's needed, at runtime, into the orchestration platforms.

Separating secrets by environment (development, staging, production) and automatically rotating credentials on short cycles reduces the damage of an incident like this, even when it happens. It's an extra layer of configuration work, but the Trigger.dev incident is a concrete reminder that no automation platform is immune to this, and that the backup plan matters just as much as the tool chosen.