# Trigger.dev breach exposed environment variables: what to rotate > An attacker read secrets stored by some Trigger.dev customers. Any API key your jobs use there should be replaced at the provider that issued it. - Published: 2026-11-02 - Author: 28creation Desk - Format: News - URL: https://28creation.com/articles/trigger-dev-environment-variables-breach/ ## The short read **An attacker read the environment variables of some Trigger.dev customers, the place background jobs keep their API keys.** - Trigger.dev disclosed it on November 1 and says the exploit is blocked. It has not said how many organizations were hit or how. ### What you can do with this > If your jobs run on Trigger.dev, revoke each key stored there with the service that issued it, then check its usage logs. In two cases Wiz traced, stolen keys sat idle for days before abuse. --- Trigger.dev runs background jobs and AI agents for developers. On November 1, [in a post by CTO Eric Allam](https://trigger.dev/blog/security-incident-nov-2026), it said an attacker "gained unauthorized access to environment variables" for a subset of customer organizations. The company says it blocked the exploit and emailed the owners of affected accounts with steps to mitigate. Environment variables are where Trigger.dev tasks keep the API keys and credentials they depend on, as Runtime Wire notes. If your team runs jobs there, treat those keys as the thing at risk, whether or not you got the email. ## What Trigger.dev has said, and what it has not The disclosure is short, and the same statement appears on [Trigger.dev's status page](https://status.trigger.dev/incident/1110434?mp=true). That page lists the API as the affected service and shows the incident as resolved at 10:50 p.m. UTC on November 1. The company says it "will follow up with more details." It has not said how many organizations were affected or how the attacker got in. [Runtime Wire](https://runtimewire.com/article/trigger-dev-environment-variables-security-incident-november-2026) reported the post at 01:26 UTC on November 2 and also notes that the count is unknown. On [Hacker News](https://news.ycombinator.com/item?id=50331784), two commenters questioned the "resolved" label while the scope is still open. ## Why environment variables keep getting hit Trigger.dev deploys and scales your tasks, so "any environment variables you use in your tasks need to be accessible to us," [its documentation says](https://trigger.dev/docs/deploy-environment-variables). A platform that runs your code must be able to read your secrets. That makes such platforms a target. Two days earlier, [Wiz counted nine AI developer platforms](https://www.wiz.io/blog/black-october-for-ai-developer-platforms) that disclosed incidents in October, from Fireworks AI on October 6 to Northflank on October 30. In every public report, Wiz wrote, attackers were "explicitly hunting stored environment variables." Trigger.dev is not on that list, and nothing public yet ties this breach to the campaign. The Northflank case holds the useful lesson. [As we reported](/articles/northflank-ninth-ai-platform-breach-october/), in two cases Wiz traced, stolen keys sat nearly idle for days before heavy abuse began. That gap is the window to act in. One separate flaw is worth knowing. [CVE-2026-114069](https://www.vulncheck.com/advisories/trigger-dev-before-4.6.0-root-secret-disclosure-via-envvars-api-endpoint), dated October 20 and rated 8.6 under CVSS 4.0, affects Trigger.dev before 4.6.0. It let a holder of a restricted `read:envvars` key pull an environment's root secret key and plaintext secrets. Trigger.dev has not named it as the cause of this incident, so we do not either. ## What to do now 1. **Read the email, then rotate anyway.** Affected owners were emailed; if you are unsure whether you were one, rotate everything stored in your deployed Trigger.dev environments. 2. **Revoke at the source.** Create a new key with the service that issued each secret, such as your AI provider. Update it in the Trigger.dev dashboard, then revoke the old one. The same order works for Trigger.dev's own keys: its [API key docs](https://trigger.dev/docs/apikeys) say revoking "takes effect immediately and cannot be reversed" and advise creating a replacement first. 3. **Check usage logs** at each provider for calls you did not make, such as unfamiliar models or a jump in volume. 4. **If you self-host,** confirm you run 4.6.0 or later, which fixes CVE-2026-114069. The trade-off is time spent on key swaps, plus failed runs if a variable goes missing mid-rotation. Trigger.dev's docs warn that deleting a variable can make runs fail. That is cheaper than a stolen AI key running for days on your bill. ## Sources - Trigger.dev, Security Disclosure: Sunday November 1st, November 1, 2026: https://trigger.dev/blog/security-incident-nov-2026 - Trigger.dev status page, incident of November 1, 2026: https://status.trigger.dev/incident/1110434?mp=true - Runtime Wire, Trigger.dev says attacker accessed environment variables for a subset of organizations, November 2, 2026: https://runtimewire.com/article/trigger-dev-environment-variables-security-incident-november-2026 - Wiz, "Black October" for AI Developer Platforms, October 30, 2026: https://www.wiz.io/blog/black-october-for-ai-developer-platforms - VulnCheck, CVE-2026-114069 advisory, October 20, 2026: https://www.vulncheck.com/advisories/trigger-dev-before-4.6.0-root-secret-disclosure-via-envvars-api-endpoint - Trigger.dev docs, Environment Variables: https://trigger.dev/docs/deploy-environment-variables - Trigger.dev docs, API keys: https://trigger.dev/docs/apikeys - Hacker News discussion, November 2, 2026: https://news.ycombinator.com/item?id=50331784