Trigger.dev env vars exposed (Nov 1): what to rotate, and where

What Trigger.dev has said (Nov 1)

• From the CTO's disclosure: "We've blocked the exploit used in this attack, but our investigation has identified exposure across a subset of organizations." Account owners of the impacted organizations were emailed with mitigation steps. If you own a Trigger.dev organization, check that inbox (and its spam folder) first. The email is the only place Trigger.dev has put organization-specific steps.
• It hasn't said how the attacker got in, when access started, which variables were read, or whether anything other than environment variables was involved. Wiz added Trigger.dev (Nov 1) to its "Black October" list of AI developer platform incidents and notes it hasn't shared any TTPs or IOCs yet.
• Until Trigger.dev says more, treat every variable stored in an impacted organization as read, in every environment: dev, staging, preview and prod each hold their own values.

Before you revoke: pull the logs

Export each AI and cloud provider's usage and billing for the last few weeks while you still know which key was which. Railway and Zeabur both said in October that they won't cover spend run up with leaked keys and pointed customers to the provider, and the provider will ask for usage records. Then revoke.

Secret values can't be read back. Trigger.dev's docs say variables marked Secret "are hidden in the dashboard and cannot be viewed after creation", so use the key names on the Environment Variables page and each provider's dashboard to work out which key is which.

An order that matches the risk

Trigger.dev hasn't published an order. This one is ours, built from what attackers this month went after: AI keys first. For each key: revoke it at the provider, create a replacement, and put the new value wherever it is managed (next section).

1. AI provider keys. OpenAI, Anthropic, OpenRouter and similar. Wiz describes the October attacks on these platforms as hunting stored environment variables, with a focus on those granting AI access. Revoke in each provider's dashboard, create a new key, and set a spend limit where the provider offers one.

2. Cloud provider credentials. AWS access keys, GCP service account keys (including a base64-encoded credentials JSON, the pattern Trigger.dev's docs show for Google). Create the replacement, deploy it, deactivate the old one, and check the cloud account's audit log (CloudTrail on AWS) for calls made with it.

3. Payment keys. A Stripe secret key can create charges, issue refunds and read customer data; roll it with the shortest expiry you can deploy within, as in rotating a leaked Stripe key without breaking webhooks. Afterwards, a read-only scan such as Stripe Leak Check flags card-testing bursts, fraud warnings you can still refund and disabled webhook endpoints, and it needs only a read-only restricted key, not the secret key you just replaced.

4. Database credentials. Change the password in the database itself (or with your database host's reset), then the connection string. If the database holds your users' sessions or tokens, revoke those too.

5. Credentials for the services that feed Trigger.dev. If you stored a Vercel access token, an Infisical client secret or a GitHub token as a Trigger.dev variable, rotate it: whoever has it can read the source of all your other secrets.

6. Everything else in the list. Webhook signing secrets, email and SMS API keys, analytics, error tracking, storage.

Want us to run it for you? The Ship Check Audit lists every key that ever left your server and confirms each old value now gets a 401 or 403: $149, within 48 hours.

Where to put the new value

From Trigger.dev's environment variable and Vercel integration docs. Variables, in the docs' words, "are fetched and injected before a runs begins."

• Typed into the dashboard: edit the value on the Environment Variables page. Editing is "being enabled gradually and may not be available for your organization yet"; without it, you delete the variable and create it again. Trigger.dev warns that deleting one "can cause runs to fail that are expecting variables to be set", so recreate it straight away. Secret-marked variables have to be recreated as Secret: the setting can only be chosen at creation.
• Infisical Secret Sync: rotate the secret in Infisical. Per the docs, the sync updates the matching Trigger.dev variable "and your tasks pick up the new value on their next run." Editing it only in Trigger.dev doesn't change it in Infisical.
• syncEnvVars build extension (Infisical, dotenvx, any secrets manager): the values are resolved at deploy time. Trigger.dev: "you need to redeploy your Trigger.dev tasks if you change the environment variables in Infisical." Rotate at the source, then run the deploy again.
• Vercel integration: it pulls variables from Vercel before each build. The docs: "To sync updated values into Trigger.dev, trigger a new Vercel deployment." Rotate in Vercel, update the value there, and redeploy. If "Pull env vars before build" is off for an environment, update the Trigger.dev value by hand too.
• Local development reads .env, .env.development, .env.local, .env.development.local and dev.vars. A dev value stored on the dashboard is still a stored value: rotate it if it was a real key.

Then check that the old values are dead

1. Test each old value directly. 401 means revoked:

   curl -s -o /dev/null -w "%{http_code}\n" \
     https://api.openai.com/v1/models \
     -H "Authorization: Bearer $OLD_OPENAI_API_KEY"
   
   curl -s -o /dev/null -w "%{http_code}\n" \
     https://api.stripe.com/v1/balance -u "$OLD_STRIPE_KEY:"

2. Trigger a test run of a task that uses each rotated key and confirm it succeeds with the new value.

3. Read each provider's usage for calls you didn't make, as far back as its logs go: Trigger.dev hasn't said when the attacker's access began.

Not the only one

Wiz now counts twelve publicly reported incidents at AI developer platforms since early October (edit of Nov 3, 15:40 UTC); Chainstack (Oct 29–31) is the latest. Black October: every AI dev platform breach in one list has all twelve. If you also hosted on one of the others, see Railway env var disclosure: what to rotate, Northflank breach: what to rotate and Zeabur is shutting down. A key you rotated after one of those and then stored on Trigger.dev needs rotating again.