Breaches

London’s Trigger.dev says attacker stole customer secrets and API keys

London AI workflow platform Trigger.dev says an attacker accessed customers’ environment variables. Rotate every stored key at its issuer now.

Padlock graphic with the headline Trigger.dev customer secrets exposed and a data breach label.

Trigger.dev, the London-based platform that runs AI agents and background jobs for development teams, has confirmed that an attacker got into environment variables belonging to some of its customer organisations. Any organisation that kept API keys, database passwords or payment credentials on the hosted service should treat them as compromised until it has revoked and reissued them.

What happened

Late on Sunday 1 November 2026, Trigger.dev posted a short security disclosure on its blog and status page. The status entry, marked resolved at 22:50 UTC, named the API as the affected service. The company said its investigation had found exposure affecting a subset of its customer organisations. An attacker had gained unauthorised access to those organisations’ environment variables.

Chief technology officer Eric Allam signed the notice. It says the exploit used in the attack has been blocked and that account owners at every affected organisation have been emailed instructions on how to limit the damage. It does not say how many customers are involved, when the intrusion started, how the attacker got in or which kinds of secret were taken. When The Register asked for more detail, the company declined and said a full incident report would follow.

Trigger.dev trades as API Hero Ltd. According to its Y Combinator profile it was founded in 2022, is based in London and has 17 staff. Its public customer list includes Emporio Armani, Cal.com and GovSignals. It has not said whether any of them were affected.

The technical picture

Trigger.dev is an open-source TypeScript framework with a managed cloud service on top. Developers use it to run long-lived tasks and AI agents, and the platform takes care of queuing, retries, scaling and observability. Those tasks have to reach other systems, so customers store the credentials they need as environment variables in each project’s staging, preview and production environments. Typical examples are model provider keys for OpenAI or Anthropic, database connection strings, Stripe secret keys and email service tokens. Recent webhook integrations with Stripe, Supabase and Slack widen that reach.

That makes the variable store unusually valuable. A single dump can hand an attacker working access to a customer’s billing, data stores and AI accounts, with no need to compromise the customer’s own network. Because the platform is built to run work at scale without timeouts, a stolen key can also be used heavily and quickly before anyone looks at the bill.

Trigger.dev has not named a root cause. The developer news site byteiota links the incident to CVE-2026-114069, and that link remains unconfirmed. The flaw itself is documented. A VulnCheck advisory dated 20 October, rated 8.6 under CVSS 4.0 and fixed in version 4.6.0, describes an authorisation error in the project environment variables API. That endpoint returned each environment’s root secret key to callers holding only a restricted read permission for variables. With the root key, a caller could read stored secrets in plain text, start tasks and create administrative tokens. Until Trigger.dev publishes its report, readers should treat byteiota’s link as a working theory.

Checklist of six actions for Trigger.dev customers: confirm exposure, rotate keys at the issuer, hunt for misuse, patch self-hosted instances, scope keys down and record the ICO decision.

Why it matters for UK organisations

This is a British supplier, and its customers will include UK businesses building AI features on its cloud. Environment variables are not usually personal data. However, the databases and SaaS accounts they unlock often hold personal data. A UK controller that finds a stolen connection string was used to query customer records has to decide quickly whether the 72-hour UK GDPR reporting duty to the ICO has started. A supplier telling you the hole has been closed does not answer that question for you.

The incident also fits a pattern that UK buyers should take seriously. Platforms that hold large numbers of AI and cloud credentials keep being targeted, and on 1 November we reported the Northflank breach as part of the same run of incidents. The Cyber Security and Resilience Bill will bring more managed and digital service providers under formal incident-reporting rules. Even so, your own exposure is decided by where your secrets are kept and how much access each one grants, whatever a regulator requires of the supplier.

Expert view

When we test cloud-native estates, the environment variable store is one of the first places we look. Teams treat it as plumbing rather than as a vault, so it routinely holds full-access production keys that were created once and never scoped down. One leaked secret can open several other systems, because the same key often works far more widely than the job it was created for.

The detail I would pay most attention to is the alleged privilege jump: a restricted read key turning into a root key. In my experience, scoped API tokens give people a false sense of safety. Buyers assume “read-only” means read-only, but the server has to enforce that limit on every endpoint, and one missed check undoes the whole permission model. The company has not confirmed that happened here, but it is exactly the kind of flaw that slips through when a platform adds features quickly.

Trigger.dev’s disclosure is thin. Going public on a Sunday night and emailing affected owners directly is the right instinct. However, customers who did not get that email still have no way of confirming they were unaffected, and no timeline to check their logs against. A prompt, detailed report would do more for trust than reassurance.

What to do now

  1. Check whether you are affected. Find out whether anyone in your organisation uses Trigger.dev cloud, including side projects and proofs of concept. Check account owner mailboxes for the notification.
  2. Rotate at the source. For every secret held on the platform, revoke it and issue a new one with the provider that created it: OpenAI, Anthropic, AWS, Stripe, your database host, email and messaging services. Deleting a variable from the dashboard does not invalidate the key. If you have stored secrets there at any point, do this even if you received no email.
  3. Look for misuse. Check AI provider usage dashboards, cloud billing, Stripe activity and database audit logs for unfamiliar sources or spikes in calls, starting several days before 1 November.
  4. Patch self-hosted instances. If you run Trigger.dev yourself, confirm you are on version 4.6.0 or later before rotating, so the new secrets are not exposed the same way.
  5. Reduce what one key can do. Issue a separate, least-privilege key for each workflow and environment, set spending caps with AI providers, and move high-value secrets into a dedicated secrets manager. This is the Cyber Essentials user access control and secure configuration controls applied to machine identities.
  6. Record your breach decision. If any rotated credential could reach personal data, document whether you reported to the ICO and why, within the 72-hour window.

Bottom line

Trigger.dev has been quick to admit there was a problem but has so far said little about what happened. Until the full report arrives, assume any secret stored on its cloud may have been read, rotate it at the issuing provider and check for misuse. The broader lesson for UK teams building with AI is that the platforms running their agents now hold some of their most valuable credentials, and those credentials need the same protection as a production database.

Sources

Related Posts