Tailscale SSH 脆弱性報告（Tailworm）｜影響条件と暫定対策

はじめに

2026 年 10 月下旬、セキュリティ研究者の Erica Windisch 氏（Cyberdione Labs）が、Tailscale と headscale を対象とした調査報告「Tailworm」を公開しました。報告には 11 件の指摘（findings）が含まれ、Tailscale SSH の承認済みセッションから root 権限の操作に到達したラボでの実証結果も示されています。

一方、Tailscale 社は 10 月 25 日、VP of Engineering の Mike Shaver 氏がコミュニティへ暫定声明を投稿し、調査を進めていることと、Tailscale SSH の一律無効化は推奨しないことを示しました。研究者の主張とベンダーが確認した範囲には差があり、「自社環境は関係するのか」「修正版を待つ間に何をすべきか」を判断しにくい状況です。

2026 年 10 月 25 日時点で、Tailworm の指摘に対する Tailscale の修正版と Security Bulletin は公開されていません。現行の最新版へ更新するだけでは対応完了にならないため、まず Tailscale SSH の許可ルールを、必要な接続元と接続先の組み合わせまで絞り込むことを推奨します。影響の中心は Tailscale SSH の組み込みサーバーを有効にしたホストで、Tailscale 上で通常の OpenSSH を使う構成とは前提が異なります。

Tailworm で何が報告されたのか

Tailworm は、Tailscale クライアント v1.104.2 と headscale v0.29.5 を 2026 年 10 月 22〜24 日に調査した報告です。指摘は Tailscale SSH に限らず、Serve / Funnel、実験的な app connector、headscale の制御サーバーにも及ぶため、まず情報の確度と対象機能を分けて整理します。

公式確認済み・研究者の報告・未確定事項の区別

Tailscale 側の暫定声明は、Reddit の公式コミュニティに投稿されたものです（Recent Tailscale vulnerability reports）。声明では、承認済み接続後の Unix 権限や SSH forwarding に関する問題を調査していること、影響する構成の全容は検証中であることが示されています。そのうえで、SSH アクセスポリシー、forwarding 権限、check mode、自動更新の確認を勧め、確定事項と修正版を含む Security Advisory を今後公開するとしています。

11 件の指摘の分類と影響範囲

11 件の指摘は研究者が付けた内部の分類で、確認時点で今回の報告に対応する CVE は確認できていません。重要度も研究者自身の評価です。企業運用で優先度が高いのは Findings 1〜3 で、その他は特定の機能や設定を使う場合に限られます。

Finding 6 は成立条件の異なる 3 つの内訳を含みます。C2 は headscale の組み込み DERP サーバーでメモリが増え続ける問題で、認証済みの内部利用者が前提です。C4 は認証キャッシュに関する問題で、認証前の登録リクエストを大量に送ることで、承認待ちの登録が追い出されます。C3 は Tailscale クライアント側の DERP 処理の問題で、悪意ある中継サーバーへ接続することが前提です。いずれもサービス停止につながる可用性の問題で、headscale を外部へ公開していることだけで成立するものではありません。

過去の Security Bulletin との違い

Tailscale は 2026 年に Unix socket に関する問題を修正済みですが、Tailworm はその修正を含む v1.104.2 を対象にした報告です。また、10 月 21 日の TS-2026-013 は証明書に関する別件のため、「v1.104.2 への更新」と Tailworm の対応を結び付けないよう注意が必要です。各 Bulletin の詳細は Tailscale Security Bulletins で確認できます。

Tailscale SSH 権限昇格の仕組みと権限境界

Findings 1〜3 の要点は、承認済みの SSH セッションで行う Unix socket の操作が、接続したユーザーの権限ではなく、root で動作する tailscaled の権限で実行される点にあります。

通常の SSH と Tailscale SSH の認証の違い

通常の OpenSSH は、公開鍵やパスワードで接続するユーザーを認証します（公開鍵認証の仕組みは「Windows で SSH 公開鍵認証を設定｜パスワードなし接続の手順」で解説しています）。Tailscale ネットワーク上で OpenSSH を使う構成でも、この認証の仕組みは変わりません。

Tailscale SSH を有効にすると、Tailscale IP あての 22 番ポートを tailscaled の組み込み SSH サーバーが受け持ちます。公式ドキュメントによると、SSH の認証フェーズは none で完了し、WireGuard のノード鍵で識別したデバイスに対して、ポリシーの ssh ルールが接続元・接続先・ログインユーザーを認可します。公式ドキュメントは、クライアント側のどの OS ユーザーでも接続できる点にも触れ、Tailscale SSH が適さない場合がある構成を挙げています。

参考: Tailscale SSH · Tailscale Docs
“Tailscale SSH may not be a good fit for: multi-user machines”
（Tailscale SSH は、マルチユーザーのマシンには適さない場合があります）
https://tailscale.com/docs/features/tailscale-ssh

Unix socket forwarding が root 権限で動く意味

SSH には、ポートや Unix socket を接続の両端で中継する forwarding 機能があります。Findings 1〜2 は、このうち Unix socket の forwarding を対象としています。

ローカル転送（ssh -L）

クライアント側で受けた通信を、サーバー側の socket へ接続（dial）して中継します。研究者は、root でしか書き込めない socket にも tailscaled が接続できたと報告しています（Finding 1）。

リモート転送（ssh -R）

サーバー側に socket を作成して待ち受けます。研究者は、root が所有する既存の socket を削除して置き換え、正規のサービスになりすませたと報告しています（Finding 2）。

OpenSSH との違い（研究者の比較）

OpenSSH は認証後にセッションのユーザー権限へ切り替えてから転送処理を行うため、ソースコードの監査結果として、既定構成では同種の問題に該当しないと評価しています。Dropbear は同種の問題（CVE-2025-14282）を 2025.89 で修正済みです。

Docker の /var/run/docker.sock のように、アクセスできればホストの root 権限に近い操作ができる socket は少なくありません。一般ユーザーとして直接アクセスできない socket でも、root の tailscaled が代わりに接続すれば、OS のファイル権限による制限は働きません。SSH 接続が承認されていることと、その接続から実行できる操作が OS 権限で適切に制限されていることは、別の問題です。

TOCTOU で許可リストが境界にならない理由

Tailscale SSH は、転送に使える socket のパスをホームディレクトリ、/tmp、/run/user などに制限しています。研究者によると、この検証はパスの文字列に対して行われ、実際の作成・削除・接続はその後でカーネルが改めてパスを解決する時点で行われます。この検証時（Time of Check）と利用時（Time of Use）の差を突き、セッション内でパスの実体を高速に入れ替えると、許可リスト外の socket やファイルを操作できたと報告されています（Finding 3）。

TS-2026-004 の修正は、検証時にシンボリックリンクの宛先も評価するものでした。研究者は、その修正を含む v1.104.2 でも検証後の入れ替えが成立したとしています。ただし、この評価は研究者の報告であり、Tailscale が確定した影響範囲ではありません。

研究者が実証した影響

研究者が前提とした条件は、ポリシーで SSH 接続を許可された端末を 1 台掌握していることです。接続先での sudo 権限や docker グループへの所属は不要としています。ラボで示された主な結果は次のとおりです。

• Docker の socket 経由でホストのファイルシステムをマウントしたコンテナを起動し、root で実行（SELinux を強制する環境ではホストファイルの読み取りが阻止されたとの注記あり）
• systemd の管理用 socket 経由で root のシェルを取得（競合に勝つ確率は 0〜4% で断続的）
• tailscaled の LocalAPI の socket を乗っ取り、ノード登録用の authkey を取得して、Tailnet Lock を無効にした既定構成で別のノードを参加させた（ラボで実施後に復元）
• root が所有する任意のファイルの削除や、パーミッションの変更

研究者はラボで、ポリシーが許可する範囲の端末へ自動的に広がる様子も計測しています。その中で拡大を止められた対策は、接続元と接続先の組み合わせごとに許可を絞ることだけだったと報告しています。研究者は再現用の PoC も公開していますが、本記事では手順を扱わず、MY TECH BLOG でも再現は行っていません。

影響条件と Tailscale SaaS / headscale の違い

Findings 1〜3 はクライアント側の tailscaled に関する指摘のため、制御プレーンが Tailscale SaaS でも headscale でも対象になり得ます。一方で、forwarding を許可する条件と check mode の承認範囲は、制御プレーンによって異なります。

Tailscale SaaS と headscale の比較

headscale v0.29.5 の公開ソースを確認したところ、accept ルールに対応する SSHAction は AllowLocalPortForwarding、AllowRemotePortForwarding、AllowAgentForwarding を固定で true に設定していました（hscontrol/policy/v2/filter.go）。check の承認後に返す SSHAction も同様でした（hscontrol/noise.go）。ポリシーの SSH ルールの定義にも、forwarding を指定するフィールドはありません。

10 月 24 日に公開された v0.29.6 のソースでも、同じ箇所の設定は変わっていませんでした（v0.29.6 の filter.go / v0.29.6 の noise.go）。この確認は、「headscale では承認済みセッションの forwarding を制限できない」という研究者の報告が、公開ソースの実装と整合することを示すものです。ソースコードの記述を確認したもので実機での動作確認ではなく、headscale の開発元が脆弱性として認定したことを意味するものでもありません。

Tailscale SaaS について研究者は、ルールごとの forwarding フラグを無効にするよう推奨しています。Tailscale のクライアントが受け取る SSHAction には forwarding を制御するフィールドがありますが、公開されている policy file の構文リファレンスで、ssh ルールに指定できる項目は action、src、dst、users、checkPeriod、acceptEnv、srcPosture だけです。利用者が forwarding を無効にできるかどうかは、Tailscale のサポートや今後の Security Advisory で確認する必要があります。

check mode で防げること・防げないこと

SSH ルールの action は、accept と check の 2 種類です。accept は tailnet で認証済みのユーザーをそのまま受け入れ、check は接続前に ID プロバイダーでの再認証を求めます。再認証が不要な期間は checkPeriod で指定し、既定値は 12 時間で、1 分〜168 時間または always（毎回）を設定できます。policy file のリファレンスでは、checkPeriod は Premium / Enterprise プランの機能とされています。

参考: Tailworm
“It does not mitigate the forwarding findings (1–3).”
（check mode は forwarding に関する指摘（1〜3）を緩和しない）
https://tailworm.com/

研究者は、Tailscale SaaS では 1 回の承認が tailnet 内の check 対象全体に及ぶのに対し、headscale では接続元と接続先の組み合わせに限られると評価しています。そのうえで、高権限のルールには短い checkPeriod か always を使うことを勧めています。check mode は認証を強める補助策として有効ですが、今回の指摘を解消する対策ではありません。

公式ドキュメントでは、checkPeriod に always を設定すると、Ansible のように短時間に多数の SSH 接続を開く自動化ツールで想定外の動作になる場合があると注意しています。自動化に使うルールを分けてから変更することをおすすめします。

Serve / Funnel と conn25 の影響条件

Serve / Funnel と conn25 の指摘は SSH とは別の機能に関するもので、いずれも特定の設定や機能を使う場合に限られます。

Finding 7

tailscale serve の TCP 転送で tailscaled 自身の socket を転送先に設定した場合に、他のピアからローカル管理 API を操作できるという指摘です。前提は、ホスト上の運用者がその転送を設定していることです。

Finding 8

設定後に転送先の Unix socket のパスをシンボリックリンクへ差し替えると、設定時のチェックを迂回できるという指摘です。そのディレクトリへの書き込み権限が前提です。

Finding 9

Funnel の有効化がクライアント側の設定に依存するという脅威モデル上の指摘です。研究者は headscale で検証するため、テスト用の設定値で条件を補っており、通常の Funnel 利用と同じ構成ではありません。

Finding 10

既定でオフの TS_SERVE_ALLOW_ALL_INTERFACES を有効にすると、Serve の待ち受けが Tailscale のインターフェースに限定されなくなるという設定上の注意です。研究者によると、そのノードの Tailscale IP への経路を持つ LAN などのネットワークからは、WireGuard や tailnet のアクセス制御を経由せずに Serve のバックエンドへ到達できます。Tailscale の Changelog によると、Kubernetes Operator は一部の実験的な Ingress でこの値を設定します。

Finding 11

HTTP/2 の接続を共有するとアプリケーションの権限ヘッダーが別のパスへ混入するという指摘で、そのヘッダーで認可するアプリケーションを複数のパスで公開している場合に限られます。

conn25 は v1.104.2 時点で実験的な app connector の機能です。研究者は、利用を許可されたクライアントが中継先を任意に指定でき、クラウドのメタデータサービスや社内 LAN へ到達できたと報告しています。conn25 を構成していない環境は対象外で、構成している場合は利用権限の見直しと、connector 側での宛先の制限が研究者の推奨です。

Tailscale SSH 対策: 運用担当者が確認すべき設定

Tailscale は Tailscale SSH の一律無効化を推奨していません。修正版の公開までは、影響の条件を満たすホストとルールを特定し、許可範囲を絞ることが中心になります。次の順に確認することをおすすめします。

修正版公開前に確認する 6 項目

tailscale version --daemon

対応優先度の考え方

次の分類は、Tailscale が確定した影響範囲ではなく、研究者の報告に基づく運用上のリスク評価です。

OpenSSH へ切り替える場合の注意

共有サーバーなど特に影響の大きいホストでは、Tailscale SSH を停止し、Tailscale 上で通常の OpenSSH を使う構成へ一時的に切り替える選択肢もあります。公式ドキュメントでは、ホスト単位の停止に tailscale set --ssh=false を案内し、停止前に別の SSH 接続手段を確保するよう注意しています（Tailscale SSH · Tailscale Docs）。

このコマンドを実行するだけで安全に移行できるわけではありません。事前に次の点を確認してください。

• OpenSSH（sshd）が稼働し、Tailscale IP で待ち受けていること
• 公開鍵の配布やパスワード認証の可否など、認証設定が運用方針に合っていること
• tailnet のアクセス制御で、22 番ポートへの接続元が必要な範囲に限定されていること
• コンソール接続など、SSH 以外の代替管理経路が使えること

Tailscale SSH の停止は、ポリシーの許可を絞っても影響が残るホストに限定し、作業を始める前に別の管理経路で接続を確認しておくことをおすすめします。切り替え後は、OpenSSH 側の認証と転送の設定にも同じ水準の管理が必要です。

公式修正の状況と今後の更新判断

確認時点で公開されている最新版は、いずれも Tailworm への修正を明記していません。状況は Tailscale Security Bulletins、headscale のリリース、headscale の CHANGELOG で確認できます。今後の Security Advisory で、修正版と影響する構成を確認してから対応完了を判断する必要があります。

確認時点の公式状況

headscale v0.29.6 は eMudhra 証明書への対応を含むため、それ自体は適用を検討する価値があります。ただし、v0.29.6 への更新で Tailworm の指摘が解消されたと判断することはできません。

修正版公開後の対応完了条件

まとめ

Tailworm が示したのは、Tailscale SSH で接続が承認された後も、root で動く tailscaled による操作が OS 権限の制限を越え得るという権限境界の問題です。確認時点で修正版は公表されていないため、更新を待つだけでなく、SSH ルールの許可範囲を絞ることが現実的な対策になります。

• 11 件は研究者の分類で、対応する CVE は確認できていない
• 影響の中心は、Tailscale SSH を有効にしたホストの forwarding
• headscale は公開ソース上、承認済みセッションに forwarding を常に許可する
• check mode は接続前の再認証で、承認後の操作は制限しない
• 最優先は、SSH ルールを接続元と接続先の組み合わせまで絞ること
• v1.104.2 や headscale v0.29.6 への更新では、対応完了と判断できない

以上、最後までお読みいただきありがとうございました。