News for hackers. Stuff that matters.

A comment on Trigger.dev customer environment variables exposed. Parent comment

Re:Trigger.dev customer environment variables exposed by tomrod on Monday November 02, 2026 @07:59AM (#50336240)
To use a fearful, apt analogy: resolving the operational issue isn't just plugging the hole in the dam, its also fixing the damage by pumping the water out and then addressing the damages.
[ Parent | on HN ]
Re:Trigger.dev customer environment variables exposed by weird-eye-issue on Monday November 02, 2026 @08:52AM (#50336811)
In your analogy they can't pump the water out. Now it's up to their users to rotate their keys. How do you expect them to do that sort of thing on behalf of their users?
[ Parent | on HN ]
Re:Trigger.dev customer environment variables exposed by tomrod on Monday November 02, 2026 @08:59AM (#50336889)
Depends on the TOS, but, blocking service until confirmed or decommed would get the trick done.
[ Parent | on HN ]
Re:Trigger.dev customer environment variables exposed by weird-eye-issue on Monday November 02, 2026 @09:59AM (#50337712)
That doesn't even make sense. People use environment variables to store things like API keys for third-party services. How do you expect them to magically rotate or decommission those keys?
[ Parent | on HN ]
Re:Trigger.dev customer environment variables exposed by tomrod on Monday November 02, 2026 @10:40AM (#50338333)
Trigger.dev wouldn't rotate customer BYOK. What I was saying is they disable customer use of their service until rotation occurs or is confirmed by the customer.
[ Parent | on HN ]
Re:Trigger.dev customer environment variables exposed by weird-eye-issue on Monday November 02, 2026 @09:46PM (#50347366)
That doesn't really help anything and just makes the exploit impact even worse since it would be effectively a denial of service
[ Parent | on HN ]