Tailworm：Tailscale SSHからrootへの権限昇格

要点

• Tailscale SSHの組み込みサーバーはrootで動くデーモンtailscaled内で稼働し、Unixソケット転送の接続、bind、unlinkをrootの認証情報で実行します。承認済みSSHセッションはこれを使ってroot専用ソケットに到達できます。研究者は、docker.sock経由のrootコマンド実行、systemd制御ソケット経由のrootシェル、新しいデバイスを登録する鍵の取得を実証しました。
• 監査ではリリース済みのTailscaleクライアント1.104.2、headscale 0.29.5、Tailscale組み込みのglidersshライブラリをテストしました。Tailscaleは10月27日に1.104.4で修正を提供し、10月28日に調査結果と4件のセキュリティ速報を公開しました。
• 研究者は11件の検出結果のうち6件をHighと評価しており、ソケット転送の問題群も含まれます。Tailscaleの速報TS-2026-014～TS-2026-017は確認されたSSHとServeの問題を扱っています。10月28日時点でCVE識別子やCVSSスコアは記載されていません。悪用はラボのみで実証されました。パスワードや盗んだ鍵なしで、ポリシーの範囲内を1ホップ1秒未満で自動伝播することが測定されています。実環境での攻撃は確認されていません。
• tailscaledサービスの環境でTS_SSH_DISABLE_FORWARDING=1を設定して今すぐサービスを再起動し、SSHルールを送信元と宛先のペアごとの許可に書き換え、クライアントを1.104.4以降にアップグレードしてください。headscaleサーバーの検出結果は別です。Tailscaleクライアントを更新してもheadscaleの制御サーバーの問題は修正されません。

レポートは検出結果に以下の番号を付けています。重大度は研究者による評価です。

Tailscaleの評価は、バグと意図した動作を区別しています。検出結果9と10は設計どおりに動作しており、検出結果4が対象とするのは安定版アプリコネクターではなく、本番前のconn25です。

影響を受けますか？

Tailscale SSHのソケット転送による権限昇格。 未修正のクライアントで次の条件をすべて満たす場合、影響を受けます。

• 対象ノードでTailscale SSHを有効にしてTailscaleクライアントを実行している。
• SSHポリシーが、acceptルールまたは承認済みcheckセッションを通じ、接続するユーザーまたはデバイスが転送を有効にした状態で対象に到達することを許可している。headscale 0.29.5は受け入れたセッションに転送を許可し、ルールごとの無効化スイッチがありません。
• 接続元デバイスが侵害されている、または接続ユーザーが攻撃者である。これらの検出結果は完全に非特権のアカウントから機能し、対象側のパスワード、鍵、sudoは不要です。

headscale制御サーバーのサービス拒否（検出結果6）。 インターネットから到達可能なheadscale 0.29.5登録エンドポイントは、アカウントもSSHアクセスもなしで攻撃できます。レポートでは、組み込みDERPのメモリ枯渇には認証済みの内部ユーザー、Tailscaleクライアントのレスポンス本文攻撃には悪意あるリレーが必要だと、それぞれ別に示しています。

実行中のものと、ポリシーが許可する内容を確認してください。

tailscale version                     # client version on every node
tailscale status                      # the peers this device can see
headscale version                     # self-hosted control server, if you run one
sudo systemctl show tailscaled --property=Environment   # is TS_SSH_DISABLE_FORWARDING set?

監査は、テスト環境でノードがtailnetのピアを列挙できたと報告しています。ポリシーが秘密であることに依存しないでください。SaaSデプロイメントではTailscale管理コンソール、headscaleではポリシーファイルでSSHルールを確認し、送信元デバイス1台から宛先デバイス1台への許可ではなく、ID全体やタグ全体に及ぶacceptルールがいくつあるか数えてください。

どう修復しますか？

Tailscaleクライアントを1.104.4以降にアップグレードしてください。更新を計画している間は転送による露出を減らし、SSHアクセスを絞ってください。headscale制御サーバーの強化は別の作業です。

1. 必要性が文書化されていなければSSH転送を無効にします。tailscaledサービスの環境で次を設定します。

sudo mkdir -p /etc/systemd/system/tailscaled.service.d &&
  printf '[Service]\nEnvironment=TS_SSH_DISABLE_FORWARDING=1\n' |
  sudo tee /etc/systemd/system/tailscaled.service.d/disable-forwarding.conf &&
  sudo systemctl daemon-reload &&
  sudo systemctl restart tailscaled

Tailscaleの10月26日の更新は、Tailscale SSH全体を無効にせずに、これで「より深刻な検出結果のいくつかを緩和する」と述べています。SaaS制御プレーンではルールごとの転送フィールドを拒否に設定することもできますが、headscale 0.29.5には同等のルール単位スイッチはありません。サービス環境設定はTailscaleクライアントごとに適用します。

1. SSHルールをペアごとの許可に書き換えます。特定の送信元から特定の宛先へとし、ID全体やタグ全体のacceptルール、特権の宛先アカウントは使用しません。ただしSSHを非特権アカウントに限定することは多層防御にすぎません。これらの検出結果は完全な非特権アカウントから機能するためです。
2. 各クライアントにTailscale 1.104.4以降をインストールし、tailscale versionで確認します。Tailscaleの10月28日の調査結果と修正から、速報TS-2026-014～TS-2026-017を参照できます。
3. 自己ホスト型headscaleサーバーには、修正版が出るまでレポートの強化策を適用します。systemdのMemoryMax、再起動の監視、登録エンドポイント手前でのレート制限、公開インターネットへの非公開化です。
4. tailscale serveを実行している場合は、Unixソケットを宛先にするTCP転送（serve --tcp <port> unix:<path>）を削除します。
5. 実験的conn25をテストしている場合は、不要なクライアントからケイパビリティを除去し、Kubernetesのコネクター名前空間へデフォルト拒否の送信NetworkPolicyを適用し、コネクターホストでカーネル層の宛先許可リストを強制します。このためのスクリプトがレポートに付属します。Tailscaleは安定版アプリコネクターには影響がないとしています。

根本原因は何ですか？

Tailscale SSHの転送処理はrootデーモンの認証情報で実行されるため、それを制約しようとするすべてのパス確認が、非特権セッションが勝てる競合になります。

2つの設計判断が組み合わさって問題になります。まず、Tailscale SSHはユーザーレベルの認証を行いません。WireGuard層がすでにデバイスを識別しているため、認証はnone方式で完了します。ポリシーが評価するのはユーザー認証情報ではなくそのデバイスIDなので、セッションは有効期間中ずっとデバイスの全認可を持ちます。

次に、組み込みSSHサーバーはrootで稼働するtailscaled内にあり、glidersshライブラリはUnixソケット転送処理、つまりssh -Lの接続、ssh -Rのbindとunlinkをrootとして実行します。

ライブラリは転送先を制約しようとはしています。tailscale/glidersshのstreamlocal.goにあるvalidateAndResolveSocketPathとvalidateAndResolveListenPathは、操作実行前にパスをディレクトリ許可リストと照合し、シンボリックリンクを解決します。最終的な接続を行うのは検証処理ではなくカーネルだからです。

// validateAndResolveSocketPath validates socketPath lexically, then resolves
// its symlinks and re-checks that the real destination is still within
// opts.AllowedDirectories and not excluded by opts.DeniedPrefixes. It returns
// the resolved path to dial.
//
// The lexical check alone is insufficient because the kernel connects to the
// symlink target: a symlink inside an allowed directory could otherwise
// redirect the connection to a socket outside it (e.g. a link in the user's
// home dir pointing at /var/run/docker.sock).

go.modによれば、Tailscale 1.104.2はglidersshのv0.3.4-0.20260716005906-1a0f895faf28を組み込み、許可リストはユーザーのホームディレクトリ、/tmp、/run/user/<uid>を含みます。しかし検証は確認時点で行われ、unlink、bind、接続は後にカーネルがパスを再解決するときに起きます。

検出結果3はその隙間を示しています。攻撃者自身のSSHセッション内のrename(2)競合ループは、毎秒約170,000回のパス状態切り替えと測定され、確認時には無害なパスを提示し、rootデーモンが操作する前にディレクトリを標的へ切り替えます。レポートの結論は1行で、{home, /tmp, /run/user}許可リストは「セキュリティ境界ではない」です。

この問題群にはCVEで認識された先例と既知の解決策があります。DropbearのCVE-2025-14282は接続側の事例で、2025.89で修正されました。転送操作前にsetuid()でセッションユーザーへ切り替えるため、パス確認は不要です。レポートで監査されたOpenSSHは明確な対照例です。認証後の子プロセスがサーバーループ前にセッションユーザーへ権限を落とすため、確認段階も確認と使用の間の隙間もありません。

どのように悪用されますか？

最も単純な実証である検出結果1には、ローカル転送を許可するSSHポリシールールが1つあれば足り、競合なしでrootによる接続を示します。コマンドはレポートの公開再現キットからのものです。

ssh -fNT -L /tmp/relay.sock:/tmp/docker.sock user@target   # dockerd at an allowlisted-dir socket
docker -H unix:///tmp/relay.sock run --rm -v /:/host busybox sh -c 'id; head -c 40 /host/etc/shadow'

接続を行うのはtailscaledなので、ソケットが見るピア認証情報はrootのものです。確認された結果は、sudoもDockerグループへの所属もなしでのuid=0(root)と/etc/shadowの内容でした。この実証はtailscaledを通じて対象の標準dockerdを使います。仕込んだデーモンも、別のdockerd脆弱性も不要です。最も強力な連鎖である検出結果3は、確認と使用の隙間を競合させます。

1. 攻撃者は、悪用したWebアプリケーション、悪意ある依存関係、フィッシングで侵入させたインプラント、または盗んだID認証情報から、ポリシーで許可されたデバイス上に足場を得ます。転送を許可するルールの下でTailscale SSHを介して対象へ接続します。
2. セッション内で、許可リスト内のディレクトリに対してrename(2)競合ループを実行し、パス状態を毎秒約170,000回切り替えます。文字列上の確認には無害なパスを見せ、操作時のカーネル再解決では標的に向けます。
3. rootデーモンが実パスにある稼働中のroot所有ソケット、たとえば/run/docker.sock、tailscaledのlocalapiソケット、headscale制御ソケットをunlinkし、そこに攻撃者の転送リスナーをbindします。
4. 攻撃者は再bindを確認済みで4分以上維持し、サービスへの中間者として動作します。localapiソケットに対して捕捉されたトラフィックには、新しいデバイスを登録する認証情報authkeyを含む、バイト単位で正確なPOST /localapi/v0/startがありました。
5. 攻撃者は取得したauthkeyを一時ノードで使用し、被害者のIDでtailnetへ参加させます。正当なタグ付きサーバーに見え、ルートが自動承認される不正ノードです。この一連の流れがラボで実証されました。

付随する検出結果は手段をさらに拡張します。unlinkの制御とlisten後のchmodは使用時に文字列上のパスをたどるため、競合するセッションはrootに任意の通常ファイルをunlinkさせ、0600へchmodさせられます。内容の変更には至らないものの破壊が可能です。

攻撃はどのように進行しますか？

承認済みSSHルールを持つ侵害デバイス1台が、対象サーバーのroot権限を得て、さらにネットワーク上の永続的なノードになります。連鎖のどこでもパスワードや鍵の窃取は不要です。

攻撃者は何ができますか？

ソケットの乗っ取りは、Unixソケット上で動く特権サービスに到達します。レポートでエビデンスとともに実証された内容は次のとおりです。

• 競合させた標準dockerd経由のrootコマンド実行。競合に成功した1本のkeep-alive接続で、/をコンテナー内へbindマウントしたコンテナーの作成と、uid 0でのコマンド実行が完了しました。
• systemd制御ソケット経由のrootシェル。/run/systemd/privateへのroot認証情報による接続はsystemdに認可され、再送したD-Busバイト列が一時ユニットを開始してrootリバースシェルを生成しました。競合による到達は断続的でした。kubeletソケットのスタブへの競合接続も同様に、uid 0を提示してすべて受け入れられました。
• デバイス登録認証情報の窃取。ソケット乗っ取りから登録までの連鎖は、再bindを自動承認ルート付きの不正ノードへ変えます。これは元ホストの再イメージ化後も残る永続化です。さらに任意のrootファイル削除と強制chmod 0600による可用性破壊も可能です。
• 全端末への拡散。ポリシーでSSH経路が許可されていると、パスワード、盗んだ鍵、ユーザー操作なしで、ポリシーが許可するすべてのデバイスへ1ホップ1秒未満で自動伝播することが測定されました。構造的な制限が2つあり、ペアごとのアクセス許可は拡散を止め、ハードウェアに紐付けられたデバイス認証情報はID窃取の永続化を防ぎました。
• rootデーモンのメモリ枯渇、検出結果5。window-changeの大量発生と無制限の環境変数追加により、7秒で約536 MBが割り当てられ、切断後も残りました。上流のgliderlabs/ssh v0.3.8から引き継いだ欠陥です。
• アプリコネクターの送信先検証、検出結果4。実験的conn25では、通常のアプリ単位ユーザー権限で、クラウドメタデータやKubernetesサービスを含む任意の送信先をコネクター経由で選択できます。クライアントが宣言した宛先が、アプリの設定済みバックエンドと照合されないためです。Tailscaleは安定版アプリコネクターには影響しないとしています。
• headscaleのサービス拒否、検出結果6。未認証で登録キャッシュの追い出しを起こすと、組織全体の新規参加を阻害できます。組み込みDERPのメモリ枯渇には認証済み内部ユーザーが必要です。Tailscaleクライアント側の付随する検出結果には悪意あるリレーが必要です。

ソケット転送の条件は、ポリシーが許可するSSHアクセスを持つ承認済みまたは侵害済みデバイスと、未修正クライアントでの転送有効化です。headscale 0.29.5はルール単位の無効化スイッチなしで転送を許可します。SSH向けにブラウザーで再認証するTailscaleのcheckモードは転送を制御しません。承認するのはセッション確立であり、その後ソケット転送の検出結果は承認済みセッションの有効期間中ずっと機能します。

なぜ修正が有効なのですか？

検出結果1～3に対するSSH転送の修正は、セッションユーザーとしてソケット操作を実行します。これはレポートが推奨し、以前にDropbearのCVE-2025-14282修正で使われた権限分離です。 Serveとリソース枯渇の検出結果には別々の修正があります。レポートの上流対応節とTailscaleのセキュリティ速報によると、次のとおりです。

• 検出結果1～3：SSH転送は、非特権でユーザー認証情報を持つ子プロセスを備えた接続ごとのモニターへ再設計されました。転送ソケットの接続、bind、unlinkは認証済みセッションユーザーの認証情報で実行され、ペイロードのピア認証情報もrootデーモンではなくそのユーザーを示します。競合で破られた文字列上のパス再検証は取り除かれ、カーネルの任意アクセス制御が境界になりました。
• 検出結果5：glidersshのwindow-change送信は最新値を保持する非ブロッキング方式となり、環境変数の大量変更にも上限が設けられました（PR #21945、#21953。上流コミットメッセージは監査の測定結果に謝辞を記載）。
• 検出結果7：localapiソケットへのserve TCP転送を、設定時と接続ごとに拒否します（PR #21966）。
• 検出結果8：Serve HTTPプロキシのUnixバックエンド宛先を接続のたびに再検証し、設定再読み込み時だけのシンボリックリンク保護を置き換えます。Tailscaleはこの修正をTS-2026-016に示し、1.104.4で提供しました。
• 検出結果11：ケイパビリティ処理をリクエストごとのコンテキストへ移します（PR #21931）。
• 検出結果6（クライアント）：リレーのレスポンス本文読み取りに上限を設けます（PR #21980）。

SSH転送では、接続、bind、unlinkがセッションユーザーとして実行されれば、セッションが何に触れられるかはカーネル自身の権限確認で決まります。昇格した権限による確認が不要なので、確認と使用の隙間はありません。Tailscale 1.104.4は10月27日にこれらのクライアント修正を提供し、ベンダーは10月28日に利用可能と確認しました。レポートがテストしたのはheadscale 0.29.5で、サーバー側の修正はまだ未完了とされています。Tailscaleクライアントを更新しても、そのheadscaleの検出結果は修復されません。

侵害されたかどうかを確認するには？

実環境での攻撃は確認されていません。未修正システムを調査するためのレポートの検出ガイダンスは次のとおりです。

• ソケットのライフサイクル監査。転送が許可されたディレクトリである/tmp、ホーム、/run/userと、エージェント自身のソケットパスに対して、Unixソケットのunlink、bind、chmod操作のauditdルールを設定します。システムコール名だけでなく、パスと操作によって対象オブジェクトを限定します。本来0600であるべきパスのソケットが0755なら、競合に勝ったbind後のchmodがリダイレクトされたことを示すフォレンジック上の特徴です。
• renameの大量発生の検出。競合には毎秒100,000回程度の持続的なディレクトリrenameループが必要です。候補ディレクトリへのinotifyまたは監査監視に頻度アラートを付けることで捕捉できます。
• 登録と鍵の監視。変更作業時間外のauthkey発行や使用、タグ付きIDの下で未観測の鍵を使って参加するノードにアラートを設定します。要求していないTailscale認証プロンプトが出たというユーザー報告はインシデントとして扱います。攻撃者の接続がcheckプロンプトを誘発できるためです。headscaleでは常駐メモリ、登録キャッシュの入れ替わり、登録遅延を監視します。

侵害のエビデンスが見つかった場合、再イメージ化だけでは封じ込めになりません。ノードのIDは状態ファイル内の鍵素材であり、rootを得た攻撃者がホスト外へコピーしていれば、制御プレーンでデバイスを削除するか鍵の期限が切れるまで有効です。デバイスを削除し、影響ホストから到達できたauthkeyと認証情報をローテーションし、署名ノードが侵害された場合はTailnet Lockもローテーションしてください。

タイムライン

• 2026-10-22～2026-10-24：Cyberdione Labsがリリース済みTailscale 1.104.2、headscale 0.29.5、組み込みglidersshライブラリをテスト。コネクターの検出結果は実験段階で本番前のconn25に関するものです。
• 2026-10-25：11件の検出結果と再現キットを含むTailwormレポートを公開。同日The Hacker Newsが報道。
• 2026-10-26：Tailscaleが「Tailscale SSH: Investigation and remediation update」を公開。設定されたローカルユーザーを超える深刻な権限昇格を確認し、テスト結果を条件に10月27日末までの修正クライアント提供を目標としました。検出結果1～3と5の修正がtailscaleとglidersshのmainブランチに入りました。
• 2026-10-27：検出結果7、11、クライアントリレーコンポーネントの修正をマージ（PR #21966、#21931、#21980）。headscale登録キャッシュの再設計PR #3586はまだ未完了。Tailscaleが修正クライアントに1.104.4のタグを付与。
• 2026-10-27：本記事。
• 2026-10-28：Tailscaleが速報TS-2026-014～TS-2026-017とともに調査結果と修正を公開。1.104.4の提供状況と残る対象範囲を反映するため、本記事を更新。

よくある質問

Tailscaleは全員にTailscale SSHを無効にするよう求めていますか？

いいえ。Tailscaleの10月26日の更新は、悪用が接続ユーザーやデバイスに付与された権限とシステム設定に依存するため、「全員がTailscale SSHを無効にすることは推奨しない」としています。未修正クライアントへの暫定対応は、転送を無効にし、SSHアクセスポリシーを見直し、機密性の高いシステムへのアクセスを絞ることです。10月28日のガイダンスは1.104.4以降へのアップグレードです。

checkモードは保護になりますか？

いいえ。checkモードが制御するのはセッション確立だけです。ポート転送は確立・承認済みセッション内で行われ、すべてのソケット転送の検出結果はその有効期間中に適用されます。レポートではSaaS制御プレーン上で、1回成功したcheckの承認が承認期間の終了までcheckモードの全宛先に使い回されることも測定しています。そのため、ユーザー自身の日常的な認可によって、攻撃者が狙う宛先への操作も可能になる場合があります。

Tailnet Lockは不正ノードの登録を止めますか？

難度は上げますが、ラボでは完全な阻止にはなりませんでした。デフォルトのTailnet Lock無効状態では、取得したauthkeyからオンラインの不正ノードまで、全連鎖が完了しました。有効な場合も無効化シークレットと署名鍵素材が転送中に捕捉されましたが、実際の無効化は実行されませんでした。署名ノードの侵害はクリーンアップではなく、ロックのローテーションとして扱ってください。レポートは各検出結果の再現キットを文書化しており、実デプロイメントに対して動くエクスプロイトは存在が確認されていません。

インターネットから悪用できますか？

SSHの検出結果を直接悪用することはできません。攻撃者にはポリシーがすでに許可するデバイス上の足場、または承認済みアカウントが必要です。レポートのラボでは、メッシュが1つの足場を、ポリシーで許可された宛先全体への特権アクセスへ機械的な速度で広げました。headscaleの検出結果は別です。未認証のインターネットユーザーは、到達可能な登録エンドポイントを通じて新しいデバイスの参加を妨害できます。これがエンドポイントを公開すべきでない理由です。

どのクライアントリリースが修正しますか？

Tailscale 1.104.4以降へアップグレードし、全ノードでtailscale versionを確認してください。Tailscaleの10月28日の調査結果と修正の記事、および速報TS-2026-014～TS-2026-017がリリースを確認しています。各クライアントの更新が終わるまではSSH転送を無効にし、ペアごとのSSH許可を使ってください。headscale制御サーバーの修正は別です。

Ostorlabで外部攻撃対象領域をスキャンし、インターネットに露出したheadscale制御サーバーや、本来公開インターネットから到達できるべきでない自己ホスト型インフラを可視化してください。

参考資料

• Cyberdione Labs「Tailworm: Security Assessment Report, Tailscale v1.104.2 and headscale v0.29.5」、2026年10月25日公開。11件の検出結果、検証済み再現手順、ワーム化の測定、検出ガイダンスを含み、緩和策一覧は10月28日更新：https://tailworm.com/ （2026年10月28日確認）
• Tailscale「Tailscale SSH: Investigation and remediation update」、2026年10月26日。検出結果、TS_SSH_DISABLE_FORWARDING=1の緩和策、10月27日末という修正クライアントの目標を確認：https://tailscale.com/ssh-investigation-update （2026年10月27日確認）
• tailscale/tailscaleの修正プルリクエスト：#21941、#21942、#21943、#21944、#21945、#21953、#21959、#21963、#21966、#21931、#21980（2026年10月28日確認）
• tailscale/glidersshのstreamlocal.go、validateAndResolveSocketPathとvalidateAndResolveListenPath関数。競合で破られる、文字列確認後に解決する検証：https://github.com/tailscale/gliderssh/blob/master/streamlocal.go （2026年10月27日確認）
• glidersshをv0.3.4-0.20260716005906-1a0f895faf28に固定するTailscale 1.104.2のgo.mod：https://github.com/tailscale/tailscale/blob/v1.104.2/go.mod （2026年10月27日確認）
• 同種の先例Dropbear CVE-2025-14282。チャネルまたはグローバルリクエストの前にセッションuidを設定することで2025.89で修正：https://nvd.nist.gov/vuln/detail/CVE-2025-14282 （Tailwormレポート経由で参照、2026年10月27日確認）
• レポートを引用し、追い出しより受け入れ制御を採用するheadscale登録キャッシュ再設計PR #3586：https://github.com/juanfont/headscale/pull/3586 （Tailwormの上流対応経由で参照、2026年10月27日確認）
• The Hacker NewsによるTailworm検出結果の報道、2026年10月25日：https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.html （2026年10月27日確認）
• Tailscale 1.104.4リリース：https://github.com/tailscale/tailscale/releases/tag/v1.104.4; ベンダーの調査結果と修正、2026年10月28日：https://tailscale.com/blog/tailscale-ssh-findings-fixes; セキュリティ速報TS-2026-014～TS-2026-017：https://tailscale.com/security-bulletins （2026年10月28日確認）