Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN1099 _____________________________________________________________________ DATE : 28/10/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Tailscale version prior to 1.104.4. ==================================================================== https://tailscale.com/security-bulletins#ts-2026-017 https://tailscale.com/blog/tailscale-ssh-findings-fixes _____________________________________________________________________ TS-2026-017 Description: HTTP/2 shared serve context could send the wrong Tailscale-App-Capabilities values across mounts. What happened? Tailscale Serve 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 serveHTTPContext. A race condition occurred because the handler wrote AppCapabilities 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. Tailscale now derives request capabilities from a per-request context rather than sharing state across all streams on an HTTP/2 connection. This vulnerability is fixed in Tailscale version 1.104.4 or newer. What was the impact? Applications that inspect a request's Tailscale-App-Capabilities 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. Who was affected? This 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. What do I need to do? If you use Tailscale Serve with TLS enabled, upgrade to Tailscale version 1.104.4 or newer. TS-2026-016 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. TS-2026-015 Description: Memory exhaustion in Tailscale SSH session handling could lead to denial of service. What happened? Tailscale SSH provides a secure shell server integrated into tailscaled. An issue in the embedded SSH server's session handling allowed authenticated peers to cause unbounded memory growth in the tailscaled process. This occurred through continuous window-change messages and environment variable appends within a session. These allocations persisted even after the peer disconnected. Tailscale now bounds the memory used for session handling and releases it when the peer disconnects. This vulnerability is fixed in Tailscale version 1.104.4 or newer. What was the impact? An attacker could exhaust available memory on the host, leading to an out-of-memory (OOM) kill of the tailscaled process. Because tailscaled is central to all node networking state, such a crash disrupts every Tailscale connection on the node. Who was affected? This issue affects nodes running the Tailscale SSH server. An authenticated SSH session permitted by policy is required to trigger the condition. What do I need to do? If you use Tailscale SSH, upgrade to Tailscale version 1.104.4 or newer. TS-2026-014 Description: Tailscale SSH Unix socket forwarding could grant peers access to root-only sockets. What happened? Tailscale SSH allows the forwarding of TCP and Unix sockets between a client and a host. The SSH server in the root-privileged tailscaled process validated Unix socket paths lexically but would perform the operations as root. This created three vulnerabilities. First, it allowed privileged dials via local forwarding (ssh -L). Second, it allowed socket replacement via remote forwarding (ssh -R) by unlinking root-owned sockets. Third, a race condition defeated the path allowlist because the kernel re-resolves paths after the initial check. These issues combined to remove the path allowlist as a security boundary. This gave authenticated peers with authorized forwarding access a route to root-only Unix sockets on the node. Tailscale now performs Unix socket forwarding on behalf of the authenticated user rather than as root. This vulnerability is fixed in Tailscale version 1.104.4 or newer. What was the impact? An attacker could reach root-only sockets such as the Docker socket or the tailscaled local API. Who was affected? This issue affects users with Tailscale SSH enabled who also allow local or remote forwarding in their access policies. What do I need to do? If you use Tailscale SSH with local or remote forwarding, upgrade to Tailscale version 1.104.4 or newer. As a mitigation, you can disable SSH forwarding by setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service. This disables forwarding without disabling all of Tailscale SSH. _____________________________________________________________________ Tailscale SSH: Findings and fixes Last weekend, a security researcher published a report titled “Tailworm,” describing potential vulnerabilities in Tailscale SSH and other Tailscale features. We know that people rely on Tailscale to protect access to important systems, and we understand how concerning it is to learn that some of those protections didn’t work as intended. Over the past several days, our engineering and security teams have identified issues that require urgent attention, reviewed related code, and developed and tested fixes. Beyond addressing the individual vulnerabilities, we’ve also introduced architectural safeguards designed to protect against broader classes of related issues. Those fixes are now available in Tailscale v1.104.4. We know that earning your trust means more than simply releasing a patch. You deserve to understand what happened, how it might have affected you, and what we’ve done to make things better. That’s what we want to explain here. Tailscale supports standard SSH connections over your tailnet, including OpenSSH. Tailscale SSH goes further by providing a built-in SSH server that uses Tailscale identities and access policies to control access. Administrators can define who can connect to which machines, which local Linux/Unix users they can connect as, and whether connections require an additional authentication check. Tailscale SSH also supports visibility features such as session recording and auditing within the platform. SSH servers, including OpenSSH and Tailscale SSH, need elevated system privileges to perform certain operations, such as starting sessions as different Unix users. The challenge is ensuring those privileges don’t extend to the connected user’s session, where commands and features such as SSH forwarding must remain within the permissions granted to that user. The Tailscale SSH vulnerabilities identified primarily concerned how permissions were enforced after a connection had been authorized, rather than the authentication and access policy checks that determine who can connect. Exploitation of these vulnerabilities requires an attacker to already have access to an authorized device in the tailnet. Under certain conditions, an authenticated SSH session could perform operations beyond the privileges of its configured local user, including through SSH forwarding. These privilege boundaries are an important part of Tailscale SSH’s security model, and in these cases we didn’t enforce them correctly. It’s important to note that the vulnerabilities don’t allow an unauthenticated attacker to connect to arbitrary Tailscale SSH servers. Exploitation requires an existing foothold on an authorized peer in the tailnet, with SSH access explicitly permitted in the tailnet policy file, along with the conditions necessary to exercise the vulnerable functionality. The report’s name has also prompted questions about whether these vulnerabilities constitute a computer worm. They don’t describe self-replicating malware spreading automatically between machines. Instead, this would be better described as lateral movement limited to connections allowed by a tailnet policy file. In addition, the access between machines was still gated by the tailnet policy file. Based on our investigation, an attacker could reach only machines the tailnet policy file already permitted SSH connections to. The vulnerabilities could only be exploited after an attacker had gained the necessary access. The report also describes five findings in Tailscale Serve and Funnel. Three were bugs, and Tailscale v1.104.4 fixes them. The other two describe behavior that works as designed: bypassing the Funnel attribute check requires local admin access, and TS_SERVE_ALLOW_ALL_INTERFACES is an opt-in setting meant to expose Serve beyond the tailnet. On Friday, October 23, concerns about Tailscale SSH began circulating on social media. Our engineering and security teams began investigating immediately, with help from external security specialists. We received the researcher’s report on the morning of Saturday, October 24, and the researcher published it two hours later. By that point, our engineering and security teams were already investigating several related issues and working on fixes. Once the report was provided, we used it to ground our in-progress investigations, ensure coverage of the public findings, reproduce the relevant issues, and accelerate work on fixes. We also expanded our review of the affected code to make sure we were addressing the underlying problems rather than individual symptoms. Over the weekend and into Monday, our engineers worked through the fixes and tested the changes, paying particular attention to Unix privileges and SSH forwarding. On Monday, October 26, we published an investigation update with our initial assessment and recommended precautions. The resulting fixes are available in Tailscale v1.104.4. The report also identified a vulnerability in Conn25, the next generation of our app connectors. Conn25 is still in pre-production and hasn’t been released. We were already aware of this issue, and addressing it is one of the reasons we haven’t released Conn25. Finding and fixing issues like this before a feature reaches users is an important part of our development process. The stable app connectors available today are not affected. We’re publishing four security bulletins covering the confirmed findings that warrant separate disclosures. Each explains the affected functionality, conditions required for exploitation, impact, and remediation: TS-2026-014 TS-2026-015 TS-2026-016 TS-2026-017 The vulnerabilities described above are addressed in Tailscale v1.104.4. If you use Tailscale SSH, we recommend updating to this release or later. Beyond updating, we also recommend reviewing how SSH access is configured across your tailnet. A few things worth checking: Review your Tailscale SSH policies to make sure access is limited to the users and devices that need it. Consider SSH check mode for sensitive systems, which requires an additional authentication check before granting access. We value independent security research and welcome reports that help us improve Tailscale. We’ll apply what we’ve learned from this investigation to our ongoing security work. If you discover a vulnerability, please contact us at security@tailscale.com so we can investigate and work with you to help keep Tailscale’s community safe. ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================