Trigger.dev customer environment variables exposed

anurag 52 points 18 comments November 02, 2026
trigger.dev · View on Hacker News

Discussion Highlights (8 comments)

reassess_blind

Have any of these companies disclosed the actual vulnerabilities used to gain access to their systems?

iampims

It’s bold to set status page incident to resolved.

corvad

I am sorry, this is "Resolved"? How can they even consider marking this resolved in any situation. Yeah we exposed your env vars but we told you about it over email so it's all good... We dont know how or to what extend though.

fathermarz

Holy smokes, is security just not a priority at all anymore? Like in what world do we live in, that this is acceptable. And at the volume this has been happening, bad guys are having a FIELD DAY.

asdfsa32

So at this rate, how long before people start hiding use of AI in development of in their SaaS and services? or people really don't care, do they?

theturtletalks

The biggest case for building bespoke software is that you drop your attack surface area and it’s not as lucrative to hack one person. Don’t even expose it to the internet if you don’t need to and just run Tailscale.

rvz

Given the recent Claude Code remote access tool, it would be wise to not install any new software, or use any package manager for a few weeks as they could have already been silently backdoored during the aftermath of that incident.

cpursley

The very fact that Nextjs vibe projects need an external (and paid!) background jobs / async service show how much of an anti pattern that this framework and similar are. Just use a sensible stack from day one that can handle concurrency out of the box like Elixir or something with established open source background jobs library. Then you can worry less about this kind of 3rd party nonsense. Ditto on auth.

Semantic search powered by Rivestack pgvector
11,391 stories · 107,783 chunks indexed