# Trigger.dev says an attacker accessed customer environment variables

Trigger.dev says an attacker accessed environment variables for an undisclosed subset of organizations. The company blocked the exploit and emailed affected account owners.[1]

Trigger.dev disclosed on November 1 that an attacker gained unauthorized access to environment variables for a subset of organizations.[1]

The company says it blocked the exploit and emailed impacted account owners with mitigation steps.[1] Its status page marked the API incident resolved at 22:50 UTC.[2]

Trigger.dev has not published the exploited flaw, the number of affected organizations, the access period or evidence about how exposed values were used.[1][2]

Because Trigger.dev injects stored variables into deployed tasks, affected values may include API keys, database credentials and service tokens selected by each customer.[3] The company has not said that every stored value contained a credential or that attackers used any copied secret.[1]

## What Trigger.dev confirmed

[Trigger.dev's disclosure [1]](https://trigger.dev/blog/security-incident-nov-2026) says an attacker gained unauthorized access to environment variables belonging to a subset of organizations. The company says it blocked the exploit and emailed all impacted account owners with mitigation steps.[1]

[The status record [2]](https://status.trigger.dev/incident/1110434) identifies the API as the affected service and marks the incident resolved at 22:50 UTC on November 1.[2] That status shows containment of the reported exploit. It does not show that exposed credentials have been revoked at their issuers.

The public notice does not identify affected customers. If your organization received no message, verify the email addresses and administrator accounts tied to Trigger.dev before concluding that it was outside the affected subset.

## Why environment-variable access matters for AI workflows

[Trigger.dev's environment-variable documentation [3]](https://trigger.dev/docs/deploy-environment-variables) says variables used by deployed tasks must be accessible to Trigger.dev so task code can run.[3] The same documentation shows examples for API keys, service-account JSON and credentials used to retrieve secrets from another manager.[3]

A Trigger.dev project can run background jobs and AI-agent workflows. Teams often give those tasks access to model providers, databases, cloud services, messaging systems and business APIs. The exact risk depends on which values each affected customer stored and what permissions each credential carried.

[RuntimeWire's report [4]](https://runtimewire.com/article/trigger-dev-environment-variables-security-incident-november-2026) independently notes that Trigger.dev had not disclosed the affected count when it reported the incident.[4] It does not add evidence about the exploit or credential abuse.

## Response checklist for Trigger.dev customers

- Check the inboxes and spam folders for every Trigger.dev owner and administrator. Preserve the notice and its stated mitigation steps as part of your incident record.[1]
- Export or record the names of variables in each affected project and environment without copying secret values into tickets, chat or shared documents.
- Revoke exposed API keys, tokens, passwords and certificates at their issuers. Updating a Trigger.dev value alone cannot invalidate a copy held elsewhere.
- Generate replacement credentials with the smallest permissions and shortest practical lifetime, then update Trigger.dev and verify affected tasks with a harmless run.
- Review model-provider usage and billing, database access, cloud audit events, source-control activity, webhook changes and business-system logs.
- Inspect Trigger.dev run history for unexpected executions, inputs, failures and outbound actions. Preserve relevant logs before their retention windows expire.
- Escalate suspicious activity to Trigger.dev and each affected provider. Follow contractual, regulatory and customer-notification duties that apply to your data and jurisdiction.
- Track later Trigger.dev updates because the company says more information will follow.[2]

## A rotation order that limits downtime

- Prioritize credentials that can spend money, read or change production data, administer identity, deploy code or create new credentials.
- Map each value to every task and external consumer before replacement so dependent jobs do not retain stale credentials.
- Revoke first when immediate misuse is possible. For systems that require overlap, restrict the old credential, monitor it closely and keep the overlap brief.
- Update the stored values, then run a harmless task. Trigger.dev says it fetches and injects environment variables before a run begins.[3]
- Run a harmless verification task and confirm that the replacement works, then check that the old credential fails at its issuer.
- Use separate credentials for development, staging and production. Separate keys by task or service when the provider supports that model.

## What remains uncertain

- Trigger.dev has not published the exploited vulnerability, initial access path or root cause.[1][2]
- The company has not stated how many organizations, projects, environments or variables were affected.[1][2]
- The public pages do not state when unauthorized access began or how long it lasted.[1][2]
- Trigger.dev has not said whether the attacker copied every accessible value or used any exposed credential.[1][2]
- No public notice identifies affected downstream providers, data sets or customer workloads.[1][2]
- The status label says resolved, but the company has promised more details and has not published a technical postmortem.[2]

## Frequently asked questions

- Who was affected? Trigger.dev says a subset of organizations and says it emailed all impacted account owners. It has not published a count or list.[1]
- Should every Trigger.dev customer rotate credentials? The public notice directs mitigation messages to affected owners. Customers should first verify their notification status and watch for updated company guidance.
- Is changing the variable in Trigger.dev enough? No. Revoke the old credential at its issuer, store the replacement and verify the next task run.
- Were AI provider keys exposed? Trigger.dev says environment variables were accessed, but it has not named the values or downstream providers involved.[1]
- Does resolved mean the secrets are safe again? The company says it blocked the exploit.[1] A copied credential remains usable until its issuer revokes it or it expires.
- Where should teams watch for updates? Trigger.dev says it will publish updates on its status page.[1][2]

## Sources

- [[1] Trigger.dev: November 1 security disclosure](https://trigger.dev/blog/security-incident-nov-2026)
- [[2] Trigger.dev status: security incident record](https://status.trigger.dev/incident/1110434)
- [[3] Trigger.dev documentation: environment variables](https://trigger.dev/docs/deploy-environment-variables)
- [[4] RuntimeWire: Trigger.dev incident report](https://runtimewire.com/article/trigger-dev-environment-variables-security-incident-november-2026)