News for hackers. Stuff that matters.
Re:Trigger.dev customer environment variables exposed by theturtletalks on Monday November 02, 2026 @12:08AM (#50333351)
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.
Re:Trigger.dev customer environment variables exposed by cbluth on Monday November 02, 2026 @01:37AM (#50333764)
I think you've just explained why people rent infrastructure.
Re:Trigger.dev customer environment variables exposed by shepherdjerred on Monday November 02, 2026 @02:48AM (#50334168)
This is probably correct if you aren’t a target at all, e.g. you aren’t running a business
Re:Trigger.dev customer environment variables exposed by pelagicAustral on Monday November 02, 2026 @04:18AM (#50334640)
Tailscale got hacked recently as well, didnt they (?). I think they did, the whole system is poisoned, because I believe one of the vectors had to do with eMudhra certs, which again, is not an issue specific to them, or something they had any say on it... there is literally no escape these days it would seem.
Re:Trigger.dev customer environment variables exposed by thewisenerd on Monday November 02, 2026 @05:02AM (#50334913)
tailscale got hacked recently? sources?

they had a priviledge escalation vulnerability that requires the attacker to already be a part of the tailnet, and more specifically allows a user-to-root escalation devices the attacker can tailscale ssh to.

> Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is. [1]

eMudhra/TLS certificates have nothing to do with this (?).

[1] https://news.ycombinator.com/item?id=50266179

Re:Trigger.dev customer environment variables exposed by theturtletalks on Monday November 02, 2026 @07:17AM (#50335826)
That was Tailscale SSH and it’s not on by default
Re:Trigger.dev customer environment variables exposed by jen20 on Monday November 02, 2026 @11:46AM (#50339600)
It also was not related to the mentioned CA, and was not "hacked".
Re:Trigger.dev customer environment variables exposed by bitlad on Monday November 02, 2026 @06:32AM (#50335506)
Or do onprem or selfhosted. Surface area reduces drastically.
Re:Trigger.dev customer environment variables exposed by theturtletalks on Monday November 02, 2026 @07:26AM (#50335922)
I was also referencing that using commercial software usually brings features you probably don’t use. Those features probably require new NPM packages so by building a bespoke software, you only build features you need.
Re:Trigger.dev customer environment variables exposed by dangoodmanUT on Monday November 02, 2026 @08:25AM (#50336514)
this is often a worse time-to-patch
Re:Trigger.dev customer environment variables exposed by seanw265 on Monday November 02, 2026 @09:30AM (#50337317)
The tradeoff is that you become your own ops team and need to monitor and respond to cves in real time.
Re:Trigger.dev customer environment variables exposed by seanw265 on Monday November 02, 2026 @09:31AM (#50337325)
I don't see bespoke software as a viable alternative because probing for vulnerabilities is both getting cheaper by the day, and also massively parallelizable.

Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.

Not to mention your bespoke tool is likely way less hardened than the existing player in the space.

Re:Trigger.dev customer environment variables exposed by sergsoares on Monday November 02, 2026 @11:44AM (#50339555)
Agree in don't ever expose if not needed.

And keep private and public personal hosted services in different contexts.