Tailscale has released version 1.104.4 to patch security flaws in its built-in SSH functionality. According to the reported disclosure, the issue could allow an attacker who has already compromised one device in a Tailscale network to use Tailscale SSH behaviour to reach services and files on other servers that would normally be restricted to the root user.

For businesses using Tailscale to manage remote access between employees, contractors, servers and cloud systems, the update is relevant because the reported weakness affects trust boundaries inside private infrastructure rather than only internet-facing services.

What happened

The reported flaws affect Tailscale SSH, the product’s built-in SSH server and access feature. The issue is linked to how network connections are forwarded by the Tailscale background process, which operates with root privileges.

Based on the source report, successful exploitation would require an attacker to already control or compromise a device within the Tailscale environment. In that scenario, the attacker could potentially use the flawed forwarding behaviour to access services and files on other connected servers that should be available only to root-level processes or users.

Tailscale says the issue is fixed in version 1.104.4. The source material does not indicate that every deployment is affected in the same way, so companies should verify their use of Tailscale SSH and review vendor guidance for exposure details.

Why it matters for European businesses

Tailscale is widely used to simplify secure connectivity across distributed teams, cloud workloads, developer environments and internal admin systems. For many SMEs and digital teams, it acts as a practical alternative to more complex VPN setups.

This makes the issue significant for business users because:

• A compromised endpoint could become a pivot point to more sensitive servers inside the private network.
• Root-level access boundaries matter for production servers, databases, internal tools and administrative services.
• Remote and hybrid work environments often depend on software-defined access tools, so a flaw in trusted connectivity infrastructure can affect multiple systems at once.
• Security teams may need to revisit lateral movement assumptions, especially where internal services are considered protected because they are not publicly exposed.

For European organisations handling client data, e-commerce operations or regulated workloads, the practical concern is not only initial compromise but whether an attacker can move from one device to broader infrastructure.

Who may be affected

The update is most relevant for organisations that use Tailscale SSH in production or administrative environments, including:

• SMEs with remote teams accessing internal systems over Tailscale
• IT and DevOps teams using Tailscale to manage Linux servers and cloud instances
• Agencies and software teams maintaining multiple client or staging environments
• E-commerce businesses running private back-office services or infrastructure over Tailscale-connected networks
• Companies relying on device-to-server trust within a mesh network model

Businesses that use Tailscale for connectivity but do not use the SSH feature may still want to confirm their configuration and exposure based on official vendor documentation.

What companies should consider

• Prioritise patching by upgrading affected systems to Tailscale version 1.104.4 or later where appropriate.
• Identify where Tailscale SSH is enabled across servers, admin hosts and developer environments.
• Review privileged access paths to understand which internal services may have been reachable through trusted forwarding mechanisms.
• Check endpoint security on devices with Tailscale access, because the reported attack path depends on an already compromised machine.
• Inspect logs and recent administrative activity for unusual SSH behaviour, lateral movement or unexpected access to internal services.
• Apply least-privilege principles to remote administration workflows and reduce unnecessary root-level exposure where possible.
• Confirm vendor guidance before making compliance or incident conclusions, since public reporting may summarise rather than fully detail the technical scope.

For smaller businesses, the broader lesson is that private access tools should be treated as critical infrastructure. Even when a system is not directly exposed to the public internet, vulnerabilities in remote access layers can still create meaningful business risk if one employee device or server is compromised first.