ts-2026-016
Vulnerability from tailscale

Description: tailscale serve Unix backends could reach privileged sockets, including the tailscaled local API socket.

What happened?

Tailscale Serve can proxy incoming connections to local backends, including Unix domain sockets, making them accessible over your tailnet. Two weaknesses existed in how tailscale serve handled Unix backend targets. First, TCP forwards to Unix sockets lacked a guard and dialed the target as root. This allowed raw bytes to be passed directly into the local API socket using the daemon's own user permissions. Second, the symlink guard for HTTP proxies only ran during configuration reload rather than per dial. A user could replace a benign backend path with a symlink after configuration to defeat this guard.

Tailscale now restricts TCP forwards to the tailscaled socket and revalidates backend targets during each dial.

This vulnerability is fixed in Tailscale version 1.104.4 or newer.

What was the impact?

The first issue allowed full node takeover by providing remote access to the local API. The second issue allowed root-context dials of arbitrary root-only Unix sockets.

Who was affected?

This affects nodes where a local operator has the ability to write serve configurations or where local users have write access to configured backend paths.

What do I need to do?

If you use Tailscale Serve with Unix socket backends, upgrade to Tailscale version 1.104.4 or newer.

Show details on source website


{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2026-016",
  "link": "https://tailscale.com/security-bulletins/#ts-2026-016",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2026-016",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Mon, 26 Oct 2026 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: \u003ccode\u003etailscale serve\u003c/code\u003e Unix backends could reach privileged sockets, including the \u003ccode\u003etailscaled\u003c/code\u003e local API socket.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003e\u003ca href=\"https://tailscale.com/docs/features/tailscale-serve\"\u003eTailscale Serve\u003c/a\u003e can proxy incoming connections to local backends, including Unix domain sockets, making them accessible over your tailnet. Two weaknesses existed in how \u003ccode\u003etailscale serve\u003c/code\u003e handled Unix backend targets. First, TCP forwards to Unix sockets lacked a guard and dialed the target as root. This allowed raw bytes to be passed directly into the local API socket using the daemon\u0027s own user permissions. Second, the symlink guard for HTTP proxies only ran during configuration reload rather than per dial. A user could replace a benign backend path with a symlink after configuration to defeat this guard.\u003c/p\u003e\n\u003cp\u003eTailscale now restricts TCP forwards to the tailscaled socket and revalidates backend targets during each dial.\u003c/p\u003e\n\u003cp\u003eThis vulnerability is fixed in Tailscale version 1.104.4 or newer.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eThe first issue allowed full node takeover by providing remote access to the local API. The second issue allowed root-context dials of arbitrary root-only Unix sockets.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eThis affects nodes where a local operator has the ability to write serve configurations or where local users have write access to configured backend paths.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you use Tailscale Serve with Unix socket backends, upgrade to Tailscale version 1.104.4 or newer.\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: \u003ccode\u003etailscale serve\u003c/code\u003e Unix backends could reach privileged sockets, including the \u003ccode\u003etailscaled\u003c/code\u003e local API socket.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003e\u003ca href=\"https://tailscale.com/docs/features/tailscale-serve\"\u003eTailscale Serve\u003c/a\u003e can proxy incoming connections to local backends, including Unix domain sockets, making them accessible over your tailnet. Two weaknesses existed in how \u003ccode\u003etailscale serve\u003c/code\u003e handled Unix backend targets. First, TCP forwards to Unix sockets lacked a guard and dialed the target as root. This allowed raw bytes to be passed directly into the local API socket using the daemon\u0027s own user permissions. Second, the symlink guard for HTTP proxies only ran during configuration reload rather than per dial. A user could replace a benign backend path with a symlink after configuration to defeat this guard.\u003c/p\u003e\n\u003cp\u003eTailscale now restricts TCP forwards to the tailscaled socket and revalidates backend targets during each dial.\u003c/p\u003e\n\u003cp\u003eThis vulnerability is fixed in Tailscale version 1.104.4 or newer.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eThe first issue allowed full node takeover by providing remote access to the local API. The second issue allowed root-context dials of arbitrary root-only Unix sockets.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eThis affects nodes where a local operator has the ability to write serve configurations or where local users have write access to configured backend paths.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you use Tailscale Serve with Unix socket backends, upgrade to Tailscale version 1.104.4 or newer.\u003c/p\u003e"
  },
  "title": "TS-2026-016",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2026-016"
  }
}


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…