With the success of Tailscale I would like to be sure that their repositories and scenarios are continuously reviewed. I understand that there is always a next hop in cybersecurity though.
_def · 2026-10-27 20:12:34 UTC
I think it's so invasive that they ship this per default. But thats the business model i guess.
How do you mean? You have to run a command to enable tailscale ssh, it isn't on by default.
seemaze · 2026-10-27 20:23:26 UTC
I've always had to manually enable this feature. I've never experienced it on by default across multiple platforms and deployments.
RobMurray · 2026-10-27 21:44:35 UTC
I've never used it once. don't even see the point. normal ssh works fine over Tailscale.
What is the advantage? Why would I want to swap the well tested auth in ssh for auth managed by tailscale?
LeoPanthera · 2026-10-27 20:25:15 UTC
Tailscale SSH is not enabled by default.
zer0zzz · 2026-10-27 21:14:10 UTC
It’s also not even available on some platforms afaik
6thbit · 2026-10-27 20:19:44 UTC
> Most of the Tailscale SSH issues we've identified concern privilege escalation. In some circumstances, someone already authorized to connect over Tailscale SSH may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges.
"Most"? "In some circumstances"?
Makes me think that they could also be investigating a full on unauthorized connection issue, or am I reading too much into it?
I think they're just writing cautiously because they're midway through the investigation and don't want to give false confidence. Doesn't seem worth reading too much into it until they provide a more thorough write up.
devmor · 2026-10-27 20:40:06 UTC
A security researcher colleague of mine was/is exploring an unauthenticated avenue along this line. I don’t have any update, she told me she didn’t feel comfortable exposing information to anyone other than Tailscale staff until she’s confident in what she found or didn’t.
raggi · 2026-10-27 21:43:50 UTC
we'd love to hear about it at security@tailscale.com, we're happy to work from & with and credit early ideas as well.
pizzafeelsright · 2026-10-27 20:40:57 UTC
Obviously tailscale has some great devs, security is complex.
There is some weaselly language.
In some circumstances default config? with password? this is a condition leading to the next
someone already authorized to connect over Tailscale SSH they have access, but it may be limited or restricted, although scope could be beyond the intended
may be able to perform actions beyond the permissions If there is a full moon and your brother in law's second cousin is wearing a hat, he may be able to use your upstair's thermostat provided you have a second story.
fooqux · 2026-10-27 21:17:23 UTC
Given what just happened with PHP a few days so, it's not surprising to me that they're holding their cards close to their chest. People will already be doing their damnedest to reverse engineer the exploit with this meager info.
traceroute66 · 2026-10-27 21:29:35 UTC
> Obviously tailscale has some great devs, security is complex.
Quick reminder that in recent months Tailscale has had issues with age-old classic vulnerabilities such as input validation.
The problem with Tailscale is twofold.
First their attack surface is too big. They continuously shoehorn new features into the product.
Second they don't appear to do regular deep-dive code audits and instead they appear to rely mostly on the goodwill of third-parties to poke at select areas of their code as and when those third-parties feel like it. Hence simple vulnerabilities such as input validation keep on popping up.
Fancy SOC2 certificates are not the same thing. That's just dogfood for the corporate auditors.
At $work we are busy working on removing Tailscale. The bells and whistles of Tailscale sure are attractive candy, but we simply can't overlook the security risk of what has become a bloated product.
p_l · 2026-10-27 22:06:13 UTC
Have you seen the slopreport for the vulnerability?
I fully understand being carefully worded when you need serious brain power just to figure out every claim in the logorrhea
If you use Tailscale SSH with headscale you are also affected. The vuln is in tailscaled, not the control plane / netmap.
wrxd · 2026-10-27 20:36:12 UTC
I like Tailascale as a product but I decided to move my homelab to plain WireGuard.
I wasn't using any of the additional features, I can get away with exposing a port on my router and I am changing devices rarely.
News like this make me happy I removed a lot of complexity and attack surface
fooqux · 2026-10-27 20:37:53 UTC
From the sounds of what info they felt was safe to provide, this wouldn't have impacted you anyway.
giwook · 2026-10-27 20:55:49 UTC
Don’t think that refutes their point.
femiagbabiaka · 2026-10-27 20:57:15 UTC
> I can get away with exposing a port on my router
using wireguard is awesome, but I wouldn't say deploying and maintaining it lacks complexity exactly. and you didn't get rid of attack surface, you just made it your responsibility ;)
swingandamiss · 2026-10-27 21:02:57 UTC
With AI, the complexity doesn't really matter anymore. Codex or Claude can easily configure complex site-to-site setups and peer configurations on mobile devices. I did this by hand before and it was hard and difficult to get right. Now I just tell AI and it does so perfectly, checks and verifies things. AI made life so easy.
femiagbabiaka · 2026-10-27 21:07:41 UTC
I would not personally expose my devices over a VPN that I self-hosted and set up purely through AI unless I felt like I understood how it worked completely. But that's probably just personal paranoia.
swingandamiss · 2026-10-27 21:20:24 UTC
Just go read reddit threads on people who do this by hand following half baked guides. There's a huge population doing this, now everyone is switching to AI. It's a big win and safer. Not everyone is a trained network engineer, but now they are with AI
arcanemachiner · 2026-10-27 21:08:17 UTC
This is true, but I still wouldn't discount the possibility of mistakes. It's good to know how your home network works. Even Opus 5.5 can make some pretty dumb mistakes, particularly if it doesn't have the full picture.
swingandamiss · 2026-10-27 21:19:16 UTC
Humans also make mistakes. At this point, I trust AI more than humans when it comes to casually configuring VPNs. I've read many who exposed things by mistake on reddit. AI has nearly solved this, probably is a solved issue at this point.
drum55 · 2026-10-27 21:10:38 UTC
No amount of claude can handle the key thing that Tailscale fixes about wireguard, all of the connection to connection logic is handled be it direct, via all sorts of weird hole punching or via relays. Wireguard itself is horrible to do this with, half the time you're just looking at `wg status` wondering why the packet counter isn't incrementing today. It can never achieve the magic that is a direct connection between plane wifi and a host that's behind NAT on the ground.
hdgvhicv · 2026-10-27 22:41:25 UTC
I can’t think of a single time I’ve wanted to connect between two hosts when I haven’t specifically allowed one through a firewall
drum55 · 2026-10-27 23:08:52 UTC
NAT are not firewalls.
LeBit · 2026-10-27 22:32:56 UTC
It makes no sense at all to configure a >3 nodes wireguard setup with straight wireguard.
Wireguard is the building block for higher level tools like Tailscale to build on.
LoganDark · 2026-10-27 21:06:39 UTC
Attack surface almost entirely goes away if you just require a good port knock first! I do that with my protection SSH servers and it works just fine. Also prevents anyone from knowing there even is an SSH server there. Or any server if it doesn't respond to pings either, and only uses reverse tunnels to accept public connections
mbreese · 2026-10-27 21:11:20 UTC
Is there a way to automate port knocks in your .ssh/config? I think that’s the main reason why I haven’t added it to my home server.
LoganDark · 2026-10-27 21:25:45 UTC
Technically you could use a ProxyCommand that does the knock and then runs nc to your target.
lakeviewterrace · 2026-10-27 21:12:20 UTC
Port knocking is idiotic and amounts to Biff Tannen's "only I know how to start this car".
Gigachad · 2026-10-27 21:25:31 UTC
Dunno, in combination with having an up to date system following best practices, port knocking is probably going to save you when bots start scanning the internet with the next SSH 0day. Any amount of friction will cause the bots to move to the next IP address.
esseph · 2026-10-27 21:29:20 UTC
LLMs port knock for redteam scans. Have for a long time.
LoganDark · 2026-10-27 21:42:36 UTC
My knock for SSH was 20 ports within 2 seconds. knockd resets the sequence if you hit any of its ports out of order. I generated the sequence with a CSPRNG.
icedchai · 2026-10-27 21:31:19 UTC
Just moving SSH off a default port gets you 98% there.
LoganDark · 2026-10-27 21:33:36 UTC
An attacker only has to get lucky once, so while I do put SSH on a non-default port too, it's not enough to avoid attacks on its own.
icedchai · 2026-10-27 21:57:37 UTC
I mostly do it to quiet down the noise from the non-stop bots and scanners.
LoganDark · 2026-10-27 22:24:56 UTC
Being off the IPv4 space completely can be even more effective at that, FWIW, but that can have other issues. Only feasible for some!
LoganDark · 2026-10-27 21:49:01 UTC
It's more like "only I know how to find this keyhole". You still need the key then, you're just also adding some defense against picking.
It would be idiotic to use the knock as the only authentication, which is why I don't.
To be quite honest, I just like the aesthetics of it.
neilalexander · 2026-10-27 21:28:26 UTC
Wireguard doesn’t respond to malformed packets or handshakes from unknown devices by design.
LoganDark · 2026-10-27 21:39:59 UTC
Oh, awesome!
ectospheno · 2026-10-27 21:16:10 UTC
Always is your responsibility even with tailscale. Now it is his responsibility without tailscale.
F_r_k · 2026-10-27 21:20:28 UTC
BTW, netbird is a cool alternative also
OptionOfT · 2026-10-27 22:38:23 UTC
On the road I find WireGuard to be quirky when connecting to DNS names. When I'm on an IPv6 only network (like T-Mobile), connecting to a DNS name that offers A and AAAA, WireGuard on iOS prefers the A record, making me connect over one of T-Mobile's 464XLAT proxies which time out after x minutes. This then makes the connection look dead until I do something on my phone that re-enables it.
Tailscale doesn't have this issue.
LeBit · 2026-10-27 22:38:38 UTC
You shouldn’t open a port on your router.
Connect from your home to a public VPS and connect your public devices to that VPS.
aborsy · 2026-10-27 20:43:17 UTC
There are too many features, and lines of code (probably more than OpenVPN). I'm pretty sure there are all kinds of zero days in it, with this attack surface and feature set.
I use it extensively, and I would rather pay them a fee if they could review thr code.
A possibility is a lock down mode, disabling risky features.
I just want a VPN for connrctiviy, no taildrop, taildrive, SSH, funnel, services, DNS, node sharing, ...They are disabled in my admin console, but the code runs on my devices and they can be enabled by mistake.
A question. Taildrop enables unauthenticated input and doesn't even obey ACLs. I'm not quite sure about this, but couldn't malware in a low trust device send a file to my Synology NAS, which will then automatically process it for indexing things like thumbnail, leading to potential code execution? Why doesn't it obey ACLs, and why isn't the recipient approval needed before the file exits the sender's device? I use tags, but I'm the owner not the tag.
drdexebtjl · 2026-10-27 21:28:58 UTC
This is also how I feel about Tailscale and its popular alternatives. They do too much.
Does anyone know of a Tailscale alternative that sticks to the basics?
Something that’s just WireGuard but without the manual key exchange, and with Tailscale-like NAT hole-punching that falls back to using an oblivious relay?
chasd00 · 2026-10-27 22:21:15 UTC
You could just use IPsec. It’s been probably 20 years but look into SWAN. It’s just a vpn in the vpn sense.
sigbottle · 2026-10-27 22:27:32 UTC
I've been toying around with nebula, self host your lighthouse on a cheap VPS (which even if it gets hacked, the most it can do is lie about traffic, not lie about node certs). Basically you're just paying for the punchthrough (you may even be able to do some duckdns shenanigans?) The main issue is that updating nodes is a pain in the butt, which is the main advantage of tailscale IMO - centralized control plane. Keeps it simple.
I was trying to do some kind of insane workflow where you as the operator have a privileged hardware yubikey that admins the nodes when you plug it in, and the point is the nodes would self-propogate the changes outwards. I immidiately ran into classic issues with distributed security in distributed systems (even with only one central operator trying to admin everything). Tailscale is also a bit more secure in its oauth layer - with this architecture, you need to set proper time limits for expiring so one node compromise doesn't get access to the whole fleet. Couldn't really come up with better ideas than forcing the operator to reuse some kind of hardware key (the idea trying to be avoiding maintaining a cloud control plane as much as possible)
Fun foray but creating such a system requires a lot of expertise that I unfortunately lack
LeBit · 2026-10-27 22:36:53 UTC
I used Nebula extensively.
I really liked it. I like the idea of embedding firewall rules in a certificate.
But , like you observed, it does not scale as well as tailscale.
LeBit · 2026-10-27 22:35:41 UTC
No.
{tail,head}scale is the best there is for wireguard at more than 3 nodes.
skowalak · 2026-10-27 22:54:50 UTC
Re: Your question. Taildrop only works between devices in the same account. So if you don't put low trust devices in the same account as your NAS this is mitigated.
MisterTea · 2026-10-27 21:05:19 UTC
Not a tailscale user so I am a bit lost here: where does SSH fit into a Wireguard based VPN service?
jubilanti · 2026-10-27 21:06:56 UTC
As added candy to their daemon to get you into their ecosystem
Everyone is twitchy over security right now, but at first glance this seems not that bad. If the attacker has to be manually added to your tailnet that makes this not very exploitable. You should be more worried about all the iot slop on your local network.
Good idea to set up automatic updates for the tailscale client though.
rietta · 2026-10-27 21:33:51 UTC
I am fairly glad I have stuck with stock OpenSSH that ships with Linux. This incident proves I am glad with that choice.
Over the decades, I have maintained remote access through port forwarding on my router - at one point in 2008 I put SSH on port 80 so I could access it from the restricted wifi network at the hospital my grandmother was at. I have also used openvpn. I have also used cloudflare tunnels. But in the end, I always connect to hardened openssh with key only authentication.
LeBit · 2026-10-27 22:30:19 UTC
Doing ssh through port 80 or 53 or 443 is immediately flagged.
I understand port 443 is always opened but nowadays you can’t just run ssh traffic on 443 without it being detected as not being https
octoberfranklin · 2026-10-27 22:31:23 UTC
Flagged by who? The Internet Police? This comment is absurd.
novafunc · 2026-10-27 22:39:18 UTC
By restricted networks, like hospitals, workplaces, schools, etc.
If their firewalls can detect it not being typical http/s traffic, they can block it.
minimaltom · 2026-10-27 22:33:21 UTC
I'm with you- the attack surface of openssh (and my trust in damien) is a better match imo
minimaltom · 2026-10-27 21:35:02 UTC
Former tailscalar here and now someone managing tailscale at an org.
Having done my own review of the vulns and the fixes as they are landing in github, its pretty clear to me that this only affects situations where you use ACLs to permit ssh into a node (via tailscale ssh, not via opensshd), but dont give a path to sudoers/root.
If a user had no SSH access and/or connectivity to a vulnerable node, none of these vulns give them access.
However, if you have a vulnerable tailscaled and you give ssh access as some non-root account/privs, then yes, these vulns are relevant as theres now known privilege escalations that give access beyond some specific user account.
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.
dennysora-main · 2026-10-27 21:49:04 UTC
But a large portion of Tailscale users should be software engineering professionals, so a lot of the time, people use Tailscale just for SSH. I personally feel the impact is still quite big, especially since SSH leads directly to control of the server.
stingraycharles · 2026-10-27 21:59:00 UTC
Engineers use vanilla SSH for SSH, Tailscale SSH is more focused on enterprise stuff where you can have an audit trail of all commands executed and enforce ACLs.
minimaltom · 2026-10-27 22:01:37 UTC
Do you use tailscale ssh but either dont have sudo, or don't permit login as root?
If all your tailscale-ssh ACLs allow you into an account with sudo, or allow you into root, theres no impact (you cant do anything with these vulns you couldnt do a month ago). Thats the nuance I'm trying to get across (admittedly my english is bad).
lambda · 2026-10-27 22:51:10 UTC
On the majority of nodes I provide Tailscale SSH access to, it's as root or a user with passwordless sudo. It's being used for admin access. So yeah, on those it doesn't matter as much.
There are a handful which restrict users to their own user accounts. But it's on dev server with friendly devs, so even for that use case it's not really the end of the world.
I'm sure our infosec folks are going to demand that we upgrade everywhere, however.
randomblock1 · 2026-10-27 22:14:39 UTC
Tailscale SSH is different than doing SSH with Tailscale
lifeisloving · 2026-10-27 22:19:18 UTC
I use tailnet as a vpn and ssh into my server via the tailnet, but I dont use tailscale ssh the product. I think most people fall into this bucket.
Of course it should be taken seriously, but this topic is also piggy backing off of 7 days straight of non stop viral engagement farming on X after php2shell, where people we're farming likes by just posting stuff like
"YoU ThInK PhP2ShELl iS BaD JuST WaIt unTiL TaIlScAlE get HaCkED, ThIS JuSt ThE BeGiNNiNG oF a CybeR ReCKoNiNG"
To farm FUD from normies. Which of course led researchers who were working on tailscale vulns to take advantage of that algorithmic attention as well and talk about their research.
Like Im pretty sure we knew about this vuln for 3 days now, or atleast that it was responsibly disclosed (and not being used in the wild).
The attention this is getting is definately the product of some cringe viral snowball effect of the also rather benign p2pshell vuln.
It feels like there's a ton of AI influencer astroturfing going on, because its wildly easy to get engagement when you add the words "agent/ai" with "vulnerbility" and [insert popular service].
scoodah · 2026-10-27 22:21:11 UTC
I’ve used tailscale in quite a few jobs now and not one have we used tailscale ssh. Call us old school or whatever but at my current place of employment we provision ssh keys on a box with ansible and just use regular old ssh over the tailnet, not tailscale ssh
aborsy · 2026-10-27 22:14:59 UTC
I backup my different devices to my NAS. The user is a restricted backup user seeing only their own directory. I obviously don't want my torrent computer gets root on my NAS.
I personally use openssh, but someone else may use tailscale SSH.
whywhywhywhy · 2026-10-27 23:01:52 UTC
Calling it “tailworm” feels like alarmism to promote their find more.
Would only show worm behavior if machines within the tailnet had the right settings and also were members of other tailnets with those settings but then it would require someone in that tailnet to have another tailnet with the right settings…
It’s far fetched.
hollow-moe · 2026-10-27 21:39:00 UTC
Recently NetBird also had a huge privesc through their SSH component too...
I'm using both at $DAYJOB and my personal infra, damn you guys ought to be more careful with such a sensible and important component...
siva7 · 2026-10-27 22:02:41 UTC
I wouldn't be too surprised if tailscale has become a critical vector of the internet like cloudflare over the years as most ai companies seem to use it
SchemaLoad · 2026-10-27 22:38:26 UTC
Tailscale is best used as an additional layer of security rather than your only layer. I host everything behind tailscale as if it was the public internet, with proper authentication, https, etc.
So a failure in tailscale is not an issue on it's own because you'd then also have to find an exploit in what I'm actually hosting as well. Both of those things happening at the same time is much less likely.
TacticalCoder · 2026-10-27 22:04:40 UTC
I'll point out that Tailscale has been repeatedly praised here as a replacement "because SSH was too old" by "security professionals". Those very same security professional happen to be the exact same closing their eyes when there's the state doing wrongdoings.
My question to those who kept praising Tailscale and making fun of good old plain SSH: how do you like your state backdoor --excuse me, I mean bug-- in Tailscale now?
LeBit · 2026-10-27 22:42:07 UTC
You use ssh to manage a multi node VPN?
mediaman · 2026-10-27 23:04:36 UTC
This comment doesn't make any sense. The products are mostly different categories. One is a VPN replacement and the other is encrypted shell access. Most people use ssh over tailscale. Tailscale does have a "Tailscale SSH" product but it's not that widely used compared to regular ssh over Tailscale.
andix · 2026-10-27 23:01:48 UTC
Somehow I don't think it's a good idea to let Tailscale handle service authentication at all. It's supposed to be an additional security layer around existing infrastructure and services.
Letting Tailscale handle VPN and SSH at the same time is basically once again a single point of failure. Similar to exposing SSH directly to the internet.
Comments
What is the advantage? Why would I want to swap the well tested auth in ssh for auth managed by tailscale?
There is some weaselly language.
In some circumstances default config? with password? this is a condition leading to the next
someone already authorized to connect over Tailscale SSH they have access, but it may be limited or restricted, although scope could be beyond the intended
may be able to perform actions beyond the permissions If there is a full moon and your brother in law's second cousin is wearing a hat, he may be able to use your upstair's thermostat provided you have a second story.
Quick reminder that in recent months Tailscale has had issues with age-old classic vulnerabilities such as input validation.
The problem with Tailscale is twofold.
First their attack surface is too big. They continuously shoehorn new features into the product.
Second they don't appear to do regular deep-dive code audits and instead they appear to rely mostly on the goodwill of third-parties to poke at select areas of their code as and when those third-parties feel like it. Hence simple vulnerabilities such as input validation keep on popping up.
Fancy SOC2 certificates are not the same thing. That's just dogfood for the corporate auditors.
At $work we are busy working on removing Tailscale. The bells and whistles of Tailscale sure are attractive candy, but we simply can't overlook the security risk of what has become a bloated product.
I fully understand being carefully worded when you need serious brain power just to figure out every claim in the logorrhea
> Organizations using headscale v0.29.5 have no mechanism to disable the forwarding behavior at the center of the finding.
https://techjacksolutions.com/scc-vendor-rollup/tailscale-he...
I wasn't using any of the additional features, I can get away with exposing a port on my router and I am changing devices rarely.
News like this make me happy I removed a lot of complexity and attack surface
using wireguard is awesome, but I wouldn't say deploying and maintaining it lacks complexity exactly. and you didn't get rid of attack surface, you just made it your responsibility ;)
Wireguard is the building block for higher level tools like Tailscale to build on.
It would be idiotic to use the knock as the only authentication, which is why I don't.
To be quite honest, I just like the aesthetics of it.
Tailscale doesn't have this issue.
Connect from your home to a public VPS and connect your public devices to that VPS.
I use it extensively, and I would rather pay them a fee if they could review thr code.
A possibility is a lock down mode, disabling risky features.
I just want a VPN for connrctiviy, no taildrop, taildrive, SSH, funnel, services, DNS, node sharing, ...They are disabled in my admin console, but the code runs on my devices and they can be enabled by mistake.
A question. Taildrop enables unauthenticated input and doesn't even obey ACLs. I'm not quite sure about this, but couldn't malware in a low trust device send a file to my Synology NAS, which will then automatically process it for indexing things like thumbnail, leading to potential code execution? Why doesn't it obey ACLs, and why isn't the recipient approval needed before the file exits the sender's device? I use tags, but I'm the owner not the tag.
Does anyone know of a Tailscale alternative that sticks to the basics?
Something that’s just WireGuard but without the manual key exchange, and with Tailscale-like NAT hole-punching that falls back to using an oblivious relay?
I was trying to do some kind of insane workflow where you as the operator have a privileged hardware yubikey that admins the nodes when you plug it in, and the point is the nodes would self-propogate the changes outwards. I immidiately ran into classic issues with distributed security in distributed systems (even with only one central operator trying to admin everything). Tailscale is also a bit more secure in its oauth layer - with this architecture, you need to set proper time limits for expiring so one node compromise doesn't get access to the whole fleet. Couldn't really come up with better ideas than forcing the operator to reuse some kind of hardware key (the idea trying to be avoiding maintaining a cloud control plane as much as possible)
Fun foray but creating such a system requires a lot of expertise that I unfortunately lack
I really liked it. I like the idea of embedding firewall rules in a certificate.
But , like you observed, it does not scale as well as tailscale.
{tail,head}scale is the best there is for wireguard at more than 3 nodes.
Good idea to set up automatic updates for the tailscale client though.
Over the decades, I have maintained remote access through port forwarding on my router - at one point in 2008 I put SSH on port 80 so I could access it from the restricted wifi network at the hospital my grandmother was at. I have also used openvpn. I have also used cloudflare tunnels. But in the end, I always connect to hardened openssh with key only authentication.
I understand port 443 is always opened but nowadays you can’t just run ssh traffic on 443 without it being detected as not being https
If their firewalls can detect it not being typical http/s traffic, they can block it.
Having done my own review of the vulns and the fixes as they are landing in github, its pretty clear to me that this only affects situations where you use ACLs to permit ssh into a node (via tailscale ssh, not via opensshd), but dont give a path to sudoers/root.
If a user had no SSH access and/or connectivity to a vulnerable node, none of these vulns give them access.
However, if you have a vulnerable tailscaled and you give ssh access as some non-root account/privs, then yes, these vulns are relevant as theres now known privilege escalations that give access beyond some specific user account.
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.
If all your tailscale-ssh ACLs allow you into an account with sudo, or allow you into root, theres no impact (you cant do anything with these vulns you couldnt do a month ago). Thats the nuance I'm trying to get across (admittedly my english is bad).
There are a handful which restrict users to their own user accounts. But it's on dev server with friendly devs, so even for that use case it's not really the end of the world.
I'm sure our infosec folks are going to demand that we upgrade everywhere, however.
Of course it should be taken seriously, but this topic is also piggy backing off of 7 days straight of non stop viral engagement farming on X after php2shell, where people we're farming likes by just posting stuff like
"YoU ThInK PhP2ShELl iS BaD JuST WaIt unTiL TaIlScAlE get HaCkED, ThIS JuSt ThE BeGiNNiNG oF a CybeR ReCKoNiNG"
To farm FUD from normies. Which of course led researchers who were working on tailscale vulns to take advantage of that algorithmic attention as well and talk about their research.
Like Im pretty sure we knew about this vuln for 3 days now, or atleast that it was responsibly disclosed (and not being used in the wild).
The attention this is getting is definately the product of some cringe viral snowball effect of the also rather benign p2pshell vuln.
It feels like there's a ton of AI influencer astroturfing going on, because its wildly easy to get engagement when you add the words "agent/ai" with "vulnerbility" and [insert popular service].
I personally use openssh, but someone else may use tailscale SSH.
Would only show worm behavior if machines within the tailnet had the right settings and also were members of other tailnets with those settings but then it would require someone in that tailnet to have another tailnet with the right settings…
It’s far fetched.
So a failure in tailscale is not an issue on it's own because you'd then also have to find an exploit in what I'm actually hosting as well. Both of those things happening at the same time is much less likely.
My question to those who kept praising Tailscale and making fun of good old plain SSH: how do you like your state backdoor --excuse me, I mean bug-- in Tailscale now?
Letting Tailscale handle VPN and SSH at the same time is basically once again a single point of failure. Similar to exposing SSH directly to the internet.