Trigger.dev Env Vars Stolen: 0 Orgs Named [2026]

Trigger.dev told customers on November 1, 2026 that an attacker gained unauthorized access to the environment variables of a subset of organizations on its AI agent and background-job platform, with CTO Eric Allam writing in the 10:50pm UTC disclosure that "the attacker gained unauthorized access to environment variables for these organizations." The company said it blocked the exploit and emailed the owners of every impacted account with mitigation steps, but it has not disclosed how many organizations were affected, when the intrusion began, or which secrets were taken; a spokesperson declined further detail and pointed to a full incident report that has not yet appeared, The Register reported on November 2, 2026.

Trigger.dev, the cloud platform that runs AI agents and background jobs for developers, told customers on November 1, 2026 that an attacker had read the environment variables of a subset of organizations. The Register reported the incident on November 2 https://www.theregister.com/security/2026/11/02/thieves-pilfer-environment-variables-from-trigger-ai-workflow-tool/5306998 , calling out how little the company has said so far. The company blocked the exploit and emailed the owners of every impacted account, but it has not said how many organizations were hit or which secrets sat in the stolen variables. Eric Allam, the company’s CTO, wrote the disclosure. It went out at 10:50pm UTC on Sunday, November 1. A day later the open questions outnumber the answers, and customers who store API keys, database passwords or signing secrets in Trigger.dev projects have to act on incomplete information. This analysis separates what is confirmed from what is not, explains why this class of theft hurts more than its short disclosure suggests, and lays out what teams should rotate first. The timing matters too. Developer tooling has been a recurring entry point this autumn, as our report on a tampered Claude Code extension that reached 5,000 users https://shattered.io/cursor-tampered-claude-code-extension-5000-users-2026/ showed. The Trigger.dev case is different in mechanism but similar in lesson: the places where developers park credentials are now prime targets, and AI workflow platforms hold more of them than most. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F What Trigger.dev Confirmed About the Security Incident The confirmed facts fit in a short list. Trigger.dev reported a security incident on November 1, 2026. An attacker gained unauthorized access to environment variables belonging to a subset of organizations on the platform. The company says it blocked the exploit used in the attack, and it says it emailed all impacted account owners with mitigation steps. Allam’s disclosure opens plainly. In his words, “There has been a security incident at Trigger.dev.” He then states the core finding: “The attacker gained unauthorized access to environment variables for these organizations.” The Register adds that the company’s own wording described exposure across a subset of organizations, and that its investigation had identified that exposure. That is the whole confirmed record. The company has not published a technical post-mortem, a customer count, a start date for the intrusion or a description of the exploit. According to The Register, a Trigger.dev spokesperson declined to give additional detail and pointed reporters toward a full incident report that has yet to appear. Timeline: From the Sunday Notice to Monday’s Coverage The sequence is compact because the public record is thin. The table below lists each dated step, using only events the company and named outlets have documented. | Date and time | Event | Source | |---|---|---| | Unknown | Attacker accesses environment variables start, duration and method unconfirmed | Not disclosed | | Nov. 1, 2026 | Trigger.dev identifies exposure across a subset of organizations and blocks the exploit | Trigger.dev disclosure | | Nov. 1, 2026, 10:50pm UTC | Security incident announced | Trigger.dev | | Nov. 1, 2026 | Impacted account owners emailed with mitigation steps | Trigger.dev | | Nov. 2, 2026, 16:44 UTC | The Register publishes its report | The Register | | Nov. 2, 2026 | Company declines extra detail, points to a future full report | The Register | The first row is the one that worries security teams. If the attacker held access for days before Sunday, the window for abuse of any stolen key stretches back with it. If access lasted minutes, the picture improves. Trigger.dev has not said which it was. What Trigger.dev Does and Why Its Variables Matter Trigger.dev is a platform for building AI agents and workflows in TypeScript. It sells itself as a durable execution layer, meaning it handles retries, queues, scaling and long-running tasks that survive crashes and redeploys. It also provides monitoring for what those tasks do. The product is open source and can be self-hosted, a point The Register stressed in its coverage. That design explains why environment variables are the valuable asset here. A background job that calls a payment API, writes to a database, sends email and queries a language model needs credentials for every one of those services. Teams commonly store them as project environment variables so the code never contains them. RuntimeWire noted that Trigger.dev runs production background jobs and AI agents for customers, so access to an organization’s variables can expose the keys and credentials those workloads rely on. The Register made a sharper point. Trigger advertises elastic scaling, automated retries and large numbers of concurrent operations without timeouts. In the hands of an attacker holding a valid key, those same features could amplify damage, depending on what the credential unlocks. The outlet also noted that Trigger recently added webhook support for services including Stripe, Supabase and Slack, which widens the range of integrations whose credentials could sit in a project. Why Environment Variables Are a High-Value Target An environment variable is a named value that code reads at runtime instead of storing in source files. Some hold harmless configuration, such as a region name. Others hold database URLs, payment secrets, signing keys and access tokens. Ketryon, a developer blog that published a rotation guide on November 2 https://www.ketryon.com/en/blogg/trigger-dev-lackan-rotera-hemligheter-utan-driftstopp , states the rule bluntly: if an attacker can read a secret variable, treat the value as compromised, even when your logs show no misuse. A copied key does not expire when the vulnerability is fixed. The attacker can store it and use it later from anywhere, and the traffic never has to pass through Trigger.dev again. A stolen database password hits the database directly. A stolen payment key hits the payment API directly. Your application logs will not show the sequence. Attackers also chase credentials because credentials skip the hard part. Instead of breaking each downstream service, they break one aggregator and inherit access to many. Our look at the reported DevOps laptop entry point in the Binance theft https://shattered.io/binance-6-3b-hack-devops-laptop-entry-point-what-we-know-2026/ showed the same logic at far larger scale, where one developer environment opened the way to hot wallets. The Trigger.dev case involves a vendor’s systems rather than an employee’s machine, but the economics are identical. What Remains Unconfirmed: Count, Contents and Attacker Several details that customers most need are missing. Trigger.dev has not given a number for affected organizations. It has not said whether the stolen variables held API keys, passwords, tokens or other secrets. It has not said whether the attacker used anything taken, and it has not named the attacker. The start time, duration and root cause are also undisclosed. No financial loss or ransom figure has surfaced. | Question | Status | What we know | |---|---|---| | Did an attacker access environment variables? | Confirmed | Trigger.dev says yes, for a subset of organizations | | Was the exploit blocked? | Confirmed company claim | Trigger.dev says it blocked the exploit | | Were owners notified? | Confirmed company claim | Emails with mitigation steps went to impacted account owners | | How many organizations? | Unconfirmed | No number disclosed | | Which secrets were inside? | Unconfirmed | No breakdown of API keys, passwords or tokens | | Were stolen values used? | Unconfirmed | No public evidence either way | | Start, duration, root cause? | Unconfirmed | Full report promised via spokesperson | | Who is the attacker? | Unconfirmed | No attribution | Readers should treat the claim that the exploit is blocked as the company’s own statement. No independent party has verified it. That does not make it false, but it means customers cannot rely on it as a reason to skip rotation. Customers Named on the Site and the Silence Around Them The Register pointed out that Trigger has some high-profile customers listed on its own website, including the fashion brand Emporio Armani, the AI acquisitions platform GovSignals and the calendar software firm Cal.com. The outlet did not say any of them were affected. It reported that Trigger has not publicly identified which organizations were hit, and we have no basis to say otherwise. Readers should keep that distinction sharp. A logo on a vendor’s marketing page says nothing about whether that customer’s variables were read. The only organizations that know their status are the account owners who received the email, plus the company itself. Ketryon adds a warning from the other direction: not receiving an email is not technical confirmation that everything is safe. Teams should check which address is registered for the account owner, look in spam folders, and confirm which organization each project belongs to. This is where a thin disclosure imposes real cost. Without a list of affected variable names or environments, every customer has to run their own inventory. A larger customer with dozens of projects and several environments each faces hours of audit work before it can even decide what to rotate. Statements on the Record: Company, Press and Practitioners Only a few named parties have said anything substantive, so it is worth listing each position. - Eric Allam, CTO, Trigger.dev: in the company’s disclosure, he said the attacker gained unauthorized access to environment variables for the affected organizations, and that Trigger.dev had blocked the exploit. - The Register Brandon Vigliarolo : the outlet reported that the company offered little explanation, that a spokesperson declined further detail, and that stolen credentials could give an attacker access to connected services and infrastructure. - RuntimeWire: in its write-up of the disclosure https://runtimewire.com/article/trigger-dev-environment-variables-security-incident-november-2026 , the outlet framed the incident as a test of whether a developer infrastructure company can give customers a clear rotation path before exposed secrets get abused. - Ketryon Kenny Tran : the blog advises treating any readable secret as compromised and rotating in a set order to avoid downtime. The post says it was written with AI assistance from the source material. Nobody in this list has claimed to know the attacker, the method or the scale. We found no verified quotes from outside security researchers on this incident, so this article does not include any. If independent analysts publish findings, expect the picture to sharpen quickly. Hosted Versus Self-Hosted: Where Secrets Should Live The Register’s closing suggestion is that self-hosting the open source version could be a better path than relying on a hosted service. That is partly true and partly a trade. Moving the platform onto your own infrastructure removes a shared vendor tenancy from the threat model. It also moves patching, access control and monitoring onto your own team, which many small shops handle worse than a dedicated vendor does. | Approach | Who guards the stored secrets | Main upside | Main risk | |---|---|---|---| | Hosted Trigger.dev, variables stored in project settings | The vendor | No servers to run | One vendor breach exposes many customers’ keys at once | | Self-hosted Trigger.dev | Your own team | Secrets stay inside your network | You own patching, hardening and incident response | | Hosted runner, secrets fetched at runtime from an external manager | A dedicated secrets service plus the vendor’s runtime | Rotation happens in one place, with access logs | Runtime still sees the value while a job executes | The third row deserves attention. Teams that already run serverless AI agents on cloud primitives know the pattern, and our walkthrough of a serverless AI agent on AWS with Lambda, Bedrock and Step Functions https://shattered.io/serverless-ai-agent-aws-lambda-bedrock-step-functions-12-steps-2026/ shows how identity-based access can replace long-lived keys in many cases. Where a workload can assume a role instead of holding a static secret, a stolen environment variable becomes much less useful. Historical Context: CircleCI, Codecov and Trigger.dev’s Own Past This is not the first time a developer platform’s stored secrets have become the prize. In January 2023, CircleCI told customers to rotate every secret stored on its platform after a security incident. In 2021, a compromise of Codecov’s Bash Uploader script exposed environment variables from customers’ continuous integration runs. Both episodes taught the industry the same lesson: when a vendor holds your secrets, its breach becomes your emergency. Trigger.dev has its own history in public. The company previously published a post-mortem about an earlier incident connected to the Shai-Hulud npm supply-chain campaign, in which it said a compromised dependency led to credential theft and unauthorized access to its GitHub organization. It said its published packages were not infected. Its status page also logged a separate October 2026 problem in which some sensitive variables synced from Vercel were overwritten with empty values. That was a configuration and availability fault, not an intrusion. No public evidence connects any of those earlier events to the November 1 incident. We flag them for context only. A reader should not infer cause from proximity, and the company has said nothing that links them. Still, the pattern of vendors getting probed repeatedly, as in our coverage of the Amadeus flaw that clouded 38 months of airline data https://shattered.io/amadeus-booking-display-flaw-airline-vendor-risk-38-months-2026/ , supports a simple stance. Treat every third-party platform that stores your credentials as a standing risk, not a settled one. How to Rotate Trigger.dev Secrets Without Downtime Ketryon’s guide gives the clearest public procedure so far, and its logic holds regardless of how the investigation ends. Rotation means creating a new secret, moving every legitimate user to it, and only then revoking the old one. Revoke first and your functions break. Wait too long and the attacker’s access stays open. The seven-step order 1. Create a new key at the issuing service without revoking the old one. 2. Store the new key in whichever system you designate as the source of truth. 3. Update Trigger.dev and every other system that uses the same credential. 4. Restart, redeploy or reload processes that cache old values. 5. Verify that real requests use the new key. 6. Revoke the old key at the issuer. 7. Check errors, queues and scheduled jobs after revocation. Ketryon adds two cautions. First, if you see ongoing misuse, skip the overlap and revoke immediately, because a short outage costs less than continued access to payments or customer data. Second, Trigger.dev can pull variables from services such as Vercel, so the same secret may live in several dashboards, local files and pipelines. Pause any automatic sync that could write an old value back over a new one. Which variables to rotate first | Priority | Variable type | Why it ranks here | |---|---|---| | 1 | Database connection strings and passwords | Usable directly against the database, bypassing app logs | | 2 | Payment secret keys and webhook secrets | Broad API access, and the webhook secret rotates separately from the API key | | 3 | Backend service-role keys for example Supabase | Server-level permissions over user data | | 4 | Token and session signing secrets | Rotation may log users out, so plan the change | | 5 | Email, storage and AI provider API keys | Enable spam, data theft or runaway usage charges | | 6 | Deployment and monitoring tokens Vercel, GitHub, Sentry | Can alter code or expose sensitive logs | | 7 | Public client keys | Not secret, but confirm access rules still restrict what they can do | Rotation alone does not tell you what already happened. Review logs at the issuer, not just in Trigger.dev. Look for runs you do not recognize, jobs at odd hours, changed environment variables, new access tokens and rejected requests that might show someone probing a key’s permissions. Export evidence before it rolls off, and keep secrets out of the incident document. Updating Variables Through the Trigger.dev SDK Teams with many projects will want to script the change. Trigger.dev’s documentation for updating an environment variable https://trigger.dev/docs/management/envvars/update shows the SDK call and the access model. It authenticates with a named environment API key, and the docs advise choosing the narrowest access preset that supports the integration. The environment parameter accepts dev, staging or prod. js import { envvars } from "@trigger.dev/sdk"; // Replace a rotated secret in one environment. // Read the new value from your own secure store, never hard-code it. const newValue = process.env.NEW STRIPE SECRET KEY; if newValue throw new Error "Refusing to write an empty value" ; await envvars.update "proj your project ref", "prod", "STRIPE SECRET KEY", { value: newValue, } ; The guard on the empty value is not decoration. The same documentation page states that an empty string is valid and gets stored as-is, not treated as a deletion. A script that reads an unset variable and writes it would silently blank a production secret. Also remember that the API key you use for this call is itself a credential. If it lived in an exposed project, rotate it before trusting it to push the other changes. Market Impact on AI Workflow and Developer Infrastructure Vendors No financial figures tied to this incident are public, so any claim about revenue or churn would be guesswork. What we can assess is the competitive pressure. Hosted platforms that run customer code and hold customer secrets sell on trust. A disclosure that leaves customers without a count, a timeline or a root cause erodes that trust faster than the breach itself, because it pushes the audit burden onto buyers. Vendors in secrets management stand to gain from the attention. Our coverage of Infisical’s $40M Series B for guarding AI agent secrets https://shattered.io/infisical-40m-series-b-600m-valuation-ai-agent-secrets-2026/ already argued that agents multiply the number of credentials in circulation. For buyers weighing options, the AWS Secrets Manager pricing comparison against Vault, Key Vault, OpenBao and Infisical https://shattered.io/aws-secrets-manager-pricing-vs-vault-key-vault-openbao-infisical-2026/ sets out what a dedicated store costs relative to the risk of keeping everything in a job runner’s settings page. For the wider AI tooling market, the lesson reaches past one vendor. Orchestration layers sit between models and the systems those models act on, so they concentrate access. Readers following this space can find more model and tooling analysis in our AI and machine learning section https://shattered.io/ai-machine-learning/ . Expect procurement teams to add questions about secret storage, tenant isolation and breach notification timing to their reviews of workflow vendors. Five Predictions for the Weeks Ahead These are editorial expectations based on how comparable incidents have unfolded, not reported facts and not statements from any named person. 1. A fuller report arrives. The spokesperson pointed to one, and public pressure from customers and press makes a detailed post-mortem likely. It should answer the count, the contents and the access path. 2. Customers move the crown jewels out. Expect more teams to keep payment and database credentials in an external secrets manager and fetch them at runtime, leaving only low-risk configuration in job runner settings. 3. Vendor questionnaires get tougher. Security reviews of AI workflow platforms will ask how variables are encrypted, who can read them internally and how fast customers get notified. 4. Attackers keep targeting aggregators. Platforms that hold credentials for many downstream services offer better returns than any single application, so job runners and agent frameworks will stay in the crosshairs. 5. Self-hosting interest rises, then plateaus. The open source option will attract attention, but the operations burden will keep most small teams on hosted plans. What Developers Should Do Today Start with scope. Check the account owner’s inbox, including spam, for the Trigger.dev notice. If you use Trigger.dev at all, inventory every project and environment, record variable names without copying values, and mark each as public, secret or administrative. Do this even without an email, since the company’s notice covers a subset and your own audit costs little. Next, rotate privileged credentials in the order above, preserving logs first. Then reduce what a future theft could reach. Give Trigger.dev jobs restricted keys limited to the permissions the code needs, separate credentials by service and environment, and prefer role-based access over static secrets wherever your cloud supports it. Finally, document the process so the next rotation takes an hour instead of a week. One more point on attribution. Avoid repeating claims about who did this or how. Neither Trigger.dev nor any named outlet has attributed the attack, and speculation about nation-state or criminal actors adds noise during a period when customers need accurate scoping. We will update this analysis if the company publishes its full report. Frequently Asked Questions What happened at Trigger.dev? Trigger.dev disclosed on November 1, 2026 that an attacker gained unauthorized access to environment variables belonging to a subset of organizations. The company says it blocked the exploit and emailed impacted account owners. How do I know if my organization was affected? Trigger.dev emailed the owners of impacted accounts. Check that inbox and your spam folder. The company has not published a list of affected organizations, so if you cannot confirm your status, ask Trigger.dev support to verify the projects and environments involved, and treat stored secrets cautiously in the meantime. Which secrets were stolen? That is unconfirmed. The disclosure does not say whether the variables held API keys, passwords, tokens or other secrets. Environment variables commonly hold such values, so the safe assumption is that any secret stored in an exposed project may have been read. Has anyone used the stolen data? No public evidence says so, and no public evidence rules it out. Trigger.dev has not disclosed whether the attacker used anything taken. Review logs at each service that issued a credential, not only in Trigger.dev. What should I rotate first? Start with database credentials and payment secret keys, then backend service-role keys, signing secrets and provider API keys. Create the new key, update every consumer, verify real traffic uses it, and only then revoke the old one. Skip the overlap if you see active misuse. Is self-hosting Trigger.dev safer? It removes the shared vendor tenancy from your threat model, and the platform is open source, as The Register noted. It also makes your team responsible for patching and monitoring. For many teams, a hosted runner paired with an external secrets manager is the more practical improvement. Is this related to the October Vercel sync problem? Not according to anything public. The October event was a status incident in which some synced variables were overwritten with empty values, which is a configuration fault. The November 1 disclosure describes unauthorized access. Nothing links the two.