Trigger.dev Environment Variables Exposed: Check, Rotate, Harden

On November 1, 2026, Trigger.dev disclosed that an attacker gained unauthorized access to environment variables belonging to "a subset of organizations" on its cloud platform. The company says it has blocked the exploit and emailed the owners of affected accounts. If you run background jobs or AI agents on Trigger.dev Cloud, treat every secret stored there as possibly exposed until you have confirmed otherwise. Then rotate the secrets in order of blast radius and check upstream providers for misuse.

Trigger.dev has published very little so far. This guide separates what is confirmed from what isn't, then gives a step-by-step response plan based on how Trigger.dev actually handles environment variables and API keys.

What Trigger.dev has confirmed so far

The public record is short. Trigger.dev's security disclosure and the matching status page entry say three things:

• The company has "blocked the exploit used in this attack."
• Its investigation found exposure across a subset of organizations, and the attacker "gained unauthorized access to environment variables for these organizations."
• All impacted account owners were emailed with mitigation steps, and more details will follow.

The status entry lists the affected component as the API. It was marked resolved at 10:50pm UTC on November 1, 2026, and as of November 2 it had no further updates. RuntimeWire reports that CTO Eric Allam confirmed on X that owners of affected accounts had been emailed.

What is still unknown

The quick "resolved" status drew criticism. In a summary of the Hacker News discussion, most of the roughly 70 comments said it was premature, and one asked what "blocked the exploit" actually means. Commenters also pointed out the core problem: the vendor can patch its platform, but only customers can rotate the third-party keys that leaked. One commenter speculated about a link to a vulnerability patched by another hosting provider. Trigger.dev hasn't confirmed this, so treat it as rumour.

Why leaked environment variables on a job platform are serious

Trigger.dev runs long-running background tasks: webhook processing, scheduled syncs, AI agent workflows, email sends, and so on. Those tasks need credentials, so a typical project's environment variables include:

• LLM provider keys (OpenAI, Anthropic, Google)
• Database connection strings, often with the password embedded in a DATABASE_URL
• Payment, email and messaging API keys (Stripe, Resend, Twilio, Slack)
• Cloud credentials (AWS access keys, GCP service account JSON)
• OAuth client secrets and webhook signing secrets

Unlike a leaked frontend config, these are server-side secrets with write access to production systems. A leaked LLM key gets you a surprise invoice. A leaked database URL or cloud key can mean data theft. For the billing side, LaunchBoosts has a separate guide on hard budget caps for cloud and LLM APIs, which limits the damage while you rotate.

Step-by-step: what to do now

1. Confirm whether you were notified

Trigger.dev emailed the account owners of affected organizations. Check the owner's inbox, including spam and any shared aliases, for a message from November 1–2. If the owner is a departed co-founder or a personal address, find that out now. If you can't confirm either way, ask Trigger.dev through its contact page. Until you have a definitive answer, act as if you were affected.

2. Build a complete inventory

List every variable in every Trigger.dev project and environment. The environment variables docs describe separate values for development, staging, production and preview, and the SDK's envvars.list call can export names programmatically. Watch out for two things:

• Secret variables can't be read back. Trigger.dev hides values marked secret once they are created, so you'll need your own records or upstream sources to know what each one contains.
• Synced variables come from elsewhere. If you use the syncEnvVars build extension, the Vercel integration or Infisical, the source of truth sits in another system. Rotate there.

Also check for credentials hiding in _URL variables, and for "test" or "dev" variables that actually point at production. The webvise playbook from the April 2026 Vercel breach calls these out as commonly missed.

3. Rotate in order of blast radius

Rotate the credentials that can do the most damage first:

1. Cloud provider and infrastructure keys (AWS, GCP, Azure, Kubernetes tokens)
2. Database credentials and connection strings
3. Payment and financial APIs (Stripe secret keys, banking APIs)
4. Keys that can send on your behalf (email, SMS, Slack bots, social APIs)
5. LLM and other metered APIs
6. Webhook signing secrets and OAuth client secrets
7. Trigger.dev's own API keys, if any are stored in other systems' environment variables

For each one, create the new credential, update it everywhere it's used, then revoke the old one. Trigger.dev's API key docs recommend this same order for its own keys, because revoking first breaks running integrations. Revocation in Trigger.dev is immediate and irreversible, and a new key's full value is shown only once.

4. Make sure running tasks actually pick up new values

Whether you need a redeploy depends on how the variable gets to Trigger.dev:

All of this comes from Trigger.dev's environment variable documentation. When in doubt, redeploy every environment after rotating. It's cheap, and it removes the guesswork. The same applies to other places you rotated, such as Vercel, where deployed builds keep old values until redeployed.

5. Mind tokens that outlive revocation

Revoking a Trigger.dev API key does not invalidate public access tokens it already created. They stay valid until their own expiry, per the docs. Removing a team member also doesn't revoke the keys they created. If you issue long-lived public access tokens to frontends, factor that window into your exposure assessment.

6. Hunt for misuse upstream

Rotation stops future abuse. It doesn't tell you whether a key was already used. For each high-value credential, check the provider's own logs:

• Cloud: CloudTrail or audit logs for unfamiliar IPs, new IAM users, new access keys or unusual regions
• Database: connection logs from unknown hosts, unexpected bulk reads or exports
• Stripe and payments: new API keys, webhook endpoints, payouts or refunds you didn't create
• Email and SMS: send volume spikes, new sender domains
• LLM providers: usage dashboards for spikes, especially on models you don't use

Since Trigger.dev hasn't said when access began, look back at least a few weeks, not just to November 1.

Don't confuse this with two earlier Trigger.dev issues

Two other October 2026 issues are showing up in search results. Neither has been publicly linked to the November 1 incident.

• CLI debug log leak (GHSA-fj2x-mqqp-3v2w). A security advisory dated October 2, 2026 found that trigger.dev deploy --dry-run --log-level debug printed plaintext secret values in CLI versions before 4.5.9. It's rated medium (CVSS 5.5). The leak is local to wherever those logs end up, such as CI logs. Upgrade to 4.5.9 or later, and if you ran debug dry-runs in CI, scrub or expire those logs.
• Vercel sync wipe (October 6, 2026). Trigger.dev's incident report explains that a sync bug overwrote variables with empty strings for 121 organizations between 12:21 and 15:10 UTC. That was an availability problem, not an exposure. Its lesson still applies: after a bulk rotation, verify that values are correct and non-empty before assuming your tasks are healthy.

Longer-term: reduce what a vendor breach can leak

This is the second major platform incident of 2026 involving customer environment variables, after the Vercel breach disclosed on April 19. That pattern argues for designing on the assumption that any platform holding your secrets can leak them.

• Store references, not secrets. Keep long-lived credentials in a dedicated secrets manager and fetch them at runtime with a narrowly scoped identity. Then the platform holds one bootstrap credential instead of twenty.
• Prefer short-lived credentials. Use OIDC federation or short-TTL tokens for cloud access wherever the provider supports it.
• Scope every key. Use restricted Stripe keys, read-only database users for read-only tasks, and per-project LLM keys with spend caps. On paid plans, Trigger.dev's own API keys support access presets narrower than "No restrictions" per its docs.
• Separate environments for real. Never reuse production credentials in staging or preview.
• Write the rotation runbook now. A one-page list of every secret, its owner, where it lives and how to rotate it turns a lost weekend into an hour of work.
• Weigh self-hosting honestly. Trigger.dev supports self-hosting with Docker Compose or Kubernetes. You give up Cloud-only features such as warm starts, auto-scaling and checkpoints, and you take on security and uptime yourself. Self-hosting moves the risk rather than removing it.

If you're comparing background job and workflow platforms after this, the AI coding and developer tools directory is a place to start shortlisting. Ask any vendor for its incident history and how it encrypts environment variables at rest.

What to watch next

• Trigger.dev's follow-up. The company has promised more details. Watch for the root cause, the time window and whether secret-flagged variables were readable. Those answers set how far back you need to audit.
• Status page updates at status.trigger.dev. An incident marked resolved can still gain new updates.
• Unusual activity on rotated providers over the next few weeks. Attackers sometimes sit on stolen keys before using them.

For today: confirm notification, inventory, rotate the high-impact credentials first, redeploy and review provider logs. If you were affected and haven't started, start with your cloud and database credentials.