Trigger.dev says an attacker read environment variables for some customer organizations

Trigger.dev, a platform for running background tasks and workflows, disclosed a security incident on Sunday, 1 November. In a short post signed by CTO Eric Allam, the company says: “The attacker gained unauthorized access to environment variables for these organizations.” It says it has blocked the exploit and emailed all impacted account owners “with steps to mitigate”.

What Trigger.dev has said

• What was exposed: environment variables, for “a subset of organizations”.
• Status: the exploit used in the attack is blocked. The status page entry lists the API as the affected service and was marked resolved at 22:50 UTC on 1 November.
• Notice: impacted account owners were emailed. The status entry adds: “We will follow up with more details.”

What it has not said

As of the evening of 2 November, Trigger.dev had not said how many organizations were affected, how the attacker got in, how long the access lasted, or which variables were read. The mitigation steps it sent are in the emails, not on the public page. “Resolved” on the status page means the exploit is blocked. It does not mean secrets that were already read are safe.

What to do now

Environment variables on a task platform usually hold the keys your jobs call out with: model provider API keys, database URLs, cloud credentials, webhook secrets. Standard practice after a secrets exposure, whatever the vendor’s email says:

1. Check the inbox of every Trigger.dev account owner in your organization, including spam, for the notice.
2. List every secret stored in Trigger.dev environment variables, across all projects and environments.
3. Rotate each one at the service that issued it, then update Trigger.dev and any other place that uses it. Revoke the old value; do not just add a new one.
4. Review logs at those providers for use of the old keys since before 1 November.

We covered how secrets slip out of agent pipelines in three common leaks. The same rotate-first rule applied when LiteLLM 1.107.0 shipped a credential stealer.

Why this matters

Anyone running AI agents or background jobs on Trigger.dev should assume the provider keys they stored there need rotating unless the company tells them otherwise. In the LiteLLM case the stealer was in the package and the fix was to pin and rotate; here the exposure sat at the platform, so pinning a version does nothing and rotation is the whole fix. Keep scoped, per-service keys, as in a token for one MCP server belongs to that server, so one leak does not open everything.