Tailscale’s engineering chief Mike Shaver says the company has identified SSH security issues and is still validating affected configurations. His October 25 update describes problems with Unix privileges and connection forwarding after a user has been authorized to connect.

The company is working on fixes. Shaver says its current assessment does not call for everyone to disable Tailscale SSH. For sensitive systems, he recommends temporarily narrowing access to the specific users and devices that need it.

Authorized access can still exceed the intended permissions

Tailscale SSH manages remote-shell authentication and authorization through tailnet policies, the rules for a private Tailscale network. Its documentation distinguishes this feature from an ordinary SSH server reached over Tailscale’s encrypted network.

That distinction matters when checking exposure. Using Tailscale as a network connection does not by itself establish that its SSH server is enabled.

Shaver says some sessions may be able to do more than their configured local user should be allowed to do. His description requires authorized access first. It supplies no evidence of an unauthenticated attacker connecting to arbitrary machines.

Evidence status: vendor-confirmed issues under investigation. The update reports neither observed malicious exploitation nor a completed public exploit demonstration. It leaves the full configuration scope, affected versions and fixed releases unresolved.

Check mode adds authentication, not a privilege fix

Shaver recommends several precautions while engineering completes its investigation:

  • Review SSH access policies. Limit allowed people, devices and destinations to those with a real need. Give sensitive systems a tighter temporary policy where practical.
  • Disable SSH forwarding if you do not need it. Shaver now specifies setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting that service. Forwarding lets a session carry other connections; the vendor says disabling it mitigates several of the more serious findings.
  • Consider SSH check mode. It requires additional authentication before a connection. Shaver explicitly says it does not fix privilege escalation after access is granted.
  • Enable automatic updates where supported. Follow the forthcoming advisory for confirmed findings, affected configurations and the patches that address them.

Tailscale’s documentation says check mode can require reauthentication on every new connection when configured accordingly. That strengthens the login barrier while leaving the underlying permission issue to be fixed.

Keep earlier patches separate from this investigation

The official bulletin index already contains older SSH advisories with their own fixed versions. Those historical numbers are not a verified fix for the report Shaver is now investigating.

At review on October 25, the bulletin feed’s latest entry was TS-2026-013, published October 21. It concerns the separate eMudhra certificate incident. Neither that entry nor the older SSH fixes establishes that this new investigation is resolved.

Caveat: This is the affected vendor’s preliminary assessment, not an independent finding that current deployments are safe; confirmed exposure and remediation details are still pending.

Update: October 25, 21:46 EDT — a specific forwarding mitigation

Shaver’s updated post now gives the service-level setting above for disabling SSH forwarding while keeping Tailscale SSH available. This replaces our earlier, general advice to remove unnecessary forwarding permissions with the vendor’s concrete interim control.

The setting belongs in the daemon’s service environment. Setting it only in an interactive shell does not configure an already-running service. Plan the restart through the normal maintenance process and retain another authorized way to administer sensitive hosts.

This is a partial mitigation, not a complete privilege-escalation fix. Continue narrowing authorized access and following the forthcoming advisory. The official bulletin feed still lists the separate eMudhra issue as its newest entry; no fixed release for this investigation is identified there.