Tailscaleの脆弱性対策｜Tailworm後に見直した4点
「Tailscaleに未修正の脆弱性が11件見つかったらしい」「最初の設定のまま使っているけれど、大丈夫なのか」——2026年10月25日に公開された「Tailworm」という報告がXで広まり、Tailscaleを使っている人の多くがこの不安を抱えています。
結論から言うと、Tailwormの主な経路はTailscale SSH・Serve・App Connector・headscaleの4つで、どれも使っていなければ報告の中心の攻撃は届きません。ただし最初の設定のままだと、アクセス制御は全端末・全ポートを通し、Tailnet Lockもオフです。私たちはこの2つに、使っていないTailscale SSHの許可と、知らないうちに止まっていた自動更新を加えた4点を見直しました。
株式会社Fyveは、事務所のMac miniでAIの定期実行ジョブを無人で回し、外出先からはTailscale経由で入っています。この記事では、2026年10月26日に私たちが実際に行ったTailscaleの脆弱性対策を、画面つきでまとめます。確かめ方、管理画面の操作、結果の順に進めます。
結論：Tailscaleの脆弱性対策は、当たるかを確かめてから最初の設定を固める
私たちが行ったことを、先に表にまとめます。構成は、事務所のMac mini（無人で動く自動化サーバー）、持ち歩くMacBook Air、iPhoneの3台で、ログインしているのは田嶋1人です。
段階 | やること | 私たちの結果 |
|---|---|---|
当たるかの確認 | Tailscale SSH・Serve・App Connector・headscaleを使っているか確かめる | 4つとも使っていなかった |
見直し1：Tailnet Lock | 信頼した端末が署名した端末しか参加できないようにする | オフ → オン |
見直し2：アクセス制御 | 全端末・全ポートの許可をやめ、使う通信だけを通す | Mac miniのSSH（22番）と画面共有（5900番）だけに |
見直し3：Tailscale SSHの許可 | 使っていない許可を消す | 削除 |
見直し4：版の更新 | 自動更新が実際に働いているか確かめる | Mac miniが1.98.8のまま止まっていた → 1.104.2 |
かかった時間は、最初の確認から最後の更新まで約40分でした。確認のコマンドはClaude Codeに実行してもらい、田嶋の手が要ったのは、管理画面へのログイン、Tailnet Lockを有効にするコマンドの実行、Mac miniの更新ボタンを押すところだけです。
Tailwormとは何か（2026年10月25日公開のTailscaleの脆弱性報告）
Tailwormは、Cyberdione LabsのErica Windisch氏が2026年10月25日に公開した、Tailscaleと、Tailscaleの管理サーバーを自前で立てるためのオープンソース「headscale」に関する報告です。2026年10月22日〜24日に、Tailscale v1.104.2とheadscale v0.29.5を試験環境で調べた結果として、11件の問題が挙げられています。
報告の要点は次の4つです。
- 中心はTailscale SSHの転送機能：Tailscale SSHで接続を許された相手が、転送の機能を使って、接続先のroot（管理者）しか触れないはずのものに届く、という問題が複数件あります
- 中心の問題は、攻撃者がすでに1台を握っている前提：Tailscale SSHに関する問題について、報告自身が「承認済みの端末1台と、SSHの許可1つ」を前提にしています。インターネット上の誰もが外から侵入できる、という種類の話ではありません
- Tailnet Lockがオフだと、不正な端末の参加まで実演：Tailnet Lockがオフのtailnet（Tailscaleでつながった自分の端末の集まり）では、不正な端末を参加させるところまで通しで実演されています。オンの場合は、解除のための情報の一部を途中で取れたものの、実際の解除までは行っていないと書かれています
- 修正版はまだない：報告は修正版が出る前に公開されました。2026年10月26日時点で、Tailscale公式のセキュリティ情報（Security Bulletins）にはまだ載っていません。最新の掲載は10月21日の
TS-2026-013です
報告はTailscaleが内容を確かめたものではなく、研究者の側の主張です。一方で、修正版が出るまでの間、使う側が設定で守るしかない状態であることも確かです。
Tailscaleの通信の仕組みと、使う側に残るリスクの全体像は、こちらの記事で整理しています。
Tailwormが自分に当たるかの見分け方
報告の11件は、ほぼすべてが特定の機能を使っている場合の話です。そこで最初に、その機能を自分が使っているかを確かめます。Serveは手元のサービスをtailnetの中に公開する機能、Funnelはインターネットに公開する機能、App Connectorは特定のサイトへの通信をtailnet経由にする機能です。
Claude Codeにこう頼む
私たちは、Claude Codeに次のように頼んで確かめました。コマンドを覚えていなくても、これで十分です。
このMacとMac miniのTailscaleの設定を確認して。Tailscale SSH・Serve・Funnel・App Connectorを使っているか、Tailnet Lockがオンか、版はいくつか、を表にして。設定は変えないで、読むだけにして。
「設定は変えないで、読むだけにして」と添えるのがポイントです。確認の段階で、AIに勝手に設定を変えられないようにします。
実際に使うコマンド
Claude Codeが実行したのは、次のコマンドです。自分で打つ場合も同じです。
tailscale debug prefs：設定の一覧。"RunSSH"がtrueならTailscale SSHを使っています。"AppConnector"の"Advertise"がtrueならApp Connectorですtailscale serve status：ServeやFunnelの設定があるか。「No serve config」なら使っていませんtailscale lock status：Tailnet Lockがオンかtailscale version --upstream：今の版と、公開されている最新の版を並べて表示します
私たちの結果は、MacBook AirとMac miniのどちらも "RunSSH": false、ServeとFunnelは「No serve config」、App Connectorも使っていませんでした。headscaleも立てていません。つまり、報告の中心の経路は私たちには当たりません。
ただ、同じ確認で、気になる点が3つ見つかりました。Tailnet Lockはオフ、アクセス制御は最初の設定のまま、そしてMac miniの版が1.98.8で、最新の1.104.2から遅れていました。管理画面の端末の一覧でも、Mac miniの版の横に赤い印（更新あり）が出ていました。一覧の smith がMac mini、stngm-6-1 がMacBook Airです。
ここからの4点は、Tailwormに当たらなかったから終わり、ではなく、最初の設定のままだった部分を、この機会に固めたという位置づけです。
見直し1：Tailnet Lockをオンにする
Tailnet Lockは、tailnetに新しい端末が参加するとき、自分が信頼した端末の署名を必須にする機能です。Tailscaleの運営会社の側が侵害されたり、ログイン用のキーが盗まれたりしても、署名のない端末は参加できません。Tailwormで「オフなら不正な端末を参加させられた」と実演されたのが、まさにこの部分です。
Tailnet Lockの設定手順
設定は、管理画面で始めて、コマンドで仕上げる流れです。Macのアプリの設定画面は、状態を見るだけの場所です。
- 管理画面の「Settings」→「Device management」→「Enable Tailnet Lock…」を開く
- 「Add signing node」で、署名に使う端末を2台以上選ぶ。私たちはMacBook AirとMac miniの2台にしました
- 解除用の秘密をTailscaleのサポートにも渡すかを選ぶ
- 画面に出た
tailscale lock initのコマンドを、選んだ端末のどれか1台で実行する
コマンドを実行すると、すでにtailnetにいる端末には自動で署名が付きます。私たちの場合も、Mac miniへのSSHや画面共有は一度も切れませんでした。
解除用の秘密は、AIに見せない場所で受け取る
コマンドを実行すると、Tailnet Lockを解除するための秘密の文字列が10個表示されます。解除に要るのは10個のうち1個だけですが、表示はこの1回限りで、なくすとTailnet Lockを解除できなくなります。10個ともパスワード管理ツールに保管します。
ここで1つ気をつけたことがあります。確認のコマンドはClaude Codeに任せましたが、この tailscale lock init だけは、Claude Codeの会話とは別のターミナルで田嶋が自分で実行しました。AIに実行させると、表示された秘密の文字列が会話の記録に残ってしまうからです。AIに任せる作業と、人がやる作業の境目は、「出てくるものが秘密かどうか」で引くと迷いません。
手順3の「サポートに渡すか」は、渡さないほうを選びました。渡しておけば、秘密を全部なくしてもサポートに解除してもらえます。その代わり、Tailscaleの側からも解除できる状態になります。Tailnet Lockは「運営会社の側が侵害されても守る」ための機能なので、渡さないほうが筋が通ると判断しました。
有効にした後は、管理画面に「Tailnet Lock enabled」、署名に使う端末に「Signing node」の印が出ます。Macのアプリの設定画面でも「Tailnet Lock: Enabled」になります。
Tailnet Lockの注意点
- 「新しい端末の承認」とは同時に使えない：管理画面にも「Device approval can't be used while Tailnet Lock is enabled.」と表示されます。承認を使っていた場合は、Tailnet Lockに置き換わります
- 新しい端末を足すたびに署名が要る：署名に使う端末から
tailscale lock signを実行するか、アプリの署名用リンクを使います - 署名に使う端末の鍵はその端末の中にある：署名に使う端末そのものを盗まれると、鍵も取られえます。署名に使う端末は、持ち歩かない機械を含めて2台以上にしておくと安心です
見直し2：アクセス制御（ACL）を絞る
Tailscaleのアクセス制御は、最初の設定では {"src": ["*"], "dst": ["*"], "ip": ["*"]} の1行です。tailnetの中の全端末が、全端末の全ポートにつながる状態です。Tailwormが前提にしている「攻撃者がすでに1台を握っている」状況では、この1行が、ほかの全端末への通り道になります。
私たちが実際にTailscaleで使っている通信は、MacBook AirやiPhoneからMac miniへのSSH（22番）と画面共有（5900番）だけでした。そこで、次のように書き換えました。
書き換えた後の設定です（アドレスとメールアドレスはぼかしています）。中身は3つです。
- hosts：Mac miniとMacBook Airに名前を付ける
- grants：自分の端末からMac miniへは、tcpの22番と5900番だけを通す。それ以外の通信は書かないので通らない
- tests：保存のたびに「Mac miniの22番・5900番は通る」「Mac miniのほかのポートとMacBook Airへは通らない」を自動で確かめる。食い違えば保存そのものが止まる
testsを書いておくと、あとで誰かが（未来の自分やAIが）設定を書き換えたとき、意図と違う変更を保存の時点で止められます。
保存した後に、通る・通らないを確かめる
保存した後は、実際の通信で確かめました。ポイントは、待ち受けているポートで「通らない」を確かめることです。もともと何も待ち受けていないポートで「通らない」を見ても、アクセス制御が効いた証拠になりません。
確かめた通信 | 結果 |
|---|---|
MacBook Air → Mac miniのSSH（22番）・画面共有（5900番） | 通る（実際に |
MacBook Air → Mac miniの88番（待ち受け中） | 通らない |
Mac mini → MacBook Airの3000番・5000番・7000番（待ち受け中） | 通らない |
MacBook Airの3000番は、開発中のWebサイトを手元で動かすときに使う番号です。書き換える前は、tailnetの中のほかの端末から、この開発用のサーバーに届く状態でした。最初の設定のままだと、こうした「自分では外に出しているつもりのないもの」まで、tailnetの中では見えてしまいます。
見直し3：使っていないTailscale SSHの許可を消す
最初の設定のアクセス制御には、"ssh" の項目も入っています。自分の端末どうしなら、Tailscale SSHで一般ユーザーにもrootにも入れる、という許可です。
私たちはTailscale SSHを使っておらず、Mac miniには通常のSSHを鍵で入っています。どの端末でもTailscale SSHは動いていないので、この許可に今すぐの害はありません。ただ、将来だれかがTailscale SSHをオンにした瞬間、Tailwormの中心の経路が開きます。使っていない許可は、使っていないうちに消しておくのが安全なので、見直し2の書き換えで一緒に消しました。
Tailscale SSHを実際に使っている場合は、消すのではなく絞ります。報告では、許可を「この端末からこの端末へ」の組ごとに書き、rootへの接続を許さないことが、修正版までのつなぎの対策として挙げられています。Tailscale SSHの仕組みと設定は、こちらの記事にまとめています。
見直し4：Tailscaleを最新版に更新する（自動更新が止まっていた）
Tailwormの修正版が出たら、それも更新として配られます。そのときに確実に受け取れるよう、今の版を最新にしておきます。
MacBook Airは、Tailscaleを起動したときに自動更新が働き、1.104.2になっていました。問題はMac miniです。自動更新の設定はオンなのに、1.98.8のまま止まっていました。
原因は「このバージョンをスキップ」
Mac miniのTailscaleの設定ファイルを読むと、原因が分かりました。最後に更新を確認したのが2026年7月29日で、その日に1.98.9が「このバージョンをスキップ」に設定されていました。そこから約3か月、新しい版が入っていませんでした。
自動更新が「オン」になっていても、実際に最新になっているとは限りません。確かめるには、管理画面の端末の一覧で版の横に赤い印が出ていないかを見るか、tailscale version --upstream で今の版と最新の版を並べるのが確実です。
Macの配布版は画面で更新する
Tailscaleのサイトから入れたMac版（App Store版ではないもの）では、tailscale update のコマンドは「この環境では使えない」と返ってきます。そこで、画面共有でMac miniの画面を開き、メニューバーのTailscaleのアイコンから「Check for Updates…」を選びました。
実際にやってみると、1.98.8からいきなり1.104.2には上がらず、1.98.10を経由して2回に分けて上がりました。1回目の更新が終わって版が最新でなければ、もう一度「Check for Updates…」を押します。更新のたびにTailscaleが再起動するので、画面共有は数十秒切れます。切れたら、つなぎ直します。
外から入っている遠くのサーバーを更新する場合は、ここに注意が要ります。更新の後にTailscaleが戻ってこないと、そのサーバーのそばに行くまで接続できなくなります。私たちのMac miniは、定期実行のジョブがTailscaleを使っていないため、万一切れてもジョブは止まりません。そのうえで、画面を見ながら更新できる画面共有の最中に行いました。
更新の後も、Tailnet Lockの署名はそのまま残り、SSHと画面共有も問題なく使えました。
見直さなかったこと
報告やXの投稿で挙がっていた対策のうち、私たちがあえて変えなかったものもあります。
- Mac miniの鍵の期限切れ：報告では、サーバーにも鍵の期限切れを設けることが勧められています。ただ、Mac miniは無人のサーバーで、鍵の期限が切れると外から入り直す手段がなくなります。Tailnet Lockで不正な端末の参加は防げるようになったので、期限切れは無効のままにしました
- 使っていないiPhone：8月から接続していないiPhoneが一覧に残っています。今後の使い方しだいなので、今回は残しました
対策は「全部やる」より「自分の構成にどれが必要か」で選ぶほうが続けやすく、あとで理由も説明できます。
Mac miniに外から入る仕組みそのものの作り方は、こちらの記事にまとめています。
Tailscaleの脆弱性対策でよくある質問
Tailwormの修正版はいつ出ますか
2026年10月26日時点で、Tailscaleの公式のセキュリティ情報には載っておらず、修正版の予定も公式には示されていません。公式のセキュリティ情報のページを確認し、修正版が出たら更新してください。それまでは、この記事のように設定で守ります。
Tailnet Lockは無料のプランでも使えますか
公式ドキュメントでは、Tailnet LockはPersonalプランとEnterpriseプランで使えると案内されています（2026年10月26日時点）。契約しているプランで使えるかは、管理画面の「Device management」に「Enable Tailnet Lock…」が出るかで確かめられます。
Tailnet Lockをオンにすると、今つながっている端末は切れますか
公式ドキュメントでは、有効にしたときに、すでにtailnetにいる端末には信頼した端末の署名が付くと説明されています。私たちの場合も、Mac miniへのSSHと画面共有は切れませんでした。新しく端末を足すときから、署名が要るようになります。
解除用の秘密をなくしたらどうなりますか
サポートに渡していなければ、Tailnet Lockは誰にも解除できなくなります。署名に使う端末が手元に残っていれば、新しい端末に署名して足すことはできます。秘密も署名に使う端末も全部失った場合は、tailnetを作り直すことになります。秘密はパスワード管理ツールに保管し、署名に使う端末は2台以上にしておきます。
Tailscale SSHを使っている場合は、止めるべきですか
報告で挙げられているつなぎの対策は、止めることではなく、許可を「この端末からこの端末へ」の組ごとに絞り、rootへの接続を許さないことです。使っていない端末ではオフにし、使っている端末では許可を絞って、修正版が出たらすぐ更新します。
まとめ：Tailscaleの脆弱性対策は、当たるかを確かめてから最初の設定を固める
- Tailworm（2026年10月25日公開）の主な経路は、Tailscale SSH・Serve・App Connector・headscale。使っていなければ中心の攻撃は届かない
- 当たるかは
tailscale debug prefs・tailscale serve status・tailscale lock status・tailscale version --upstreamで確かめられる。Claude Codeに「読むだけ」と添えて頼めば十分 - 当たらなくても、最初の設定のままの部分を固める。私たちが行ったのは次の4点
- Tailnet Lockをオンにする
- アクセス制御をMac miniの22番・5900番だけにする
- 使っていないTailscale SSHの許可を消す
- 止まっていた自動更新を直して1.104.2にする
- Tailnet Lockの解除用の秘密は、AIの会話の外で受け取り、パスワード管理ツールに保管する
Tailscaleは、ルーターのポートを開けずに外から入れる便利な道具です。ただ、最初の設定のまま使っていると、1台が乗っ取られたときの広がり方を自分で決めていないことになります。脆弱性の報告は、その設定を見直す良いきっかけです。
手元のサービスをインターネットに公開するFunnelの仕組みと止め方は、こちらの記事にまとめています。
Claudeのこの5つの設定、今すぐ見直した方がいい
共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ（全28ページ）
2026年7月、Claudeの共有チャットがGoogle検索から読める状態になっていました。原因は設定そのものではなく、自分が過去に共有したものを覚えていないことでした。共有リンクの棚卸しから、学習をオフにしても残る例外条項、Claude Codeの権限モードまで、今日30分で確認できる形にまとめています。
- 見落としやすい共有リストは3つある（3つ目は画面の下）
- 学習をオフにしても残る、公式の例外条項
- 権限モード6つの違いと、Shift+Tabでの切り替え方
- 私が実際に禁止しているコマンド23行を全文公開
メールアドレス登録で他にも様々な資料を閲覧できます
＋9PDF 18点・合計468ページ ＋ すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。