「Tailworm」で指摘されたTailscale SSHの脆弱性とTailscaleの対応を解説

11項目の指摘の内容、修正版v1.104.4、Redditでの回答、利用者が今すぐ確認すべきことを一次資料で整理する

2026年10月28日
著者: 竹洞 陽一郎

2026年10月24日（米国時間）、Cyberdione LabsのErica Windisch氏が、Tailscaleとheadscaleのセキュリティ評価報告「Tailworm」を公開しました。
報告では、Tailscale 1.104.2とheadscale 0.29.5を対象に、Tailscale SSH、Tailscale Serve／Funnel、実験的なApp Connector（conn25）、DERPクライアント、headscaleにまたがる11項目の問題が指摘されています。
最も影響が大きいのは、Tailscale SSHのUnixドメインソケット転送の処理で、SSH接続を許可された端末から、接続先サーバーのroot権限に到達できるというものです。

Tailscaleは、VP of EngineeringのMike Shaver氏がRedditで回答し、10月26日に調査状況の報告とセキュリティ速報TS-2026-014〜017を公開しました。
修正を含むTailscale v1.104.4は、米国時間10月27日にタグ付けされ、10月28日時点で公式パッケージのstableトラックから配布されています。
Tailscale SSHを使っている場合は、v1.104.4以降への更新が対策の中心です。

国内外の報道には、修正版の公開前の時点で書かれたものや、「認証なしで任意の端末を乗っ取れる」と読める見出しのものもあります。
Velumeshは株式会社Spelldataが運営するTailscaleの日本正規代理店として、導入済み・導入検討中の企業が正確な前提で判断できるよう、研究者の報告、Tailscaleの公式発表、ソースコードを照合して、2026年10月28日時点の状況を整理します。

対象となる使い方

次のいずれかに当てはまる場合は、影響を受ける可能性があります。
いずれの場合も、Tailscale v1.104.4以降に更新してください。

Tailscale SSHで、SSHポートフォワーディング（ssh -L、ssh -R）を許可している（TS-2026-014）

そのサーバーへのログインとSSHポートフォワーディングを許可されたユーザーや端末（または、それを乗っ取った攻撃者）が、ログインした後にroot権限を取得し得る問題で、今回の中で最も重大です。
SSHポートフォワーディングを実際に使っているかどうかではなく、許可しているかどうかで決まります。

Tailscale SSHで、サーバーへのログインを許可している（TS-2026-015）

そのサーバーへのログインを許可されたユーザーや端末（または、それを乗っ取った攻撃者）が、ログインした後にtailscaledのメモリを枯渇させて停止させられる問題です。
ログインを許可されていない端末やインターネット上の第三者からは悪用できません。
影響はそのサーバーのTailscaleの通信が切れることに限られますが、SSHポートフォワーディングを許可していなくても該当するため、対象はTS-2026-014より広くなります。

Tailscale Serveで、Unixドメインソケットのサービスを公開している（TS-2026-016）

tailscaledの管理APIを含む、root専用のソケットに到達される問題です。

Tailscale Serveで、1台の端末から複数のWebアプリケーションをHTTPSで公開し、アプリケーション側でTailscaleの権限情報（Tailscale-App-Capabilitiesヘッダー）を使ってアクセスを制御している（TS-2026-017）

別のアプリケーション向けの権限情報が送られ、アクセス制御を誤る問題です。

headscaleを自前で運用している

headscaleでは、Tailscale SSHのログインを許可すると、SSHポートフォワーディングも必ず許可されます。
また研究者は、headscaleに通信できる相手がアカウントなしでメモリを枯渇させられると報告しており、10月28日時点でheadscale側の修正版は出ていません。

Tailscale SSHのサーバーとして動作するのは、LinuxとmacOS（オープンソース版tailscaled）だけです。
Tailscale SSHを使わずにtailnet上で通常のOpenSSHを使っている場合、Windows・iOS・Androidの端末、Tailscale ServeとFunnelを使っていない端末、現在提供中のApp Connectorは、今回のTailscale SSHとServeの問題の対象ではありません。
ただし、Tailscaleの更新はすべての端末で行ってください。
各項目の詳しい条件は、後述の「Tailscale SSHの問題の仕組み」と「Tailscale Serve・Funnelの問題」で説明しています。

要点

何が問題だったのか

Tailscale SSHが、SSHのソケット転送（ssh -L、ssh -R）の処理を、接続したユーザーの権限ではなくtailscaledのroot権限で実行していました。
そのため、SSH接続と転送を許可されたユーザーが、Dockerのソケットやtailscaledの管理API（LocalAPI）など、root専用のソケットに到達できました。

誰が攻撃できるのか

インターネット上の第三者が認証なしで攻撃できる脆弱性ではありません。
攻撃者は、tailnet内でSSH接続を許可された端末をすでに操作できる必要があります。

修正状況

Tailscale SSHとTailscale Serveの問題は、Tailscale v1.104.4で修正されました。
実験的なApp Connector（conn25）は未リリースの機能で、現在提供中のApp Connectorは影響を受けないとTailscaleは説明しています。
headscale側の問題は、10月28日時点で修正版が出ていません。

利用者がすること

Tailscale SSHやTailscale Serveを使う端末を、v1.104.4以降に更新します。
すぐに更新できない端末では、SSH転送を無効化し、SSHのアクセスポリシーを必要最小限の送信元と宛先の組に絞ります。

TailscaleがTailscale SSHの停止を求めていない理由

Tailscaleは、10月25日のRedditでの回答と10月26日の調査状況の報告で、「現時点の評価では、すべての利用者にTailscale SSHの無効化を推奨しない」と述べています。
10月28日のブログ記事でも、推奨している対応はv1.104.4以降への更新とSSHのポリシーの見直しで、Tailscale SSHの停止は求めていません。
Tailscale SSHを今すぐ止める必要はなく、まずv1.104.4以降に更新してください。

Tailscaleが公式発表で示している根拠

Tailscaleの各発表には、次の内容が書かれています。

• 問題は、接続を許可された後の権限の扱いにありました。誰がどのサーバーに接続できるかを判定する認証と認可は、正しく動作していました。
• 認証されていない攻撃者が、任意のTailscale SSHのサーバーに接続できる問題ではありません。攻撃者は、ポリシーファイルでSSH接続を許可された端末を、すでに操作できている必要があります。
• 攻撃者が到達できるのは、ポリシーファイルでSSH接続が許可されているサーバーだけです。Tailscaleは、これを自己増殖するワームではなく、ポリシーで許可された範囲に限られた横展開と説明しています。
• 実際に悪用できるかどうかは、接続するユーザーや端末に与えた権限、サーバーの設定などの条件によって変わります。
• 最も重大な指摘のいくつかは、端末側でSSHの転送だけを無効にする設定（TS_SSH_DISABLE_FORWARDING=1）で緩和でき、Tailscale SSH全体を止める必要はありません。
• 修正版のv1.104.4が公開され、セキュリティ速報TS-2026-014〜017で対象の問題と修正内容が示されています。

一斉に停止した場合の影響（Velumeshの見解）

次の点はTailscaleの発表には書かれておらず、導入を支援している立場からのVelumeshの見解です。

• Tailscale SSHを一斉に停止すると、管理者がサーバーに入れなくなったり、Tailscale SSHを使った自動化処理が止まったりします。修正版への更新作業そのものが、Tailscale SSHを経由して行われている場合もあります。
• 代わりにOpenSSHへ急いで切り替えると、SSH鍵の配布、ポートの開放、ファイアウォールの設定などを短時間で行うことになり、別の設定ミスを生むおそれがあります。
• v1.104.4への更新で、TS-2026-014とTS-2026-015を含む4件の問題が修正されます。更新までの間は、転送の無効化でTS-2026-014を緩和できます。停止で得られるリスクの低減の多くは、停止しなくても得られます。

一方、v1.104.4にすぐ更新できず、転送の無効化もできないサーバーで、タグ単位やグループ単位の広いルールでSSH接続を許可している場合は、更新が終わるまで、そのサーバーへのsshルールを一時的に絞るか、Tailscale SSHを止めることを検討してください。
また、接続元の端末が侵害された疑いがある場合は、Tailscale SSHを止めるかどうかの前に、管理コンソールでその端末を削除してください。

経緯

日付は、Tailscaleのブログとセキュリティ速報の記載に従っています。
国内外の報道の多くは報告の公開日を10月25日としており、時差によるずれと考えられます。
また、10月28日の確認時点では、TailscaleのChangelogページにv1.104.4の項目はまだ掲載されていませんでしたが、GitHubのタグ、公式パッケージのstableトラック、セキュリティ速報、Tailscaleのブログでv1.104.4の公開を確認できます。

指摘された11項目と修正状況

研究者は、11項目に「High」「Medium」などの深刻度を付けていますが、これは研究者自身の評価で、CVSSなどの共通の基準による評価ではありません。
10月28日時点で、11項目に対応するCVE番号は確認できません。
Tailscaleは、確認した問題のうち個別の開示が必要なものを、4件のセキュリティ速報にまとめています。

Tailscale SSHの問題の仕組み

Tailscale SSHの認証と認可

Tailscale SSHは、tailscaledに組み込まれたSSHサーバーです。
接続元の端末はWireGuardの鍵で暗号学的に識別され、tailnetポリシーファイルのsshルールで、どの送信元がどの宛先に、どのローカルユーザーとして接続できるかを判定します。
SSHの鍵やパスワードを配布する必要がない一方、許可された端末を攻撃者が操作できれば、その端末の権限でSSH接続できることになります。
この点は以前から仕様として公開されている性質で、今回の脆弱性そのものではありません。

問題は、接続が許可された後の処理にありました。
OpenSSHは、認証後にセッションを処理するプロセスを接続ユーザーの権限に落としてから、ポート転送などの要求を処理します。
一方、Tailscale SSHでは、root権限で動作するtailscaledのプロセスが、Unixソケット転送の接続（dial）、待ち受け（bind）、既存ソケットの削除（unlink）を、自身のroot権限のまま実行していました。

SSHのローカル転送とリモート転送

SSHには、SSHの接続の中に別の通信を通す「転送（フォワーディング）」の機能があります。
TCPのポートの転送は、SSHの接続プロトコルを定めたRFC 4254 Section 7で規定されています。
Unixドメインソケットの転送はRFCにはなく、OpenSSHが独自に拡張したもので、OpenSSHのPROTOCOLファイルのSection 2.4「Unix domain socket forwarding」に定められています。
Tailscale SSHもこの拡張に対応しています。

たとえば、次のように使います。

# ローカル転送：手元の15432番ポートへの接続を、サーバーのlocalhost:5432（PostgreSQLなど）へ届ける
ssh -L 15432:localhost:5432 alice@server

# リモート転送：サーバーの8080番ポートへの接続を、手元の端末のlocalhost:3000へ届ける
ssh -R 8080:localhost:3000 alice@server

# Unixソケットのローカル転送：手元のソケットへの接続を、サーバー上の/tmp/app.sockへ届ける
ssh -L /home/me/app.sock:/tmp/app.sock alice@server

OpenSSHのサーバーは、認証が終わった後のセッションを接続ユーザー（この例ではalice）の権限で処理します。
そのため、転送でサーバー側が行う接続や待ち受けも、aliceに許された範囲でしか行えません。
aliceがDockerのソケットやsystemdの管理ソケットに接続する権限を持っていなければ、転送を使っても接続できません。

v1.104.2のTailscale SSHでは、Unixソケットの転送先として指定できるパスを、接続ユーザーのホームディレクトリ、/tmp、/run/user/（ユーザーID）の下に限っていました。
この制限は、パスの文字列だけを見て判定するものでした（ソースコードのUserSocketDirectories）。
一方で、判定の後の接続、待ち受け、既存ファイルの削除は、root権限で動くtailscaledがそのまま実行していました。
そのため、/tmpの下にあるroot専用のソケットにはそのまま接続でき、判定と実際の操作の間にパスの一部をシンボリックリンクに差し替えれば、/run/systemd/privateなど許可されていない場所のソケットにも到達できました。
リモート転送では、待ち受けの前に同じパスの既存ファイルを削除する設定（BindUnlink）が有効だったため、/tmpの下にあるroot所有のソケットを削除して、攻撃者が待ち受けるソケットに置き換えられました。

TS-2026-014：Unixソケット転送によるroot専用ソケットへの到達

TS-2026-014によると、tailscaledはUnixソケットのパスを文字列として検査（字句的な検査）した上で、操作をrootとして実行していました。
これにより、次の3つの問題が生じていました。

1. ssh -L（ローカル転送）で、root専用のソケットにrootとして接続できる。
2. ssh -R（リモート転送）で、root所有のソケットを削除し、攻撃者のソケットに置き換えられる。
3. パスの検査後にカーネルがパスを解決し直すため、競合状態を突いて許可リストを回避できる。

Tailscaleは、この3つの組み合わせにより、パスの許可リストがセキュリティ境界として機能しなくなっていたと説明しています。
影響として、Dockerのソケットやtailscaledの管理API（LocalAPI）など、root専用のソケットに到達される可能性が挙げられています。
研究者は、ラボ環境でsystemdの管理ソケットを経由したrootシェルの取得と、管理APIからの端末登録用の鍵の取得を実証したと報告しています。

影響を受けるのは、Tailscale SSHを有効にしていて、アクセスポリシーでローカル転送またはリモート転送を許可している場合です。
tailnet上で通常のOpenSSHを使っている場合は、TS-2026-014の対象ではありません。

Tailscale SSHのサーバーとして接続を受け付けられるのは、公式文書ではLinuxと、macOSのオープンソース版tailscaledです。
ソースコード上は、FreeBSDとOpenBSDもSSHサーバーのビルド対象に含まれています。
Windows、iOS、Android、およびmacOSのApp Store版・スタンドアロン版はTailscale SSHのサーバーとして動作しないため、これらの端末がTS-2026-014とTS-2026-015の影響を受けることはありません。
ただし、これらの端末がSSHの接続元として攻撃者に操作され、Linuxサーバーなどに接続される可能性は残るため、接続元の端末も更新の対象から外さないでください。

なお、同じUnixソケット転送の処理については、2026年6月3日に公開されたTS-2026-004で、シンボリックリンクを経由して特権ソケットに到達できる問題がTailscale 1.98.9で修正されています。
Tailwormの指摘は、その修正後のv1.104.2でも、root権限のまま処理するという構造が残っていたことを示したものです。
TS-2026-004は今回の修正ではないため、1.98.9以降であることを理由に対策済みと判断しないでください。

v1.104.4での修正内容

TS-2026-014の修正では、Unixソケット転送を、rootではなく認証されたユーザーの権限で実行するように変更されました。
v1.104.4のソースコード（ssh/tailssh/fwdmonitor.go）を確認すると、Unix系OSでは、転送するソケットの接続と待ち受けを、接続ごとに起動する監視プロセスの子プロセスが、認証されたローカルユーザーの資格情報で実行する構造になっています。
パスの許可リストの検査はtailscaled側に残りますが、実際の操作は一般ユーザーの権限で行われるため、検査を回避されてもroot専用のソケットには到達できません。
TCPの転送やエージェント転送も同じ仕組みに移されており、Tailscaleは個々の脆弱性の修正に加えて、関連する種類の問題を防ぐ構造的な対策を導入したと説明しています。

研究者は報告の中で、同種の問題がDropbear SSHでCVE-2025-14282として修正された例を挙げ、認証後すぐに接続ユーザーの権限に落とす設計が根本的な対策であると指摘していました。
v1.104.4の修正は、転送の処理について、その方向の設計に変えたものと言えます。

TS-2026-015：セッション処理のメモリ枯渇

TS-2026-015によると、Tailscale SSHのセッション中に送られる一部の制御メッセージの処理で、tailscaledのメモリ使用量に上限がなく、切断後も解放されない問題がありました。
原因は、Tailscale SSHが使っているSSHサーバーのライブラリ（tailscale/gliderssh）の処理にあり、修正はv1.104.4に含まれています。
この問題を正しく恐れるために、次の4点を押さえてください。

誰が悪用できるのか

そのサーバーへのTailscale SSHのログインを、sshルールで許可されたユーザーや端末だけです。
許可された端末が乗っ取られた場合は、その攻撃者も悪用できます。
ログインを許可されていない端末や、インターネット上の第三者からは悪用できません。

何が起きるのか

tailscaledがメモリ不足（OOM）で強制終了され、そのサーバーのTailscaleの通信がすべて切れます。
公式のLinuxパッケージでは、systemdの設定（Restart=on-failure）によりtailscaledは自動で再起動しますが、繰り返し攻撃されると停止と再起動が続くおそれがあります。

何が起きないのか

この問題だけでは、root権限の取得、データの窃取や改ざん、ほかのサーバーへの拡散は起きません。
影響は、そのサーバーの可用性に限られます。

どうすれば防げるのか

v1.104.4以降に更新すれば修正されます。
更新までの間は、Tailscale SSHのログインを許可する範囲を必要な送信元と宛先の組に絞ってください。
また、Tailscale SSHを有効にしているサーバーで、tailscaledのメモリ使用量と再起動の回数を監視すると、この問題が起きていることに気づけます。

Tailscale Serve・Funnelの問題

報告には、Tailscale ServeとFunnelに関する5項目が含まれています。
Tailscaleは、そのうち3項目を不具合として認め、v1.104.4で修正しました。

TS-2026-016

tailscale serveのTCP転送先にUnixソケットを指定すると、tailscaledの管理APIのソケットにも到達でき、ノードの完全な乗っ取りにつながる問題と、転送先の検査が設定の読み込み時にしか行われない問題です。
影響を受けるのは、Serveの設定を書き込めるローカルのオペレーターがいる端末か、転送先のパスにローカルユーザーが書き込める端末です。

TS-2026-017

TLSを有効にしたServeで、HTTP/2の同一接続上の並行ストリームが共通のコンテキストを共有し、別のマウント向けのTailscale-App-Capabilitiesヘッダーが送られる可能性がある問題です。
要件の異なるマウントが同じ端末に2つ以上あり、アプリケーション側でこのヘッダーを認可に使っている場合に影響します。

残る2項目のうち、Funnelの利用許可の検査はローカルの管理者権限がなければ回避できず、TS_SERVE_ALLOW_ALL_INTERFACESはtailnetの外にServeを公開するために明示的に有効にする設定であることから、Tailscaleは設計どおりの動作と説明しています。
研究者も、後者を脆弱性ではなく設定上の注意事項として分類しています。

App Connector（conn25）について

研究者は、実験的なApp Connectorの実装「conn25」で、アプリの利用を許可された端末が、そのアプリとは無関係の宛先（クラウドのメタデータサービス、社内LAN、Kubernetesクラスター内のサービスなど）へ通信を転送させられると指摘しました。
Tailscaleは、conn25は次世代のApp Connectorとして開発中の、まだリリースしていない機能であり、この問題を把握していたことがリリースしていない理由の一つであると説明しています。
また、現在提供中のApp Connectorは影響を受けないとしています。

研究者は、v1.104.2にconn25のコードが含まれていたことを根拠に指摘しています。
通常の運用でconn25が有効になる経路について、10月28日時点で本記事では確認できていません。
App Connectorを利用している場合は、App Connectorの利用を許可する端末を必要なものに絞ることを、v1.104.4への更新と合わせて確認してください。

headscaleとDERPクライアントについて

headscaleは、Tailscaleのコントロールプレーンを自前で運用するためのオープンソースの実装で、Tailscale社の製品ではありません。
Tailscale社のコントロールプレーン（SaaS）を使っている場合、headscaleの問題は影響しません。

研究者は、インターネットから到達できるheadscale 0.29.5に対して、アカウントなしでメモリを枯渇させてクラッシュを繰り返させたり、新しい端末の登録を妨げたりできると報告しています。
headscaleは10月24日に0.29.6を公開していますが、CHANGELOGに記載されたセキュリティ修正は、eMudhraの中間証明書の失効（TS-2026-013と同じ件）とGoの依存ライブラリの更新で、Tailwormの指摘への対応は含まれていません。
研究者は10月28日時点の対応表で、headscale側の修正を「pending」としています。

また研究者は、headscale 0.29.5では、SSHが許可されたセッションで転送が無条件に許可されるため、headscaleでのSSHの許可はroot権限の付与と同等に扱うべきだと指摘しています。
headscale 0.29.5のソースコード（hscontrol/noise.go、hscontrol/policy/v2/filter.go）でも、許可（accept）したSSHセッションに対して、ローカル転送とリモート転送を許可する値が固定で設定されていることを確認できます。
ただし、端末側の環境変数TS_SSH_DISABLE_FORWARDINGはv1.104.2にも実装されており、ソースコード（ssh/tailssh/tailssh.go）上、コントロールプレーンから届いた許可より先に判定されます。
そのため、headscale環境でも、端末側でこの環境変数を設定すれば転送を無効にできます。
なお、v1.104.4に更新した端末では、転送の処理が接続ユーザーの権限で実行されるため、転送を経由してroot権限を得ることはできなくなります。
一方で、headscale環境ではSSHを許可すると転送も必ず許可されるため、そのユーザーの権限でサーバーから到達できるサービスへの転送経路を与えることになる点は、修正後も変わりません。
headscaleを運用している場合は、クライアントをv1.104.4以降に更新した上で、headscaleのメモリ上限と再起動の監視、登録APIへの到達範囲の制限を検討してください。

DERPクライアントの問題は、悪意のあるDERPリレーの応答を上限なく読み込んでしまうもので、クライアントを攻撃者が用意したリレーに接続させることが前提です。
Tailscaleのセキュリティ速報の対象には含まれていませんが、研究者はクライアント側の修正がv1.104.4に含まれていると記載しています。

Tailscale側の回答の要点

Mike Shaver氏のRedditでの回答は、修正版の公開前の時点のもので、次の点を述べています。
本記事では、Reddit上の投稿そのものではなく、International Cyber DigestのX投稿で紹介された全文を参照しています。

• 現時点の評価では、すべての利用者にTailscale SSHの無効化を推奨するものではない。
• 研究者の報告を受け取って確認中であり、エンジニアリングとセキュリティのチームは外部の専門家とともに、報告の前から独自に調査していた。
• 確認した問題の多くは、接続を許可された後の処理、特にUnixの権限とSSH転送の扱いに関するもので、設定されたローカルユーザーに許される以上の操作ができる場合がある。
• 深刻な問題ではあるが、認証されていない攻撃者が任意の端末に接続できることとは異なる。影響はSSHアクセスの設定によって変わる。
• 暫定的な対策として、SSHのアクセスポリシーと転送の許可を見直す、追加の認証としてチェックモードを検討する（ただし権限昇格の問題は解消しない）、自動更新を有効にする。
• 修正後に、確認された問題、影響を受ける構成、推奨する対応、修正版を説明するセキュリティ速報と、技術的な解説を公開する。

この回答で予告された内容は、10月26日の調査状況の報告、TS-2026-014〜017のセキュリティ速報、10月28日のブログ記事「Tailscale SSH: Findings and fixes」として公開されました。
ブログ記事では、Serve・Funnelの5項目のうち2項目を設計どおりとする判断や、conn25が未リリースであることも説明されています。

「ワーム」という表現について

研究者は、ラボ環境で、ポリシーでSSH接続が許可された端末に、パスワードや盗んだ鍵を使わずに1ホップあたり1秒未満で次々と広がることを確認したとして、「wormable」と表現しています。
一方でTailscaleは、自己複製するマルウェアが自動的に広がることを示したものではなく、tailnetポリシーファイルで許可された接続の範囲に限られた横展開（ラテラルムーブメント）と表現する方が適切だと説明しています。

両者の説明は、到達できる範囲がSSHのポリシーで許可された送信元と宛先の組に限られるという点で一致しています。
研究者も、送信元と宛先の組ごとにSSHを許可するポリシーが拡散を止めた唯一の制御であったと報告しており、TPMやSecure Enclaveに結び付いた端末鍵が、端末の識別情報の窃取を防いだとしています。
本記事の見解としては、「ワーム」という名称から受ける印象よりも前提条件は限定的ですが、タグ単位やグループ単位で広くSSHを許可しているtailnetでは、1台の侵害から多数のサーバーのroot権限に到達し得たという点で、軽視してよい問題ではありません。

開示の進め方について

研究者は、オープンソースのソフトウェアの脆弱性はすでに利用者を危険にさらしており、早く周知する方が修正の適用を早めるという立場を報告の中で示しています。
また、攻撃コード（PoC）は公開せず、Tailscaleのセキュリティ窓口にのみ共有したと報道機関に説明しています。
一方、Tailscaleによると、報告を受け取ってから公開までの時間は約2時間で、修正版の準備期間を設ける協調開示（Coordinated Vulnerability Disclosure）の形にはなっていません。

結果として、利用者は修正版の公開前に問題の存在を知って暫定対策を取ることができた一方、攻撃者にも同じ情報が渡りました。
開示の方法の是非には両方の立場に論拠があり、本記事では判断を示しません。
利用者にとって重要なのは、報告の公開から約3日でv1.104.4が配布され、修正済みであることを公式のセキュリティ速報で確認できる状態になったという事実です。

各メディアの報道の誤りと不正確な点

この件の報道は、修正版の公開前に書かれたものが多く、研究者の報告をそのまま要約した記事や、時間の経過で状況が変わった記事が混在しています。
ここでは、2026年10月28日時点で確認できた国内外の報道を、研究者の報告、Tailscaleの公式発表、Tailscaleとheadscaleのソースコードと照合し、誤りや不正確な点を整理します。
公開時点では正しかったが、その後の修正版の公開で状況が変わった記述は、誤りとは区別して扱います。
なお、検索した範囲では、国内の大手ITメディアによる報道は見つかりませんでした。

国内の報道

海外の報道

誤りや不正確な記述が生じた背景

誤りや不正確な記述が生じた背景には、次の事情があると考えます。

• 研究者の報告が修正版の公開前に出たため、報道が先行し、Tailscaleの公式説明（ワームではなく横展開であること、conn25は未リリースであること、FunnelとTS_SERVE_ALLOW_ALL_INTERFACESの2項目は設計どおりであること）は10月28日のブログ記事まで出ていませんでした。
• 研究者の報告は5つの分類と11の項目で構成されていますが、見出しでは最も影響の大きいTailscale SSHにまとめられ、件数だけが残りました。
• 研究者の報告にある「headscaleでは転送を無効化できない」という記述を、端末側の設定を確認せずにそのまま転載した記事が複数ありました。
• 米国と日本の時差により、報告の公開日、修正版のタグ付け、Changelogの日付が1日ずれて記載されている記事があります。日付自体の違いは、ここでは誤りとして扱っていません。

また、「認証なしで任意のTailscale端末に侵入できる」と読める表現も正確ではありません。
Tailscale SSHの問題を悪用するには、tailnet内でSSH接続を許可された端末をすでに攻撃者が操作できることが前提です。
認証なしで攻撃できるのは、インターネットから到達できるheadscaleに対するメモリ枯渇など、可用性に関する項目に限られます。
確認する時刻や参照する資料によって結論が変わる状況では、日付と参照先を明示した一次資料で判断してください。

利用者が確認・対応すべきこと

1. Tailscaleのバージョンを確認し、v1.104.4以降に更新する: 各端末でtailscale version --daemonを実行すると、CLIと稼働中のtailscaledのバージョンを確認できます。v1.104.2は今回の修正を含みません。Linuxでは、公式リポジトリから導入している場合はaptやdnfなどのパッケージ管理で更新でき、tailscale updateでも更新できます。自動更新はtailscale set --auto-updateで有効にできます。Tailscale SSHやTailscale Serveを有効にしているサーバーを優先して更新してください。macOS、Windows、iOS、Androidのアプリは、アプリの更新機能や各OSのアプリストアから更新します。これらの端末はTailscale SSHのサーバーにはなりませんが、接続元として使われる可能性があるため、あわせて更新してください。コンテナイメージやKubernetes Operatorで動かしている場合は、使っているイメージのタグが1.104.4以降であることを確認してください。tailscaledを再起動すると、確立済みのTailscale SSHのセッションは切断されます。
2. すぐに更新できない端末ではSSH転送を無効にする: tailscaledのサービスの環境変数にTS_SSH_DISABLE_FORWARDING=1を設定し、tailscaledを再起動します。公式のLinuxパッケージでは、systemdのユニットが/etc/default/tailscaledを環境変数のファイルとして読み込みます。この設定はTailscale SSH全体ではなく転送機能だけを無効にするもので、Tailscaleは重大な指摘のいくつかを緩和すると説明しています。転送を使う業務や自動化処理がないかを事前に確認してください。この設定で緩和できるのはTS-2026-014（転送を経由したroot権限の取得）だけです。TS-2026-015（メモリ枯渇）、TS-2026-016とTS-2026-017（Tailscale Serve）は、v1.104.4以降に更新しないと残ります。
3. SSHのアクセスポリシーを最小権限にする: SSHを許可する送信元、宛先、ログインするローカルユーザーを洗い出し、タグ単位やグループ単位の広い許可を、必要な送信元と宛先の組に絞ります。チェックモードは接続の開始時に再認証を求めるもので、確立したセッション内での権限昇格は防げない点に注意してください。
4. Tailscale Serveの設定を確認する: Unixソケットを転送先にしている設定、特にTCP転送の設定がないか、tailscale serve statusで確認します。TS_SERVE_ALLOW_ALL_INTERFACESを設定している場合は、必要性を見直してください。
5. App Connectorの利用許可を確認する: 現在提供中のApp Connectorは影響を受けないとされていますが、利用を許可する端末が必要なものに限られているかを確認します。
6. headscaleを運用している場合: headscale側の修正が出るまで、SSHの許可をroot権限の付与と同等に扱います。v1.104.4に更新できない端末では、2と同じくTS_SSH_DISABLE_FORWARDING=1を設定してください。その上で、headscaleのメモリ上限、再起動の監視、インターネットからの到達範囲の制限を検討してください。
7. 端末の追加とSSHの利用を記録・監視する: 研究者の攻撃手順は、端末登録用の鍵を取得して攻撃者の端末をtailnetに追加するところで完結します。構成監査ログで端末の追加や鍵の発行を確認し、重要なサーバーではTailscale SSHのセッション記録の利用を検討してください。ログは、侵害されたサーバーから削除・改ざんできない場所に保管してください。各機能の利用条件は公式文書で確認してください。
8. 侵害が疑われる端末がある場合: 端末の再インストールだけでは、すでに盗まれたノード鍵は無効になりません。管理コンソールで端末を削除し、ノード鍵の有効期限の設定と、Tailnet Lockの利用を検討してください。研究者は、Tailnet Lockが有効な環境では、攻撃者の端末をtailnetに登録する最後の段階が成立しなかったと報告しています。

Velumeshの見解

今回のTailscale SSHの問題は、接続の可否を判定する認証と認可ではなく、許可した後の権限の分離が正しく実装されていなかったというものです。
Tailscale自身も、権限の境界はTailscale SSHのセキュリティモデルの重要な部分であり、それを正しく適用できていなかったと認めています。
2026年には、Tailscale SSHについてTS-2026-009（ユーザー名の引数の扱いによるrootセッションの取得）、TS-2026-010（環境変数の値の漏えい）も公開されており、root権限で動作する組み込みのSSHサーバーという設計には、OpenSSHのような長い実績のある権限分離の仕組みと比べて、こうした問題が入り込む余地があったと考えます。

一方で、v1.104.4では、転送の処理を接続ユーザーの権限で実行する構造に変えており、個別の不具合の修正にとどまらない対応が取られています。
また、今回の攻撃の前提と拡散の範囲は、tailnetポリシーファイルで許可した送信元と宛先の組に限られます。
Tailscaleを使う場合も使わない場合も、端末が侵害されることを前提に、SSHの許可を必要最小限の組に絞り、端末鍵を失効させる手順を用意しておくことが、被害の範囲を決める要素であることに変わりはありません。

Velumeshでは、ご契約中のお客様からの、v1.104.4への更新手順、SSHポリシーの見直し、Tailscale SSHと通常のOpenSSHのどちらを使うべきかなどのご相談を、サポート窓口で受け付けています。

参考資料

• Tailworm — Security Assessment Report（Erica Windisch／Cyberdione Labs、2026年10月27日更新）
• Tailscale SSH: Findings and fixes（Tailscale、2026年10月28日）
• Tailscale SSH: Investigation and remediation update（Tailscale、2026年10月26日）
• Tailscale Security Bulletins（TS-2026-013〜017）
• International Cyber Digest: Mike Shaver氏のReddit回答の紹介（X、2026年10月25日）
• tailscale/tailscale v1.104.4（ssh/tailssh/fwdmonitor.go、修正後の転送処理）
• tailscale/tailscale v1.104.4（ssh/tailssh、ソースコード）
• Tailscale Packages - stable track
• Tailscale Changelog
• headscale CHANGELOG
• SecurityWeek: Tailscale Rushes Patches After Uncoordinated Disclosure of ‘Tailworm’ Flaws
• BleepingComputer: Tailscale warns of SSH flaws allowing root privilege escalation（2026年10月27日）
• MY TECH BLOG: Tailscale SSH 脆弱性報告（Tailworm）｜影響条件と暫定対策
• note（ゆいまる氏）: Tailworm解説記事
• Startup Fortune: Researcher publishes 11 unpatched Tailscale SSH flaws without warning（2026年10月26日）
• Aviatrix Threat Research Center: Tailworm 2026（2026年10月25日）
• IoT Tech News: Tailscale SSH flaw gives root on devices fleet-wide
• GBHackers: Tailscale SSH Vulnerabilities Allow Attackers to Gain Root Access to Connected Servers
• The Hacker News: Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
• juanfont/headscale v0.29.5（hscontrol、ソースコード）
• セキュリティ対策Lab: Tailscale SSHなどに11件の問題を指摘「Tailworm」（2026年10月28日更新）
• Tailscale SSH（Velumesh）

本記事は、2026年10月28日時点で確認できた一次資料に基づいています。
headscale側の修正やconn25の扱いなど、今後状況が変わる項目は、確認でき次第更新します。
Tailscaleの導入前設計、SSHポリシーの見直し、既存VPNからの移行などについてのご相談は、お問い合わせからご連絡ください。