Trigger.dev says an attacker accessed environment variables of some organisations; no count or times given

A five sentence notice with no number and no time

Trigger.dev's own notice of a security incident is five sentences and 67 words (derived count). It went up on the vendor's blog at 22:33 UTC on Sunday 1 November 2026, and a status page entry followed at 22:50 UTC. It says an attacker gained "unauthorized access to environment variables" for a subset of organizations. It gives no count of organizations, no time of discovery or containment, and no cause beyond the word exploit. Twenty six days earlier (derived), the same vendor's incident report of 6 October named 121 customer organizations and dated eight steps. The 1 November notice has none of those.

What that does not establish is most of what a customer needs. The notice does not say which variables, from which environments, over what period, or whether the values were copied out, decrypted or used anywhere. "Access" is the vendor's word. Headlines may say stolen. The vendor's pages do not.

This briefing rests on the vendor's pages only: the blog notice, the status entry, the vendor's documentation and security page, its 6 October report and its public advisory list. No outside report was read. All were read from 18:33 to about 18:40 UTC on Monday 2 November 2026. When the status overview and the blog feed were re-read at 18:34 UTC, neither had an update, 20 hours and 1 minute after the blog went up (derived). Trigger.dev is a platform that runs background tasks and AI agents for its customers, as its own site describes it, so what sits in its environment variables is usually the keys that let those tasks reach other services. Any later update from the vendor will overtake parts of this page.

What the vendor states, and what it does not

The status entry is marked Resolved and lists the affected service as API. Its last line says the vendor will follow up with more details. So the page labelled resolved says the account is not finished. The status overview, last updated at 18:33 UTC on 2 November, showed all services online and the incident only in the API component history, with nothing added since.

Zoom

What environment variables mean on this platform

The notice never says which kind of variable it means, so the vendor's documentation is the nearest definition. It says any variables a task uses must be added so the deployed code runs, that values can be set for a development, staging and production environment, and that a variable can be marked Secret, which hides its value in the dashboard so it "cannot be viewed after creation". A separate page section lists Production, Staging, Development and Preview as the targets for a synced secret. The documentation's own examples of what goes in are API keys and database credentials, and it also describes writing values in from Infisical, from Vercel and from a deploy time build extension. So the likely contents are the keys a customer's code uses to reach model providers, databases and payment or messaging services. That is this site's inference from the documentation, not something the notice says.

The friendly names are where a reader can be misled. The vendor's security page says data is encrypted at rest and in transit, and its 6 October report says a restore copied encrypted data without decrypting customer secrets. Those are statements about storage. A task has to receive the plaintext value to run, so the platform necessarily holds a path from the stored value to the readable one. The notice does not say whether the values the attacker reached were readable, and a Secret flag describes what the dashboard shows, not what an attacker who reaches the right path obtains. Until the vendor says which values were reachable, treat a secret flagged variable as no safer than a plain one.

The times, and the vendor's own earlier standard

The two printed times are 22:33 UTC for the blog notice (the page data and the blog feed agree) and 22:50 UTC for the status entry, 17 minutes apart (derived). Nothing else on either page is dated, so the length of the attacker's access, the gap between discovery and containment, and the gap between containment and the emails are all unknowable from these pages.

Zoom

The vendor has shown it can be specific. A comparison of disclosure detail only, because the 6 October incident was a different kind of event (a vendor change that cleared customers' values, with no attacker) and nothing links the two:

The vendor's public advisory list on GitHub shows 39 published advisories (derived from four list pages), the latest dated 20 October 2026. None is dated 1 or 2 November and the notice links to none. Only the list pages were read, not the advisories themselves. The list includes earlier items whose titles concern environment secrets, among them one from 14 September about restricted API keys reading an environment root secret and one from 31 July about CLI debug logs exposing resolved secret values. Whether either relates to the 1 November incident is not stated, and this site does not suggest it does.

What a customer can do, in order

The vendor's steps went to account owners by email and are not on the public pages, so none of the items below is the vendor's advice unless it says so. They are this site's suggestions, ranked by how much each reduces risk for the effort, and each is a precaution because the vendor has not said which values were reachable.

Technical details

The vendor's notice and status entry print no indicators, versions, commands, hashes, domains or addresses, and no cause beyond the word exploit. There is therefore nothing to hunt for in your own logs from the vendor's text, and this site has not invented any. What the vendor's documentation does print is the programmatic surface for listing and changing environment variables. Defenders can use it to build the inventory in step three of the checklist and, after rotation, to set new values. The names below are copied as the documentation prints them (layout adjusted onto separate lines); use them with care, because listing a variable may return its value.

envvars.list()      List all environment variables
envvars.upload()    Upload multiple env vars. You can override existing values.
envvars.create()    Create a new environment variable
envvars.retrieve()  Retrieve an environment variable
envvars.update()    Update a single environment variable
envvars.del()       Delete a single environment variable

The same page names the environments a variable can target. These are the labels to cover when listing and rotating, copied from a code comment and from its section on synced secrets:

// e.g., "dev", "prod", "staging"
Production, Staging, Development, or Preview

The question the notice leaves open

A vendor that has told you an attacker reached your environment variables, and nothing else, has handed you a task rather than an answer. The question to put to your own team is this: if every key stored in that platform was read, which provider logs would show whether it was used, and do they reach back far enough to say?

Key facts