Tailscale 1.104.4でSSHとServeの4件の脆弱性を修正｜影響する設定と、更新の確かめ方
Tailscaleが、SSHとServeの4件を直した1.104.4を公開
機器どうしを暗号化した仮想ネットワーク（tailnet）でつなぐTailscaleは、2026年10月28日にバージョン1.104.4を公開しました。10月26日にセキュリティ速報4件（TS-2026-014〜017）を出していて、1.104.4はそのすべてを修正しています。その後の11月2日には1.104.5が公開され、2026年11月8日時点の最新版は1.104.5です。4件の修正は、1.104.4以降の版に含まれています。
対象は、Tailscaleに組み込まれたSSHサーバー「Tailscale SSH」と、tailnetの中へWebサービスなどを公開する「Tailscale Serve」です。Tailscaleのブログによると、SSHで接続を許された人が、設定したユーザーの権限を超えて操作できる場合があったことが中心でした。
この記事では、4件がそれぞれどの設定のノードに関係するかを整理し、GitHubで公開されているソースの差分から、1.104.4で何が変わったかを確かめます。最後に、更新の確かめ方と、すぐに更新できないノードで使える暫定策（SSHのフォワーディングの件だけに効く設定）をまとめます。
1.104.4の要点
Tailscale SSHかServeを使うノードは、1.104.4以降へ更新する
修正の数
速報4件
SSHが2件（権限を超えた接続、メモリ枯渇）、Serveが2件（内部の窓口への転送、権限情報の混線）。
悪用の前提
tailnet内の許可された機器
SSHの件は、アクセス方針で接続を許された機器を攻撃者が先に押さえていることが前提。
修正版
1.104.4
全プラットフォーム向けに10月28日公開。11月8日時点の最新版は、11月2日公開の1.104.5。
更新までの暫定策（014だけ）
SSHのフォワーディングを止める
TS_SSH_DISABLE_FORWARDING=1 で014は防げる。残る3件には暫定策が示されておらず、更新が必要。
出典: Tailscaleのセキュリティ速報（2026年10月26日）、変更履歴、ブログ（10月28日）。差分は筆者がGitHubのv1.104.2とv1.104.4を比べて確認
研究者の報告から4日で、修正版が出た
きっかけは、Tailscale SSHへの懸念と、研究者がまとめた「Tailworm」という報告です。Tailscaleのブログによると、10月23日ごろからSNSでTailscale SSHへの懸念が広がり、Tailscaleは調査を始めました。24日の朝に報告を受け取り、その約2時間後に研究者が報告を公開しました。Tailscaleは26日に調査状況と暫定策を公表し、28日に修正版を出しています。
10月23日ごろ
Tailscale SSHへの懸念がSNSで広がる
10月24日
Tailscaleが報告を受け取り、約2時間後に研究者が「Tailworm」を公開
10月26日
セキュリティ速報4件と、フォワーディングを止める暫定策を公表
10月28日
1.104.4を全プラットフォーム向けに公開
Tailscaleは、問題の中心は「誰が接続できるか」を決める認証やアクセス方針の確認ではなく、接続を認めたあとの権限の扱いにあったと説明しています。報告にはServeとFunnel（tailnetの外へ公開する機能）の5件も含まれていて、そのうち3件をバグとして1.104.4で直し、残る2件は仕様どおりの動作だとしています。速報では、Serveの修正を、2つの弱点をまとめたTS-2026-016と、TS-2026-017の2件として公表しています。開発中で未公開の新しいアプリコネクタ（Conn25）の問題も報告されましたが、現在提供しているアプリコネクタは影響を受けないとしています。
4件は、SSHのフォワーディングやServeの使い方で影響が分かれる
4件とも、Tailscaleを入れているだけで影響するものではなく、特定の機能や設定を使っているノードが対象です。自分のノードの設定と照らし合わせると、急いで更新すべきノードが分かります。
TS-2026-014 Tailscale SSH
フォワーディングで、rootだけが使える窓口に届いた
SSHの接続を通して別の通信を中継する機能（ssh -L / -R）を、rootの権限で処理していた。接続を許された人が、DockerやtailscaledのUnixソケット（同じ機器のプログラムどうしの窓口）に届くおそれがあった。
対象: アクセス方針でSSHのフォワーディングを許しているノード
TS-2026-015 Tailscale SSH
メモリを使い果たし、tailscaledが止まった
接続中のセッションから画面サイズの変更などを送り続けると、切断後もメモリが解放されなかった。tailscaledが止まると、そのノードのTailscaleの通信がすべて切れる。
対象: Tailscale SSHを有効にしたノード（方針で許されたセッションが必要）
TS-2026-016 Tailscale Serve
Unixソケットへの転送で、tailscaledの内部の窓口に届いた
ServeのTCP転送の宛先をUnixソケットにすると、tailscaledの操作用の窓口（ローカルAPI）にもrootとして届き、ノードを乗っ取られるおそれがあった。悪用するのは、そのノードでServeの設定を変えられる利用者や、転送先のパスを書き換えられる利用者で、設定のあとで宛先をシンボリックリンクに差し替える方法もあった。
対象: Unixソケットへ転送するServeを使うノードのうち、root以外のユーザー（operator権限を与えたユーザーを含む）がServeの設定を書けるか、転送先のパスに書き込めるもの
TS-2026-017 Tailscale Serve
あるパスの権限情報が、別のパスへの要求に混ざった
HTTPSで公開した複数のパス（マウント）で、1本の接続上の同時の要求どうしが権限情報（Tailscale-App-Capabilities）を共有し、許されていないパスの応答を受け取れる場合があった。
対象: 求める権限が違う複数のパスをServeで公開しているノード
なかでも影響が大きいのは、オレンジの枠で示したTS-2026-014と016です。どちらも、本来はrootしか使えない窓口に一般の権限から届き、ノード全体を操作されるおそれがありました。Tailscaleの暫定策がSSHのフォワーディングを止める設定なのは、014がフォワーディングを通して起きるためです。
一方で、SSHの件はどれも、アクセス方針で接続を許された機器からの操作が前提です。攻撃者は、まずtailnet内のパソコンやサーバーのどれかを乗っ取る必要があります。そのため、SSHの件で被害が及ぶ範囲は、アクセス方針で「どの機器からどのノードへSSHを許しているか」によって決まります。
差分では、SSHの処理をユーザーの権限で動かす形に変わった
TailscaleのソースはGitHubで公開されています。v1.104.2とv1.104.4を比べると、42のコミットで88のファイルが変わり、その大半がTailscale SSHの実装でした（1.104.3は社内向けで、公開のタグはありません）。
TS-2026-014への対応では、フォワーディングの処理を、接続したユーザーの権限で動く子プロセスへ任せる仕組み（fwdchild.go など）が新しく入りました。これまでrootのまま行っていたソケットへの接続を、接続を許されたユーザーとして行うので、そのユーザーが本来触れない窓口には届かなくなります。この仕組みはLinux、macOS、FreeBSD、OpenBSDで使われます。
TS-2026-016への対応では、Serveの設定を保存するときに、宛先がtailscaled自身のソケットなら拒否するようになりました。加えて、接続のたびに宛先を確かめ直します。Linux（カーネル5.6以降）では宛先のファイルを固定してから接続するので、設定のあとでシンボリックリンクに差し替えられても、固定したファイル以外にはつながりません。固定できない環境でも、接続したあとに相手を確かめ、tailscaledのソケットだと分かれば切断します。TS-2026-017では、権限情報を接続ごとではなく要求ごとの情報として持つ形に変わっています。
速報に含まれない強化もありました。SSHで受け取る環境変数のうち、rootの処理に影響しうる GLIBC_TUNABLES などを拒否する対象に加え、変数名の長さにも上限を設けています。SSHのホスト鍵（サーバーを見分けるための秘密鍵）を保存するときの権限も、0700から0600へ絞られました。
v1.104.2
err = os.WriteFile(path, pemGen, 0700)v1.104.4
err = os.WriteFile(path, pemGen, 0600)GitHubのv1.104.2とv1.104.4の比較から抜粋（2026年10月29日に筆者が確認）。新しく作る鍵ファイルに適用される
Tailscaleはブログで、報告された問題を直すだけでなく、同じ種類の問題を防ぐための構造的な安全策も入れたと説明しています。差分で見えるフォワーディングの子プロセス化や、接続ごとの確かめ直しは、その一部にあたります。
更新までの手順と、すぐ更新できないノードでの暫定策
対応の基本は、Tailscale SSHかServeを使っているノードを1.104.4以降へ更新することです。2026年11月8日時点の最新版は11月2日公開の1.104.5で、4件の修正に加えて、不安定な回線でTailscale SSHやServeの接続が止まる問題の修正や、Windowsのインストーラーでインストール時に権限昇格につながりうる問題の修正が入っています。自動更新は段階的に配信されるため、有効にしていても、まだ1.104.4以降になっていないことがあります。tailscale update などで今すぐ更新し、版を確かめてください。SynologyやDockerで動かしているノードは、それぞれの方法で個別に更新します。
手順1 対象のノードを洗い出す
Tailscale SSHかServeを有効にしているノードを確かめる
管理画面のアクセス方針でSSHを許している先と、tailscale serve status で何かを公開しているノードが対象。
手順2 更新して版を確かめる
1.104.4以降へ更新し、tailscale version で確かめる
表示された版が1.104.4以降なら、4件の修正が入っている（11月8日時点の最新版は1.104.5）。tailscale version --daemon なら、コマンドと、裏で動くtailscaledの両方の版が出る。管理画面の機器一覧でも各ノードの版を確かめられる。
手順3 すぐ更新できないノード
フォワーディングを止め、SSHの許可を絞る
tailscaledの実行環境に TS_SSH_DISABLE_FORWARDING=1 を設定して再起動すると、SSH自体は使えたままフォワーディングだけが止まる。Tailscaleの公式パッケージで入れたLinuxなら、/etc/default/tailscaled に TS_SSH_DISABLE_FORWARDING=1 の1行を足し、sudo systemctl restart tailscaled で再起動する。再起動の間はそのノードのTailscaleの通信が切れ、Tailscale SSH越しに作業中なら接続も切れる。SSHを使ったトンネルも止まるので、使っている場合は先に確かめる。TS_SSH_DISABLE_FORWARDING=1 で防げるのはTS-2026-014だけで、ほかの3件には暫定策が示されていない。更新までの間は、アクセス方針でSSHを許す機器も必要なものに絞り、Serveを使うノードは更新を優先する。
更新が済んだあとも、SSHのアクセス方針は見直す価値があります。Tailscaleは、SSHを許す相手を必要な人と機器に絞ることと、重要なシステムには接続時に追加の確認を求める「check mode」を検討することを勧めています。tailnet内の機器が1台乗っ取られたときに、どこまでSSHで届くかを決めているのがこの方針だからです。
SSHの2件の対象は、Tailscale SSHのサーバー機能を有効にしたノードです。Tailscale SSHを有効にせず、tailnetの上で通常のOpenSSHサーバーにだけ接続しているノードは、速報が示す対象の条件に当たりません。Serveの2件は条件が別なので、Serveを使っているノードは同じように更新してください。