Tailworm：Tailscale / headscale における未修正の特権昇格・横展開脆弱性群

2026年10月25日、Cyberdione Labs のセキュリティ研究者 Erica Windisch 氏により、メッシュ VPN ソフトウェア「Tailscale（v1.104.2）」およびそのオープンソース版コントロールプレーン「headscale（v0.29.5）」に関する包括的なセキュリティ評価レポート「Tailworm」が公開されました。
本レポートでは、特権分離の欠如、競合状態（Race condition）、不適切なリソース制御などに起因する計11件の指摘事項（Finding 1〜11）が報告されています。
対象製品のパッチが提供されていない「ゼロデイ」の状態でのフルディスクローズ（即時全面公開）となっており、攻撃者が Tailnet（Tailscale ネットワーク）内の端末1台に初期足場を築いている場合、一般ユーザ権限から他ノードの root 権限を奪取し、ネットワーク全体へ自動横展開（ワーム化）が可能であると指摘されています。

本脆弱性情報の公開プロセスは、通例の「協調的開示（Coordinated Vulnerability Disclosure: ベンダーへ非公開で通報し修正後に公表）」とは異なり、ベンダー修正前に一般公開された点が特徴的です。
通常の手順が選択されなかった背景として、研究者は以下の主張・問題意識を公開理由として明示しています。

• 「ゼロトラスト」を標榜する設計上の問題提起:
  Tailscale はセキュリティを中核価値として打ち出している一方、歴史的に権限分離（Privilege Separation）が厳格に保たれてきた OpenSSH などのデーモンを高特権（root）で単一プロセス動作する独自実装へと置き換えるなど、多層防御の原則に逆行する設計選択がなされていると研究者は指摘しています。
• 運用の現場に対する即時注意喚起:
  研究者は「インフラはすでに今日この瞬間にも危険にさらされている」と評価しており、比較的容易に発見できる設計・実装上の欠陥であることから、事前に運用者へ広く周知して防衛策（ACLの絞り込み等）を講じさせることが最善の被害防止策であると判断したと述べています。
• オープンソースと免責条項:
  対象ソフトウェアが BSD-3-Clause ライセンスに基づくオープンソースである点に触れ、第三者監査としての独立性と透明性を担保する意図を示しています。

この脅威の特徴的な部分をみてみましょう。

• Tailscale SSH による root 権限奪取（Findings 1〜3, 5）
  Tailscale SSH は tailscaled プロセス（通常 root 権限で稼働）内で統合動作しています。
  • Unix ソケット転送の権限昇格 (ssh -L / -R)
    一般ユーザ権限の SSH セッションであっても、ソケット転送のパス検査や接続・バインド処理が root 権限のまま実行されます。
    これにより、本来アクセスできない Docker/containerd や systemd などの特権ソケットと直接通信させたり、既存の特権ソケットを置き換えたりすることが可能です。
  • TOCTOU（Time-of-Check to Time-of-Use）競合
    ソケットパスの検証から実際のバインド/ダイヤルまでの間にシンボリックリンク等を差し替えることで、パス許可リストを回避して任意ファイル操作・root 権限奪取に至ります。
  • ワーム化（横展開）の成立条件:
    デフォルト設定（Tailnet Lock 無効、かつ TPM 等のハードウェア保護がない環境）では、root を奪取したノードからノード鍵等を窃取し、攻撃者の端末を正規ノードとして追加可能です。
    これにより、既存の SSH ポリシーで許可されているノード間を自動横展開（ワーム化）できることが検証されています。
• App Connectors のネットワーク境界バイパス（Finding 4 / conn25）
  実験的機能である「App Connectors（conn25）」において、コネクタを経由したトラフィック変換時に送信先アドレスの適切な検証が行われません。
  • コネクタ権限を持つ利用者が、Tailnet 側のネットワーク ACL を迂回し、AWS/GCP 等のクラウドアカウントメタデータ（一時認証情報の窃取）や、Kubernetes クラスタ内部の全サービス宛てに任意のトラフィックを直接到達させることが可能です。
• headscale に対する未認証 DoS 攻撃（Finding 6）
  自前ホスティング用のコントロールプレーン「headscale」に関する問題です。
  • インターネット上に公開されている headscale サーバーに対し、未認証の外部攻撃者がリソースを急激に消費させるリクエストを送り、メモリ枯渇（OOM）やキャッシュ退避を引き起こせます。これによりサーバーがクラッシュループに陥り、組織全体の新規デバイス登録や認証が停止します。
• Tailscale DERP リレーのメモリ枯渇（Class 4）
  クライアントエージェントが通信中継に用いる DERP リレーとの通信処理において、悪意のある中継サーバーからの応答を無制限に読み込んでしまう実装不備が存在します。敵対的リレーに接続させられたエージェントがメモリ枯渇を起こし、サービス停止に至ります。
• tailscale serve / funnel のローカル管理 API 露出（Findings 7〜11）
  ローカルサービスを外部公開する tailscale serve 機能において、TCP 転送から Unix ソケットへの転送パスに検証の抜け道が存在します。
  • オペレータが誤った転送設定を行うと、本来外部から到達してはならないエージェント自身のローカル管理 API（localapi）がリモートから直接書き込み可能な状態で露出します。

Tailworm は、ネットワーク境界を越えた侵入そのものというよりは、「初期侵入を受けた端末が1台でも存在する場合、ゼロトラスト境界とされた Tailnet 全体が侵害・特権奪取される」という内部拡散リスクを実証したレポートです。
ベンダーからの公式パッチが提供されるまでの間、システム運用者には以下の暫定措置が強く推奨されます。

• SSH アクセスルールの最小化（最優先）:
  ACL において autogroup:member や広範なタグを用いた一括許可を廃止し、「特定の接続元端末・ユーザ」と「特定の接続先」を1対1で結ぶ厳格なペア指定に制限する。
• 不要な SSH ポート転送の無効化:
  SaaS 版 Tailscale ではポリシー上で SSH ポート転送（forwarding）を明示的に禁止（false）に設定する（※headscale v0.29.5 では転送を無効化できないため、接続自体の絞り込みが必須）。
• 特権ソケットが存在するホストの洗い出し:
  Docker、Kubernetes ノード、systemd 等の Unix ソケットが稼働している重要サーバにおいて、Tailscale SSH の利用を停止し、必要に応じて権限分離された従来の OpenSSH への切り替えを検討する。
• headscale 運用の見直し:
  コントロールサーバをインターネットへ直接フルオープンにせず、リバースプロキシでのレート制限やメモリ上限監視、アクセス制限を適用する。

実装上の脆弱性なのか、設計上の脆弱性なのか、考えさせられる部分の重い事例となっていると感じます。

Tailworm
https://tailworm.com/