{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2026-017",
  "link": "https://tailscale.com/security-bulletins/#ts-2026-017",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2026-017",
      "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: HTTP/2 shared serve context could send the wrong \u003ccode\u003eTailscale-App-Capabilities\u003c/code\u003e values across mounts.\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 requests to local backends allowing private services to be shared on your tailnet. When enabled with TLS, the server advertises HTTP/2 and all streams on one connection shared a single \u003ccode\u003eserveHTTPContext\u003c/code\u003e. A race condition occurred because the handler wrote \u003ccode\u003eAppCapabilities\u003c/code\u003e per request while the reverse proxy read them in a shared hook. Concurrent streams on the same connection could race on this field, causing capabilities from one mount to bleed into requests for another mount.\u003c/p\u003e\n\u003cp\u003eTailscale now derives request capabilities from a per-request context rather than sharing state across all streams on an HTTP/2 connection.\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\u003eApplications that inspect a request\u0027s \u003ccode\u003eTailscale-App-Capabilities\u003c/code\u003e to authorize a peer might have made incorrect decisions based on capability headers intended for another application. A peer holding a capability for one mount could potentially receive privileged responses from a different mount they are not authorized to access.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eThis affects nodes with serve TLS enabled and at least two mounts with different capability requirements on the same node. The issue requires concurrent streams multiplexed on a single connection.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you use Tailscale Serve with TLS enabled, 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: HTTP/2 shared serve context could send the wrong \u003ccode\u003eTailscale-App-Capabilities\u003c/code\u003e values across mounts.\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 requests to local backends allowing private services to be shared on your tailnet. When enabled with TLS, the server advertises HTTP/2 and all streams on one connection shared a single \u003ccode\u003eserveHTTPContext\u003c/code\u003e. A race condition occurred because the handler wrote \u003ccode\u003eAppCapabilities\u003c/code\u003e per request while the reverse proxy read them in a shared hook. Concurrent streams on the same connection could race on this field, causing capabilities from one mount to bleed into requests for another mount.\u003c/p\u003e\n\u003cp\u003eTailscale now derives request capabilities from a per-request context rather than sharing state across all streams on an HTTP/2 connection.\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\u003eApplications that inspect a request\u0027s \u003ccode\u003eTailscale-App-Capabilities\u003c/code\u003e to authorize a peer might have made incorrect decisions based on capability headers intended for another application. A peer holding a capability for one mount could potentially receive privileged responses from a different mount they are not authorized to access.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eThis affects nodes with serve TLS enabled and at least two mounts with different capability requirements on the same node. The issue requires concurrent streams multiplexed on a single connection.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you use Tailscale Serve with TLS enabled, upgrade to Tailscale version 1.104.4 or newer.\u003c/p\u003e"
  },
  "title": "TS-2026-017",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2026-017"
  }
}