Trigger.dev says attacker accessed customer environment variables

Trigger.dev disclosed that an attacker got at environment variables for some of its customers, and if you run background jobs or agent workflows there, those variables are probably where your keys live.

The disclosure is short. Under the title "Security Disclosure: Sunday November 1st," Trigger.dev says there was a security incident, that it blocked the exploit used, and that its investigation "identified exposure across a subset of organizations." The attacker "gained unauthorized access to environment variables for these organizations." Impacted account owners were emailed with steps to mitigate.

That's basically all of it. The status page lists the API as the affected service and shows the incident as Resolved, with a timestamp of Nov 1, 2026 at 10:50pm UTC, plus a line saying "We will follow up with more details." The Hacker News thread hit 130 points and 65 comments, and a lot of those comments were about that one word, resolved.

What's actually new

Here's what Trigger.dev has confirmed. Environment variables were accessed, for a subset of organizations, through an exploit that's now blocked. Owners of affected accounts got an email.

Here's what it hasn't said, per its own pages and a response guide from Learnetto that tracked the gaps. No root cause or exploited flaw. No count of affected organizations, projects or variables. No access window. Nothing on whether the attacker copied every value, or used any of them.

The reason this matters more than the length of the post suggests: Trigger.dev's docs, as cited in Learnetto's guide, say variables used by deployed tasks have to be accessible to Trigger.dev so the task code can run, and that it fetches and injects them before a run starts. So these are a lot more than config flags. Its own examples cover API keys, service-account JSON and credentials used to pull secrets from another manager.

Why it matters if you build agents

Think about what an agent task's env file usually looks like. A model provider key. A database URL. A Stripe key for the billing step, a Slack token for the summary at the end, maybe a GitHub token for the PR it opens. Every one of those is a separate credential, issued by a separate service, with separate permissions. If that file leaks, you're rotating all of them, and the rotation is the expensive part.

Learnetto's guide makes the point plainly: updating a value in Trigger.dev doesn't invalidate the copy someone else already has. You have to revoke at the issuer. Its suggested order is to go first after anything that can spend money, read or change production data, administer identity, deploy code or create new credentials. Then replace with narrower permissions, run a harmless task to check it works, confirm the old credential fails, and review logs and billing for every service an exposed value could reach.

This is the bit where the number of keys sitting in one place really hurts. One way to shrink it for the app side of an agent is to not hand the job the app keys at all. With MewCP, app credentials sit in MewCP's encrypted vault and get injected into the request only when a tool is called, so the job's environment holds one MewCP key instead of a stack of app tokens. If that key leaks, you revoke it in the dashboard and the docs say it stops working immediately, and since the gateway records every call, you have one place to look for what it touched.

To be fair about the tradeoff, that moves your app secrets to another hosted vault, which is the exact trust question the HN thread is chewing on. A leaked MewCP key is also still live until you revoke it, so keep the toolset behind it small and only switch on the tools the job actually needs.

What people are saying

The biggest argument on Hacker News was about the status page. Some commenters thought marking the incident resolved, with that little detail, was a bad call, and wanted it held at mitigated until there's a postmortem. One person said that's how it worked everywhere they had been, with resolved meaning a postmortem and repair items are published. Others pushed back that the exploit is blocked, so Trigger.dev's incident is over, and what's left is each customer's incident until they rotate their secrets. One commenter also pointed out that "blocked the exploit" could mean a few different things.

A second thread of comments went bigger picture. One commenter predicted infra startups will lose enterprise customers back to the hyperscalers after incidents like this, pointing at a recent Northflank breach and Railway. Others argued for self-hosting or building their own tools, and got the obvious replies: you become your own ops team, and bespoke tools are often less hardened. Someone noted Trigger.dev is open source and can run in your own infra.

On cause, nothing is confirmed. One commenter said Northflank mentioned patching CVE-2026-98432 and that this looked similar, but that's unconfirmed by Trigger.dev. Another said a competitor, Inngest, had a similar issue a few months ago. Treat both as thread chatter tbh.

Open questions

• Root cause. Not published yet. The status page promises more details.
• Scope. How many organizations, and which variables, is unknown. If you didn't get an email, Learnetto suggests checking every owner and admin address before assuming you're outside the subset.
• Misuse. No word on whether any exposed credential was actually used.
• The CVE link. The connection to the Northflank patch is speculation.

If you're a Trigger.dev customer, check your inboxes and spam folders first, then work through the rotation order above. Resolved on a status page doesn't mean your keys are safe again.

Sources

• Trigger.dev, Security Disclosure: Sunday November 1st, https://trigger.dev/blog/security-incident-nov-2026
• Trigger.dev status page incident, https://status.trigger.dev/incident/1110434
• Hacker News discussion, https://news.ycombinator.com/item?id=50331784
• Learnetto, Trigger.dev Breach: Secret Rotation Guide, https://learnetto.com/ai-resources/triggerdev-environment-variable-breach
• MewCP docs, API Key, https://docs.mewcp.com/mewcp/authentication/mewcp-key.md