TS-2026-006

Vulnerability from tailscale - Published: Thu, 11 Jun 2026 00:00:00 GMT

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…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…