Just a quick notice for anyone using this software in their homelab. Tailscale has released v1.104.4 to address a series of prominent vulnerabilities disclosed last week. These vulns affect the Tailscale Serve and Tailscale SSH functionalities of the software, and allow already-authorized attackers to gain further privileges erroneously. Kindly update to that version or higher, especially if you are using one of the SSH/Serve features.

For headscale selfhosters that also use Tailscale SSH, consider setting TS_SSH_DISABLE_FORWARDING=1 on all clients, as headscale does not have a way to force turning off SSH forwarding (one of the attack vectors). Headscale also has a relevant disclosed vulnerability affecting node registration, and an in-progress patch for that which is trackable here.

Finally, do give your SSH grants/access control list a review again. You may also disable these ssh/serve features if you don’t need them (and even compile the binary without them if you know how), and consider traditional alternatives such as OpenSSH + normal reverse proxy.

Further links:

  • Tailscale’s blogpost on findings and fixes, with security recommendations
  • Tailscale’s security bulletin for more info on the vulnerabilities (see TS-2026-014 to TS-2026-017)
  • Their prior investigation notes here
  • lemmyvore@feddit.nlEnglish
    1·
    7 hours ago

    Wireguard may be more obviously public, but they both technically are, right? Otherwise accessing a node just wouldn’t be possible.

    There is something exposed to the Internet in both cases, yes, but it works very differently.

    With WG it’s a client-server pattern; the server exposes a port, waits for authorized clients to connect, and when a client connects successfully the server routes their connections into the private LAN with everything that entails.

    With TS the public part is a supplier of control configurations and client pairing service. The pairing service needs to be contacted by two authorized clients in order to negotiate a connection between them. Once that’s done, it’s the clients that route each other’s connections into their respective LANs, the pairing server is not involved anymore.

    In other words the TS public surface is not WG, it’s their (proprietary) client verification and matching service. The WG connections between clients happen later, privately.

    To me, separating client authentication from routing and transport looks like a better design, because it’s multi-layered. You get the normal WG authentication and another layer on top.

    If you don’t need something specific that tailscale offers, then wireguard offers probably better security.

    “Security” is a relative term. It’s better to think in terms of attack surface, exposure, whether attacks are targeted or not etc. Which are all ongoing factors.

    Both TS and WG are popular and being used by lots of people but it’s also important for them to be actively maintained, independently audited, maintain transparency etc.