ts-2026-006
Vulnerability from tailscale

Description: Tailscale SSH allowed users to be addressed by numeric UID, bypassing root user restrictions in ACLs.

What happened?

Tailscale SSH previously allowed users to be addressed by their username or UID value, however the root user restrictions in ACL enforcement only considered the former. A user with non-root SSH access who addressed 0@host would have been able to access root in violation of ACLs.

Tailscale now disallows the use of UIDs or numeric-only usernames via SSH to avoid this ambiguity.

This vulnerability is fixed in Tailscale version 1.98.9 or newer.

What was the impact?

A user with SSH access to a node would have been able to SSH as root using the username 0 in violation of ACL policy.

Who was affected?

Users of Tailscale SSH on Linux/Unix hosts that rely on autogroup:nonroot user restrictions in Tailscale ACLs.

What do I need to do?

If you use Tailscale SSH, upgrade to Tailscale version 1.98.9 or newer.

Credits

We would like to thank Tim Hoffman (GM) for reporting this issue.

Show details on source website


{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2026-006",
  "link": "https://tailscale.com/security-bulletins/#ts-2026-006",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2026-006",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Thu, 11 Jun 2026 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Tailscale SSH allowed users to be addressed by numeric UID, bypassing \u003ccode\u003eroot\u003c/code\u003e user restrictions in ACLs.\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 previously allowed users to be addressed by their username \u003cem\u003eor\u003c/em\u003e UID value, however the \u003ccode\u003eroot\u003c/code\u003e user restrictions in ACL enforcement only considered the former. A user with non-\u003ccode\u003eroot\u003c/code\u003e SSH access who addressed \u003ccode\u003e0@host\u003c/code\u003e would have been able to access \u003ccode\u003eroot\u003c/code\u003e in violation of ACLs.\u003c/p\u003e\n\u003cp\u003eTailscale now disallows the use of UIDs or numeric-only usernames via SSH to avoid this ambiguity.\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\u003eA user with SSH access to a node would have been able to SSH as \u003ccode\u003eroot\u003c/code\u003e using the username \u003ccode\u003e0\u003c/code\u003e in violation of ACL policy.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of Tailscale SSH on Linux/Unix hosts that rely on \u003ccode\u003eautogroup:nonroot\u003c/code\u003e user restrictions in Tailscale ACLs.\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 Hoffman (GM) 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 allowed users to be addressed by numeric UID, bypassing \u003ccode\u003eroot\u003c/code\u003e user restrictions in ACLs.\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 previously allowed users to be addressed by their username \u003cem\u003eor\u003c/em\u003e UID value, however the \u003ccode\u003eroot\u003c/code\u003e user restrictions in ACL enforcement only considered the former. A user with non-\u003ccode\u003eroot\u003c/code\u003e SSH access who addressed \u003ccode\u003e0@host\u003c/code\u003e would have been able to access \u003ccode\u003eroot\u003c/code\u003e in violation of ACLs.\u003c/p\u003e\n\u003cp\u003eTailscale now disallows the use of UIDs or numeric-only usernames via SSH to avoid this ambiguity.\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\u003eA user with SSH access to a node would have been able to SSH as \u003ccode\u003eroot\u003c/code\u003e using the username \u003ccode\u003e0\u003c/code\u003e in violation of ACL policy.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of Tailscale SSH on Linux/Unix hosts that rely on \u003ccode\u003eautogroup:nonroot\u003c/code\u003e user restrictions in Tailscale ACLs.\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 Hoffman (GM) for reporting this issue.\u003c/p\u003e"
  },
  "title": "TS-2026-006",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2026-006"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…