{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2026-004",
  "link": "https://tailscale.com/security-bulletins/#ts-2026-004",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2026-004",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Wed, 03 Jun 2026 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Tailscale SSH Unix socket forwarding did not respect symlink permissions, allowing privileged socket access.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003e\u003ca href=\"https://tailscale.com/docs/features/tailscale-ssh\"\u003eTailscale SSH\u003c/a\u003e includes the ability to forward both TCP and Unix sockets between the client and host. A bug in the filesystem permission checks within Tailscale SSH\u0027s Unix socket forwarding permitted an unprivileged user to bind and access a privileged socket on the remote host.\u003c/p\u003e\n\u003cp\u003ePreviously, when Tailscale SSH evaluated filesystem permissions for requested sockets, it only performed lexical matching of the requested path against its allowlists and denylists. An attacker who created a symlink at a path they owned (e.g., \u003ccode\u003e/home/$USER/my.sock\u003c/code\u003e) that pointed to a protected resource (e.g., \u003ccode\u003e/var/run/docker.sock\u003c/code\u003e) would have been able to bind and access the latter path in an SSH connection. This is possible because Tailscale runs as \u003ccode\u003eroot\u003c/code\u003e and so has access to the privileged destination.\u003c/p\u003e\n\u003cp\u003eIn addition to lexical matching, Tailscale SSH now checks the requested and configured paths for symlinks and evaluates them to ensure that their destinations are also authorized. Symlinks with destinations outside of the configured allowlist will be denied.\u003c/p\u003e\n\u003cp\u003eThis vulnerability is fixed in Tailscale version 1.98.9 or newer.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eAn unprivileged user would have been able to access privileged Unix sockets on the remote host.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of Tailscale SSH on shared Linux/Unix hosts that rely on filesystem permissions to restrict access to Unix sockets.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you use Tailscale SSH, upgrade to Tailscale version 1.98.9 or newer.\u003c/p\u003e\n\u003ch4\u003eCredits\u003c/h4\u003e\n\u003cp\u003eWe would like to thank Tim Sageser (\u003ca href=\"https://dtrsecurity.com\"\u003edtrsecurity\u003c/a\u003e) for reporting this issue.\u003c/p\u003e",
  "summary_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/html",
    "value": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Tailscale SSH Unix socket forwarding did not respect symlink permissions, allowing privileged socket access.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003e\u003ca href=\"https://tailscale.com/docs/features/tailscale-ssh\"\u003eTailscale SSH\u003c/a\u003e includes the ability to forward both TCP and Unix sockets between the client and host. A bug in the filesystem permission checks within Tailscale SSH\u0027s Unix socket forwarding permitted an unprivileged user to bind and access a privileged socket on the remote host.\u003c/p\u003e\n\u003cp\u003ePreviously, when Tailscale SSH evaluated filesystem permissions for requested sockets, it only performed lexical matching of the requested path against its allowlists and denylists. An attacker who created a symlink at a path they owned (e.g., \u003ccode\u003e/home/$USER/my.sock\u003c/code\u003e) that pointed to a protected resource (e.g., \u003ccode\u003e/var/run/docker.sock\u003c/code\u003e) would have been able to bind and access the latter path in an SSH connection. This is possible because Tailscale runs as \u003ccode\u003eroot\u003c/code\u003e and so has access to the privileged destination.\u003c/p\u003e\n\u003cp\u003eIn addition to lexical matching, Tailscale SSH now checks the requested and configured paths for symlinks and evaluates them to ensure that their destinations are also authorized. Symlinks with destinations outside of the configured allowlist will be denied.\u003c/p\u003e\n\u003cp\u003eThis vulnerability is fixed in Tailscale version 1.98.9 or newer.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eAn unprivileged user would have been able to access privileged Unix sockets on the remote host.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of Tailscale SSH on shared Linux/Unix hosts that rely on filesystem permissions to restrict access to Unix sockets.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you use Tailscale SSH, upgrade to Tailscale version 1.98.9 or newer.\u003c/p\u003e\n\u003ch4\u003eCredits\u003c/h4\u003e\n\u003cp\u003eWe would like to thank Tim Sageser (\u003ca href=\"https://dtrsecurity.com\"\u003edtrsecurity\u003c/a\u003e) for reporting this issue.\u003c/p\u003e"
  },
  "title": "TS-2026-004",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2026-004"
  }
}