Trigger.dev Environment Variables Exposed — Lessons for Every SaaS User
By Arash Latifi — Founder, The DevArt
On Nov 1, Trigger.dev disclosed that an attacker accessed environment variables for a subset of customers. What happened, how the community reacted, and a checklist for your own project.
TL;DR — An attacker gained access to environment variables for a subset of Trigger.dev customers; the exploit is blocked but no technical postmortem has been published. If you use any SaaS service, your API keys are on the line — run this checklist today.
On November 1, 2026, Trigger.dev CTO Eric Allam published a short disclosure: the exploit used in the attack has been blocked, but the investigation identified exposure of environment variables for a subset of organizations. All impacted account owners were emailed with mitigation steps.
Two days later, there's still no technical postmortem — no explanation of what the vulnerability was, how long the access lasted, or who the attacker was. That gap is exactly what made the HN discussion (104 points at the time of writing) heated, and it carries lessons for everyone.
How the community reacted — and why it matters
| What users expected | What actually happened | Result | |---|---|---| | Full technical postmortem after containment | One paragraph + status set to resolved | Trust damaged | | Scope of the leak (which keys, how long) | "We emailed impacted owners" with no public detail | Speculation filled the gap | | Status stays "mitigated" during investigation | Marked resolved immediately | Heated HN debate |
Sharp points from the thread:
- One user asked whether any of the recently-breached companies had disclosed the actual vulnerability. The answer: no — "which may mean they don't know."
- whilenot-dev noted: "they just state that they 'blocked the exploit' — did they take the affected API offline, disable the attacker's account, or actually fix the bug?"
- One commenter said this response alone means they'll "never use this service or recommend it" — not because of the breach itself, but the communication.
- An interesting theory: Northflank mentioned patching CVE-2026-98432, the Linux TCP kernel vulnerability, and this incident may be related (unconfirmed).
Why env vars are the crown jewels
Your environment variables typically hold payment gateway keys, SMTP credentials, SMS API tokens, and webhook secrets. With access to them, an attacker can withdraw from your payment account, send phishing email from your domain, or forge webhooks — without ever touching your server or code.
Checklist: do this today
- [ ] Rotate the API keys and credentials for every external service you use (payments, SMTP, SMS) — even if you don't use Trigger.dev. As one HN commenter put it: it's the customers' incident until their secrets are rotated.
- [ ] Review your payment gateway logs for unrecognized transactions or payouts.
- [ ] Audit admin access and long-lived tokens; revoke any key that hasn't been used recently.
- [ ] Watch for official emails from services you use — but never click links inside them; check the vendor's status page or dashboard directly.
- [ ] Build a rotation habit: every 90 days, rotate everything. It's an hour of work that neutralizes an entire class of breach.
- [ ] If you run a service yourself, have a crisis playbook: publish the postmortem before flipping the status to resolved.
The communication lesson: what does "resolved" mean?
The biggest friction in the thread was the status page being marked resolved quickly. When one user asked "if it's fixed and customers were emailed, are you really upset they marked it resolved?" the reply was simply: "Yes." The industry expectation is that a security incident closes when the root cause is publicly explained, a postmortem is published, and preventive measures are defined — not just when the exploit stops working.
For smaller teams, the takeaway is direct: if your account or server is ever breached, full transparency (even bad news) beats silence. Speculation always looks worse than reality.
Q: I don't use Trigger.dev — does this affect me?
Yes, twice over. Any SaaS holding your env vars can suffer a similar breach, and any API key you've granted a third party (payment gateway, email) is exposed if that vendor is compromised. Scope every third-party key to the minimum access it needs.
Q: How do I know if my keys leaked?
Three practical checks: review each key's usage logs (most services show last-used timestamps), watch transactions and outbound email for unfamiliar activity, and when in doubt, rotate — rotation costs minutes; a payment breach can cost your business.
Q: What's the right way to store env vars?
Basics: one scoped key per service, no master keys in third-party tools, 90-day rotation, and use your host's secret manager or env vars rather than a committed .env file.