[xyzzy_plugh]

> we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years.

This is a poor measure of quality. I've spent considerable time knee-deep in these issues in particular and the vast, vast majority of them are feature requests, bug reports awaiting more information from the submitter, or bug reports that cannot easily be reproduced (likely conflicts with other software). On the whole, Tailscale does an excellent job of "just working" in practically every possible environment. They do an incredible job thriving in the diverse ecosystem of software networking and their work will naturally never be remotely done. There will always be gaps, it's the nature of the beast. I'm not aware of any other product that does a better job here.

If you've spent any time dealing with enterprise software you'd know that there is an infinite firehose of these sort of issues. We're lucky that Tailscale keeps these public. Many other vendors track these sort of issues privately.

If there are particular issues which jeopardize the security posture of Tailscale deployments that have been open for a significant amount of time, my clients and I would love to know. Please share!

> We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery. Especially as, AFAIK, Tailscale have never had a formal security audit on their software.

I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?

I absolutely guarantee they undergo regular formal security audits. There's no question.

> So we install it on hardened bastion hosts in an old-school "jump host" model. So people can still get access to where they need to be, but we don't need to install Tailscale's unaudited shit on every single server / vm / etc.

Bastion hosts are a terrible model in 2026. I can't take this approach seriously.

> we don't need to install Tailscale's unaudited shit on every single server / vm / etc.

You never need to do this. Simply create an exit node into your subnet, and everything you want becomes routable.

It sounds to me like your architecture struggles with a zero-trust network approach if you view this as a blocker. I've got some slots available if you need a consultation!

> In terms of SSH, we use old-school OpenSSH and SSH certificates. Its really not that difficult and its really not expensive, you can do offline signing with Yubikeys, no need for expensive HSMs.

It's expensive in terms of engineer-hours, especially compared to Tailscale. It's also easy to get wrong, and end up with the same vulnerability as TFA, or worse.

But my main issue is that if you see this as equivalent it's telling me that you're not really the target audience. Your set-up is far more vulnerable than the out-of-the-box experience you get with Tailscale. If you don't mind, then I'm happy for you.

Lastly, I don't work for Tailscale and I'm not affiliated with them in any way beyond being a happy user that has solved a lot of problems very easily with their product. I highly recommend it to practically everyone. It's great.

I'm having a hard time taking your comment seriously. It just seems like non-constructive FUD.

[traceroute66]

> I absolutely guarantee they undergo regular formal security audits. There's no question.

Well, they clearly don't if they have an "insecure argument handling" vulnerability.

As others here have said already here, its an "venerable and ancient class of bugs".

Its the sort of thing that should be picked up by modern defensive programming that includes fuzz testing.

And it is CERTAINLY the sort of thing that should be flagged by any competent security audit. "insecure argument handling" is bread-and-butter for security auditors.

> I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?

SOC2, ISO27001 and all that shit is not the same thing.

As I said, anyone serious who is proud of having had their software audited as clean would publish their reports in public. Nothing to hide. And it strengthens your case with customers.

It can always be a suitably redacted management summary written by the auditor. That's what everyone else does.

[greengreengrass]

>> Or inspect their SOC2 documents?

> SOC2, ISO27001 and all that shit is not the same thing.

Hard agree. SOC2/ISO27001 are a thing that might be useful, but are mostly a framework dreamt up by auditors and other people who like wearing suits (and making lots of money).

They have some normative controls. But a SOC2 audit is not going to survive contact with an engineer who can push code and whose job depends on the company they work for making money. Where they have to ship product features, and don't have weeks to justify every line of code they write.

A SOC2 audit is not going to survive contact with a script kiddie in their bedroom (or, a nation-state APT) who has plenty of time and an LLM to help them find vulnerabilities or weird edge cases they can compose to attack a system.

These frameworks might serve a purpose, but corporate 'compliance' departments have been lulled into a false sense of security that a satisfactory SOC2 audit means the product is secure and obviates them from asking more technical details or for a fuller audit. It's not. That doesn't matter in a lot of cases, but probably does for a network security solution - I would absolutely be asking deeper questions if I was deploying any of these products en masse.

But then again, the insurers probably asked for a SOC2 certificate, so I guess like most things in life, it's not about whether the systems are secure - it's about whose insurance is ultimately covering the loss.

[xyzzy_plugh]

Have you tried asking them for a copy of such a report? Or is your plan to just continue complaining until they make one public?

The finding in TFA was the result of a security audit.

[cyphar]

As an open source maintainer of a fairly large project, we get reports from Ada Logics and similar firms every once in a while and those are absolutely not the same as a proper security audit (which we've also had commissioned in the past). Reports are just a description of a particular issue, not the deeper analysis of the general structure of the codebase that you get from a good audit.

[traceroute66]

> The finding in TFA was the result of a security audit.

Don't you fucking dare.

Might I point you to the words "We would like to thank Anthropic and Ada Logics for reporting this issue.".

It was not commissioned by Tailscale. It was DONE BY OTHERS AND REPORTED TO TAILSCALE. Just like the fucking disclosure tells you.

Tailscale should not be relying on the random goodwill of others to do random audits of unknown coverage at random intervals.

That is not a serious approach to security.

They should be commissioning their own, paid out of their own pocket, at regular intervals, and publishing the results.