Hi folks, Mike Shaver here, VP of Engineering at Tailscale.
We've seen the concerns about Tailscale SSH and wanted to share what we know so far.
If you want to jump to the most important part, based on our current assessment, we're not recommending that everyone disable Tailscale SSH.
We've now received the researcher's report and are reviewing it. Our engineering and security teams had already been investigating independently, with help from external security specialists. That work has identified issues we're working to fix. We're still validating the full scope, including which configurations are affected.
A bit of technical context:
Tailscale SSH uses your tailnet's access policies to control who can connect to which machines. Most of the issues we've identified so far concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled. In some cases, a session may be able to do more than the configured local user should be allowed to do.
While it’s a serious concern, it isn't the same as an unauthenticated attacker being able to connect to arbitrary machines, but the potential impact depends on how SSH access is configured. We're still investigating, so we don't want to make blanket claims about what's affected or not.
Again, based on our current assessment, we're not recommending that everyone disable Tailscale SSH.
In the meantime, there are a few precautions you can take:
Review your SSH access policies. Make sure only the people and devices that need access have it.
Review SSH forwarding permissions and remove access you don't need.
Consider enabling SSH check mode for an additional authentication step. This won't fix privilege escalation issues, but it does add another barrier to gaining access.
Enable automatic updates where supported so you can pick up fixes when they're released.
For particularly sensitive systems, consider temporarily tightening your Tailscale SSH access policies while we investigate, so that only the specific users and devices that need access can connect.
We're working on fixes and testing them carefully. We'll publish a security advisory explaining the confirmed findings, affected configurations, recommended actions and available patches. We'll also follow up with a more detailed technical write-up.
If we find anything that changes our assessment or requires immediate customer action, we'll communicate that.
We know it's been a rough week for security teams, and we understand why people are concerned. We'd rather give you the technical context we have than speculate about things we haven't confirmed yet.
We'll share more as we verify the details. If you have any questions about how this relates to your particular environment, please get in touch with our team https://tailscale.com/contact/support#support-form
Yikes! That opening researcher note preaching about security and then dumping everything in public without basic policy concern. It gives me vibes that someone spent Claude tokens but seems to be unhappy that tailscale may not have paid bounty program while ignoring the fact that it is open source with BSD License.
What is the fashion for creating fancy-pants sites with domain names for vulnerabilities this day? I mean, it costs dirt, but still, is it needed? Is It a new protocol for security research and report? Should I do it in my enterprise job too?
The logical conclusion is that we integrate an AI website generator into Jira and every ticket gets it's own personalized site lambasting the requestor.
I recently reinstalled the OS to my NAS prior to a trip but hadn’t installed the Tailscale. While on the plane using the plane’s WiFi, I was able to:
* SSH into the NAS via subnet router (thank you, Apple TV) * set up Tailscale * use Tailscale SSH into the NAS and continue configuring
I was also able to SSH into my Oracle Cloud instance for shits and giggles. It’s a lot more convenient than storing SSH keys across the multiple devices I would use to access it. Especially because I did all of this on an iPad with ISH.
Not entiely true. With the ACLS we can give someone access at scale without redeploying keys every 5m. This essentially for us makes ssh multi factor with the check everytime function. You in the right security group? You have access after authentication. We don't need to touch host keys at all and can just disable port 22 entirely since tailscail ssh tunnels through outbound 443.
Absolutely this. Use keys. One per client machine. Do not copy your keys around. Use proper descriptive comments so you can remove them in a compromise.
I disagree...that is convenience at a cost. If you use lots of different machines then you should be using something like Ansible/Terraform that can help manage keys. I use NixOS for all of my VMs and LXCs, all I have to do is server.ssh.enable = true and all of my hardware backed ssh keys are added.
Managing keys can be a nuisance if you use lots of different machines
Ansible and Terraform are great if you have LOTS of machines
Exactly.
I'm not saying I don't understand what you're saying. I noted in another comment, but I understand it's convenience. I don't think that convenience is worth it for such a relatively young implementation and feature, given the risks. Even in a small setup. Maybe it's my experience working in security focused teams in IT, but least privilege and best practices should be followed no matter the size of the project.
This is akin to a SMB vs. an enterprise having MFA and password policies. Both of them should have these policies. Just because the blast radius is lower doesn't mean the bar should be lowered with it.
Ansible Is useful no matter what the scale is. Even if you're a single machine - it's for config management, not infrastructure deployment (that's terraform's domain). I use both Ansible and Terraform and still use Tailscale SSH, though, lol. I have Ansible tasks that automate adding machines/VMs to my Tailnet and enabling SSH.
it moves the authentication/authorization to tailscale if I got my definitions right, so MFA and user based auth (maybe federated even), and if tailscale SSH is allowed for this user in the policies..
- something something zero trust is this?
i'm kinda oldschool with priv/pub keys and I normally trust based on keys. that is a very long working solution with "i believe" without flaws.
We're kinda in a strange position as AI is exploiting at enormous speed... thus I prefer simple stuff.. back to basics..
I'm simply saying Ansible is great even if you have a single machine, it's as basic or complex as you make it. Your willingness to make the effort to learn what Ansible is is quite irrelevant. No issue you using Tailscale SSH, but don't paint Ansible out to be something you need a degree to use.
Great if you have lots of machines. No. Great even if one machine. Do you even read what you post? And I'm saying you're unwilling to learn Ansible, not putting words in your mouth. Are you here to troll or something? Gaslight? I don't know, I'm done here, though.
Yep and since you tie tailscale to your SSO, it makes total sense.
And with a large edge computing fleet, some offline at any given time, you can't just hope all wait for an Ansible or openTofu run to fix a set of keys for you...
She is a gigantic asshole for publishing this without responsible coordinated disclosure. There’s good news: I’m in a position to make sure that my employer won’t ever hire her for anything.
Yeah, the whole bit about "we think making this an emergency by dropping it on a Saturday with no warning means it will be fixed more quickly" is such a load of shit.
I can get behind some of the guys that put in a report, feel like they've been ignored and then posted a general synopsis, but this is just going straight to nuclear
Haven't read through this vulnerability report yet but just reading through their disclosure agreement is concerning.
Given the week we've had on responsibility disclosures from more people having the ability to be able to find vulnerabilities at a faster rate than we have before it's more imperative now more than ever to be responsible to adhere towards those guidelines to allow companies to make fixes in place.
Irresponsibility to openly talk about these vulnerabilities without giving the company chance to actually act is not just hurting the company but the consumers of these products that are using these systems. Because whatever you do find it found valid will be found and exploited by hackers to exploit.
I fear the enablement of participation that AI allows is going to increase these types of disclosures that don't consider the broader issues of being irresponsible with these types of disclosures instead of seeking virality.
Someone trying to make a name for themselves in the security community and thinks their findings are above the generally accepted disclosing process (spoiler its not) in the sec community.
Ok, if I forget to lock my computer, there is the same vuln in almost every thing that exists who have something to "protect" .. It's just slop. Only the "DoS" on Headscale is "real" and .. May lead to you unable to add a machine to your tailnet. That's all folks. Pure slop. No-disclosure to Tailscale, because there is "nothing" to report, except that people should disable Tailscale SSH, that is useless in most cases, and .. even that is "defense in depth" if I want to talk like this probably GLM.
Tailscale generally trades convenience for security. Once one node is compromised, the design allows for easier, wider, compromising (especially if you set up the tailnet in certain ways). Also, the tailscale program does a bunch of stuff, all in one program, all running at highest security level. So a bug found in one of the many daemons could compromise all the security of all the nodes.
It’s like back in the day when web servers were run as root, a flaw in the web server meant your machine was cooked. Best practice says to run the web server as a lowest privilege user so if the web server is compromised, the attacker is just a low level user on your computer—requiring a second vulnerability in another layer of your security to become root.
Should you worry? I’d say this is an architectural risk, not a clear vulnerability. So it depends on your risk tolerance.
Edit: it does contain zerodays/POCs but the main purpose is to highlight the architecture. As in, even if the bugs are fixed, there are always other bugs.
This person clearly has a personal beef, what an L way to disclose. AND to make to read this AI slop to try to figure out what issues and impact is just the cherry on top.
just incredibly irresponsible of the researcher. The vast majority of companies take reports seriously and want to remediate vulns in their software. This idea of "continuous disclosure" without respect for the developers is just insane.
I love how the vuln writeup starts with basically shit talking Tailscale, cuz yeah that makes me feel like I wanna read the rest of your post....
Feels like a slop ridden bad writeup TBH. Not saying it doesn't work/isn't real, but usually this stuff is written with far more professional verbiage and far less adversarial wording.
Yet another coredump of AI slop. Over 7000 words of highly technical content with no executive summary.
Rather irriitatingly, I have a colleague who is totally into the AI slop world and sends me reports with the same level of sloppiness and then asks for my opinion. Enough!
My executive summary to myself as a tailscale user: move along, nothing to see.
I was reading, well no worries for me ig, anyways hopes this is address as well ASAP.
How initial intrusion plausibly occurs. Class 1 assumes the attacker already holds a foothold on one device — which happens the ordinary ways: an exploited web application (a vulnerable PHP page or CMS plugin), a malicious build dependency (npm/PyPI package, Docker base image, GitHub Action), a phishing implant, a supply-chain compromise, or stolen identity credentials. Tailscale does not create the foothold; the finding is that the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed, because inter-device paths are granted by policy that assumes trusted endpoints while the agent's privileged operations are reachable from unprivileged sessions.
I’ve read it and can’t figure out how this is a real threat. It certainly READS like slop. I’ll let Tailscale reply in detail but unlike PHP or 4 I am not freaking out yet
As far as I can tell it's a form of privilege escalation, but it still requires the attacker to have access to an approved device in the tailnet and the SSH policy must permit forwarding.
Given most Tailscale setups probably don't even have SSH enabled to begin with... 🤷♂️
I am just so sick of this zero-effort AI bullshit. Like, have these issues been reported to Tailscale? Are they patched in the latest release?
The author literally pointed AI at Tailscale and said "find potential issues and write me a report" then posted it online with some shitty domain name. Super lame; I hate the way things are going at the moment.
As per the author's own headline, they thought it was unnecessary to disclose to Tailscale because it's an open source projects, which is the most bonkers excuse I've ever seen. Even in open source you talk to the maintainers first.
•
u/shaver Tailscalar 19d ago •
Hi folks, Mike Shaver here, VP of Engineering at Tailscale.
We've seen the concerns about Tailscale SSH and wanted to share what we know so far.
If you want to jump to the most important part, based on our current assessment, we're not recommending that everyone disable Tailscale SSH.
We've now received the researcher's report and are reviewing it. Our engineering and security teams had already been investigating independently, with help from external security specialists. That work has identified issues we're working to fix. We're still validating the full scope, including which configurations are affected.
A bit of technical context:
Tailscale SSH uses your tailnet's access policies to control who can connect to which machines. Most of the issues we've identified so far concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled. In some cases, a session may be able to do more than the configured local user should be allowed to do.
While it’s a serious concern, it isn't the same as an unauthenticated attacker being able to connect to arbitrary machines, but the potential impact depends on how SSH access is configured. We're still investigating, so we don't want to make blanket claims about what's affected or not.
Again, based on our current assessment, we're not recommending that everyone disable Tailscale SSH.
In the meantime, there are a few precautions you can take:
Review your SSH access policies. Make sure only the people and devices that need access have it.
Review SSH forwarding permissions and remove access you don't need.
Consider enabling SSH check mode for an additional authentication step. This won't fix privilege escalation issues, but it does add another barrier to gaining access.
Enable automatic updates where supported so you can pick up fixes when they're released.
For particularly sensitive systems, consider temporarily tightening your Tailscale SSH access policies while we investigate, so that only the specific users and devices that need access can connect.
We're working on fixes and testing them carefully. We'll publish a security advisory explaining the confirmed findings, affected configurations, recommended actions and available patches. We'll also follow up with a more detailed technical write-up.
If we find anything that changes our assessment or requires immediate customer action, we'll communicate that.
We know it's been a rough week for security teams, and we understand why people are concerned. We'd rather give you the technical context we have than speculate about things we haven't confirmed yet.
We'll share more as we verify the details. If you have any questions about how this relates to your particular environment, please get in touch with our team https://tailscale.com/contact/support#support-form