macOS Tahoe 26.6.1：画面共有の脆弱性と取るべき対応
Appleは画面共有の認証バイパスを修正するmacOS Tahoe 26.6.1を公開しました。CVE-2026-65400で実際に何が可能だったのか、そして自分のMacをどう監査するかを解説します。
Appleは2026年8月6日（木）、26.6のリリースからわずか10日後にmacOS Tahoe 26.6.1を公開しました。開発者向けベータはありませんでした。パブリックベータもありませんでした。新機能もなく、Safariのバージョンアップもなく、ファームウェアの変更もありません。リリースノートに書かれているのはセキュリティ修正が1件のみで、セキュリティコンテンツの文書に記載されているCVEもちょうど1件だけです。
この組み合わせこそが、今回の話の本質です。Appleは通常、ポイントアップデートを出荷する前に少なくとも数日間は開発者にシードしますし、x.x.1のリリースであればセキュリティ関連の作業に加えていくつかのバグ修正を伴うのが普通です。ところが今回はシード配布を完全に飛ばし、中身はたった1件、Screen Sharingコンポーネントに存在するCVE-2026-65400だけでした。Appleは同日、同じ修正をmacOS Sequoia 15.7.9とmacOS Sonoma 14.8.9にもバックポートしています。これは、最新リリースだけでなくすべての環境に一斉に修正を行き渡らせたいときにベンダーが取る動きです。
macOS Tahoe 26.6.1のScreen Sharingの脆弱性はきちんと理解しておく価値があります。というのも、この件を正直に語ろうとすると、いちばん知りたい詳細の部分に大きな空白が残るからです。Appleのimpact（影響）欄はたった1文です。該当サービスを有効にしている必要があったのかどうかには触れていません。仕組みの説明もありません。にもかかわらず、いくつかのメディアはその空白を、誰も裏付けていない具体的な記述で埋めています。本ガイドでは、実際に確認できている事実、本当に不明なままの点、現実的にリスクを負っていたのは誰か、そして脆弱性の仕組みがどうであれ重要になる実践的な部分――自分のMacのリモートアクセス面を監査する方法――を扱います。
要点まとめ
- macOS Tahoe 26.6.1はビルド25G76、2026年8月6日リリース。セキュリティ修正1件のみで、それ以外は何もない。 Safariは26.6のまま、システムファームウェアも18000.161.9で変更なし、新機能もありません。Mr. Macintoshによるアップデートパッケージの解析によれば、デルタアップデートのサイズはApple silicon版が約2.1 GB、Intel版が約898.9 MBです。
- CVE-2026-65400はScreen Sharingにおける認証バイパスである。 Appleのimpactの記述は「ネットワーク上の攻撃者が、有効な認証情報なしにScreen Sharingへ認証できる可能性がある」というものです。修正内容はAppleの言葉では「状態管理の改善により認証の問題に対処した」となっています。AppleはBynario Atlasと協働したAlfredo Pesoli（@__rev）氏をクレジットしており、ドイツのメディアheiseはBynario AtlasをAIベースの脆弱性検出システムだと説明しています。
- 影響範囲はローカルネットワークであり、オープンなインターネットではない。 heiseは、Macがローカルネットワーク上にあり、該当ポートがルーターでフォワードされていなければ、インターネット越しのリモート画面共有は不可能だと指摘しています。現実的な脅威モデルは共有Wi-Fi環境です。オフィス、学生寮、コワーキングスペース、ホテル、カフェといった場所が該当します。
- 攻撃の成立にScreen Sharingが有効である必要があるかどうかをAppleは明言しておらず、それこそがアップデートすべき最大の理由である。 heiseは、Screen SharingやApple Remote Desktopが有効でなければならないのか、それとも画面共有が全体として無効でも攻撃が可能なのかは現時点で不明だと明確に述べています。新品のMacではScreen Sharingは初期状態でオフなので、多くの人は「自分は最初から無関係だった」と結論づけたくなるでしょう。しかしその結論を裏付けるものは、Appleが公開した情報のどこにもありません。
- 同じ修正はmacOS Sequoia 15.7.9（ビルド24G830）とmacOS Sonoma 14.8.9（ビルド23J631）にも提供された。 Appleが2つの旧メジャーバージョンへ同日にバックポートしたことは、この件を深刻に扱った妥当なシグナルです。Appleは実際に悪用された事例は把握していないとしています。この件に関しては、対応するパッチさえ適用すれば古いmacOSに留まっていても問題ありません。
macOS Tahoe 26.6.1の実体
Tahoe 26.6は2026年7月27日にビルド25G72として出荷され、Tahoeサイクル全体で最大規模のセキュリティ修正のまとまりでした。優に140件を超える問題が解消されています。macOS Tahoe 26.6の完全解説では、その内容を、AppleがmacOS 27に向けた準備だと説明していたSpotlightの再インデックス処理を含めて取り上げています。
macOS Tahoe 26.6.1はその正反対のリリースです。ビルドは 25G76、日付は 2026年8月6日、そして存在理由はただ1つの穴を塞ぐことです。
パッケージそのものについて確認できている事実は次のとおりです。
- ビルド： 25G76
- リリース日： 2026年8月6日、26.6のおよそ10日後
- ベータシード： なし。開発者ベータもパブリックベータもなし
- 新機能： なし
- Safari： バージョン26.6のまま、更新なし
- システムファームウェア： 18000.161.9で変更なし
- セキュリティコンテンツ： CVE 1件、Screen SharingのCVE-2026-65400
- Appleのセキュリティ文書： support.apple.com/en-us/148170
ダウンロードサイズは、Appleのリリースごとにパッケージの詳細を定期的に公開しているMr. Macintoshによるものです。デルタアップデートは Apple siliconで約2.1 GB、Intelで約898.9 MB です。デルタではなくフルインストーラを取得する場合は、これよりかなり大きくなると考えてください。Intelのデルタがギガバイトを切る一方でApple siliconのデルタが2 GBを超えるのはTahoeでは通常のことで、Apple silicon側は署名付きシステムボリュームのペイロードを含み、その再構築のされ方が異なるためです。
ベータがなかったことの意味
Appleの通常のポイントリリースの流れでは、少なくとも1回の開発者向けシード、たいていはリリース候補、そしてその1〜2日後にパブリックベータが挟まります。このプロセスは、何百万台ものマシンがアップデートを受け取る前にリグレッションを捕まえるために存在します。
これを飛ばすこと自体は前例がないわけではありませんが、意味を読み取れる程度には珍しいことです。Appleがシードもせず機能追加もなしにいきなり正式リリースへ進んだ場合、妥当な読み方は、修正が小規模で内容がよく理解されており、シードのスケジュールが許すよりも早く出したかった、というものです。これは「バグが悪用されていた」という意味ではありません。Appleは実際に悪用された事例は把握していないと明言しています。ただし、Appleが1週間待ちたくなかったことは確かです。
バックポートが2つ目のシグナルです。Appleは最新版の2世代前までのmacOSにセキュリティアップデートを提供していますが、同じ修正を3系統すべてに同日投入するとは限りません。今回それを Sequoia 15.7.9 と Sonoma 14.8.9 に対して行ったということは、サポート対象のどのマシンにも未修正のまま放置すべきでない問題だとAppleが評価したことを示唆しています。
現時点でのバージョンの時系列
自分がどの位置にいるかを確認したい場合、最近のTahoeリリースで押さえておくべきものは次のとおりです。
- 26.5 2026年5月11日、macOS Tahoe 26.5アップデートガイドで解説
- 26.5.1 2026年6月1日
- 26.5.2 2026年6月29日
- 26.6 2026年7月27日、ビルド25G72
- 26.6.1 2026年8月6日、ビルド25G76
自分のMacが何を実行しているかを確認するには、ターミナルを開いて次を実行します。
sw_versこれで製品名、バージョン番号、ビルドが表示されます。バージョンが26.6.1、ビルドが25G76と表示されれば、パッチは適用済みです。Appleメニューから「このMacについて」を開き、バージョン番号をクリックしてビルドを表示させる方法でも確認できます。
CVE-2026-65400で何が可能だったのか、平易な言葉で
Appleのセキュリティ文書が極端に簡潔なのは有名です。今回のものは、説明全体がわずか2文に収まります。
影響：
ネットワーク上の攻撃者が、有効な認証情報なしにScreen Sharingへ認証できる可能性がある。
修正：
状態管理の改善により、認証の問題に対処した。
どちらの文も、丁寧に読む価値があります。
「Screen Sharingへ認証する」とは
MacのScreen Sharingは、グラフィカルセッションのライブ操作権をそのまま引き渡すサービスです。接続した相手はディスプレイに表示されている内容を見ることができ、ポインタを動かし、文字を入力し、アプリケーションを開き、ログイン中のユーザーが読めるものはすべて読めます。ファイル転送のチャンネルでも、閲覧専用のビューでもありません。デスクそのものです。
通常、このサービスに到達するには認証情報が必要です。設定によって、それは接続を許可されたユーザーのアカウントパスワードであったり、レガシーのVNCオプションを有効にしている場合は別途設定したVNCパスワードであったりします。サービスはセッションを許可する前にこれらの認証情報を検証します。
「有効な認証情報なしに認証する」とは、この検証を正しい秘密情報なしに通過させられた可能性があるということです。攻撃者はあなたのパスワードを知るわけではありません。知る必要もありません。サービスが「認証は成功した」と信じ込む状態にたどり着くのです。
そこで攻撃者が得られるのは、その接続が認可された対象と同じ権限レベルです。接続に使われるアカウントが管理者であるMacなら、それは管理者権限を持つセッションであり、実質的にマシンの完全な支配に近いものになります。共有用アカウントが標準ユーザーであるMacなら、そのユーザーのアクセス権にとどまりますが、それでも書類を読み、メールを閲覧し、画面上のあらゆるものを見るには十分です。
「状態管理の改善」とは
Appleは修正内容の記述に限られた語彙しか使わず、それぞれの表現はおおまかにバグの種類と対応しています。「状態管理の改善」は一般に、複数ステップの処理の中で自身の進行状況を誤って追跡していたサービスを指します。この接続は認証済みかどうか、という情報をコードのどこかが保持しており、その情報が誤った値になり得たということです。
公開されている記録から読み取れるのはここまでです。Appleは仕組みを公表しておらず、Apple自身のもの以外にこの脆弱性の内容を説明したベンダーアドバイザリも存在しません。
研究者のクレジットについて
Appleは Bynario Atlas（bynar.io）と協働した Alfredo Pesoli（@__rev） 氏をクレジットしています。heiseはBynario AtlasをAIベースの脆弱性検出システムだと説明しており、これは自動化された発見パイプラインがAppleのCVEクレジットを獲得した、比較的目に見えやすい事例の1つと言えます。研究者名のつづりについてはメディアによってわずかに表記が異なりますが、クレジットそのものに争いはありません。
現実的な脅威モデル：ローカルネットワーク限定
Appleのimpact文にある「ネットワーク上の攻撃者」という表現は非常に重い意味を担っており、どの程度心配すべきかを判断するうえで最も有用な文脈です。
heiseの報道はその境界線を明示しています。Macがローカルネットワーク上にあり、該当ポートがルーターでフォワードされていなければ、インターネット越しのリモート画面共有は不可能です。Screen SharingはTCPポート5900を待ち受け、Apple Remote Desktopはそれに加えて3283を使用します。一般的な家庭用ルーターは誰かが明示的に設定しない限りこれらのポートを転送しませんし、NAT（ネットワークアドレス変換）があるため、公衆インターネット上の攻撃者があなたのMacのプライベートアドレスに直接ダイヤルすることはできません。
つまり攻撃者は、あなたのMacとすでに同じネットワークセグメント上にいる必要があります。
「同じネットワーク上」が実際に意味するもの
これは想像するほど特殊な状況ではありません。自分がコントロールしていない人々とブロードキャストドメインを共有するネットワークには、次のようなものがあります。
- オフィスのWi-Fi。メインネットワークから適切に分離されていないゲストネットワークを含む
- コワーキングスペース。見知らぬ人同士がインフラを共有することがそもそもの前提
- 大学の寮やキャンパスネットワーク。多くの場合フラットで、しかも規模が巨大
- ホテルのWi-Fi。全客室が単一のサブネットになっていることが多い
- カフェや空港のWi-Fi
- カンファレンスやイベントのネットワーク
- インターネット回線を共有している集合住宅
リスクがはるかに低いネットワークは次のとおりです。
- 既知の少数のデバイスだけが接続された家庭内ネットワーク。ただしWi-Fiパスワードが広く共有されておらず、信頼できないデバイスが接続されていないこと
- 自分が管理するスマートフォンへのセルラーテザリングのみで接続しているマシン
もう1つ挙げておくべき厄介な点があります。「ネットワーク上の攻撃者」とは、必ずしも建物の中にノートPCを持って座っている人間を指すわけではありません。そのネットワーク上にすでにある侵害されたデバイスでも同じことができます。感染したWindowsマシン、ろくに管理されていないIoTデバイス、既知の欠陥を抱えたルーターなどが該当します。ローカルネットワークという範囲の限定はリスクを大幅に狭めますが、ゼロにはしません。
深刻なバグではあるがパニックになる話ではない理由
ここでの温度感は、3つの事実の組み合わせで決まります。第1に、Appleは実際に悪用された事例を把握していないとしています。第2に、攻撃にはネットワーク上での隣接が必要なので、インターネット全体を対象にした大規模スキャンというシナリオは成立しません。第3に、Appleは仕組みを公表していないため、攻撃を試みる者は解説記事を読むのではなく自力で発見する必要があります。
一方で、この修正はベータシードを飛ばすほど急を要し、2度もバックポートされるほど重要でした。正しい対応は、今週中にアップデートを適用し、ついでに共有設定を監査することです。Macをインターネットから切り離すことではありません。
実際に意味のあるリスクを負っていたのは誰か
すべてのMacが同じだけの危険にさらされていたわけではありません。一律の警告を出すよりも、具体的に見ていく価値があります。
リスクが高いケース
サーバーとして常時稼働しているMac miniやMac Studio。 キーボードやモニターを接続していないことが多いため、Screen Sharingを常時オンにしている可能性が最も高いマシンです。電源は入りっぱなし、ネットワークにも接続しっぱなしで、誰も画面を見ていません。押し入れの中でメディアサーバーやビルドエージェント、ホームオートメーションのハブとして動いているMac miniは、まさにこの類型に当てはまります。
共有オフィスやコワーキングスペースにあるMac。 信頼できないネットワークと、IT部門の都合でScreen Sharingが有効になっているかもしれないマシンという組み合わせは、今回における最悪のケースです。
IT管理下の端末群。 Apple Remote Desktopや、リモートでの画面監視を有効にするMDMを運用している組織では、ポリシーによって多数のマシンで一斉にScreen Sharingの仕組みが有効になっています。端末群を管理している立場なら、このアップデートは優先的に展開すべきものであり、以下の監査手順は1台ずつではなく規模を前提に適用してください。
一度Screen Sharingを有効にして、そのまま忘れている人。 これは人が認めるよりずっとよくあることです。家族を手伝うために、あるいはノートPCからデスクトップに接続するためにオンにして、それ以来ずっと入りっぱなしになっているというケースです。
ルーターでポート5900をフォワードしているMac。 誰かが意図的にScreen Sharingをインターネットへ公開しているなら、ローカルネットワーク限定という制約は守りになりません。この構成はこのCVE以前から悪手でしたが、今はさらに悪手です。
リスクが低いケース
デフォルト設定のまま家庭内ネットワークで使っているノートPC。 新品のMacではScreen Sharingは初期状態でオフです。一度も有効にしておらず、家庭内ネットワークが小規模で構成も把握できているなら、危険度は低かったと言えます。
大半の時間をスリープまたは電源オフで過ごしているMac。 動いていないサービスには到達できません。
適切にセグメント分けされたゲストネットワークの背後にあるマシン。 ゲストSSIDのクライアント分離機能は、そのネットワーク上のデバイス同士が互いに到達することを防ぎ、攻撃に必要な隣接性を取り除きます。
以上すべてに但し書きが付く理由は、次のセクションにあります。
Appleが語らなかったこと
ここは多くの報道が省略している部分であり、そしてこのアップデートをどう捉えるべきかを決定づける部分でもあります。
有効／無効の問いには答えが出ていない
Appleのアドバイザリは、CVE-2026-65400を悪用するためにScreen Sharingが有効である必要があるかどうかに触れていません。heiseはこの空白を率直に述べています。アクセスにScreen SharingやApple Remote Desktopが有効である必要があるのか、それとも画面共有が全体として無効でも攻撃が起こり得るのかは、現時点で不明だというのです。
これは個人のリスク評価にとって決定的に重要です。なぜならScreen Sharingは初期状態でオフだからです。もしサービスが動作している必要があるなら、影響を受ける母集団は小さく、しかも自ら選んだ人たちに限られます。もし共有機能のスタックのどこかがトグルオフでも待ち受けや応答をしているなら、影響を受ける母集団はサポート対象バージョンのすべてのMacということになります。
どちらの方向にも一応の根拠があります。macOSでは、システム設定でオフになっているサービスは実際にリスニングソケットを開いていません。これは狭い解釈を支持します。他方でmacOSはいくつかのシステムサービスにlaunchdのソケットアクティベーションを使っており、launchデーモンが休止状態でもシステム側がソケットを保持し、必要に応じて起動する構造になり得ます。これは広い解釈を支持します。Appleが2度バックポートし、ベータシードを飛ばしたという判断は、少なくとも弱い意味で広い解釈と整合しますが、証拠にはなりません。
正直な答えは、Apple以外の誰にもわからない、というものです。そうでないふりをするつもりはありません。
その不確実性の下でどう考えるべきか： 不明な部分は、自分が危険にさらされていたかどうかを推理するための材料ではなく、アップデートすべき理由として扱ってください。26.6.1を入れるコストは再起動1回です。トグルがオフだったから守られていたはずだ、という推測を外したときのコストは、見知らぬ他人があなたの画面を見ている状態です。この非対称性だけで、欠けている詳細を待たずに結論は出ます。
仕組みは未公開であり、公表されている一部の詳細は裏付けがない
このバグについて、どのデーモンに問題があったのか、何が不正な状態を引き起こしたのか、攻撃者がどれほど速く特権シェルに到達できるのかといった、より詳細な技術的主張が出回っています。それらの主張はごく少数の二次的メディアにのみ現れ、情報源も単一で、Appleにもheiseにも、そうした詳細を一切含まない9to5Macの報道にも裏付けられていません。慎重に扱い、それらを前提に対応方針を組み立てないでください。
これは架空の懸念ではありません。過度に具体的な脆弱性の解説は人の行動を変えます。「このバグは特定の設定のマシンにしか効かない」と読めば、アップデートを見送るかもしれません。そしてその記述が創作だったとしたら、あなたは何の理由もなくアップデートを見送ったことになります。
具体的にどうすればよいか
- 使っているmacOSに応じて、26.6.1、15.7.9、14.8.9のいずれかをインストールする
- 「Screen Sharingはオフだったから大丈夫だった」を先延ばしの理由にしない
- いずれにせよ共有設定を監査する。監査はそれ自体に価値がある
- 信頼できる技術的な解説が出るまで、悪用の仕組みに関する主張は無視する
Macのリモートアクセス面を監査する方法
ここが本記事の実践的な中核であり、この特定のCVEでリスクがあったかどうかに関係なく役に立つ部分です。ほとんどの人は、自分のMacがネットワークに対して何をさらしているのかを実際に見たことがありません。
システム設定 を開き、一般、共有 と進みます。個別のトグルが付いたサービスの一覧が表示されます。そのうち3つがマシンへのリモートアクセスを司っており、この3つは絶えず混同されています。
Screen Sharing（画面共有）
CVE-2026-65400が影響するのがこのサービスです。オンになっていると、他のマシンがTCPポート5900のVNC経由で接続し、あなたのグラフィカルセッションを操作できます。
確認方法： 共有パネルでScreen Sharingの行を見ます。トグルがオフなら、このサービスは有効ではありません。オンなら、隣の小さなインフォメーションボタンをクリックしてアクセス許可リストを確認します。
アクセス許可リストの意味： デフォルトの選択肢は「すべてのユーザ」か、特定のリストのどちらかです。ここでの「すべてのユーザ」は、あなたが作って忘れているアカウントも含め、そのMac上のすべてのユーザーアカウントを意味します。名前を指定したリストに制限するほうが確実に優れています。インフォメーションボタンをクリックし、指定したユーザーのみにアクセスを許可するオプションを選んで、必要なアカウントだけを追加してください。
そのパネル内の「コンピュータ設定」 には、さらに2つのオプションがあります。1つは、誰でも画面操作の許可を求められるようにするもので、ログイン中のユーザーに確認が表示されます。もう1つはVNCパスワードを有効にするもので、Apple製以外のクライアントがアカウントの認証情報ではなく共有パスワードで接続できるようになります。VNCパスワードのほうが2つの認証経路のうち弱いほうで、プロトコルの仕様上8文字が上限です。サードパーティ製クライアントのために特別に必要でなければ、オフのままにしておいてください。
必要ないならオフにしてください。 これは、このパネルでほとんどの人ができる最も効果の高い変更です。
リモートログイン（SSH）
これはTCPポート22で動く完全に別のサービスです。提供するのはコマンドラインアクセスであり、グラフィカルなアクセスではありません。CVE-2026-65400の影響は受けず、Screen Sharingをオフにしてもこちらには何の影響もありません。
どちらも「リモートアクセス」であり、片方をオフにすれば扉が閉じたように感じられるため、この2つはよく混同されます。しかし実際には閉じていません。
ターミナルからの確認方法：
sudo systemsetup -getremoteloginこれでリモートログインがオンかオフかがわかります。オフにするには次のようにします。
sudo systemsetup -setremotelogin off共有パネルでリモートログインのスイッチを切っても同じことができます。Screen Sharingと同様、インフォメーションボタンからすべてのユーザーではなく特定のユーザーにアクセスを制限でき、そうすべきです。
SSHを日常的に使っているなら、意味のある強化策はパスワード認証を完全に無効化して鍵認証を使うことです。これによって、SSHに対する推測攻撃という種類の攻撃がまるごとなくなります。
リモートマネージメント（Apple Remote Desktop）
これが3つ目のスイッチで、最も混乱を招くものです。
リモートマネージメントはApple Remote Desktopのエージェントです。画面の監視と操作に加えて、ソフトウェアの配布、レポート、リモートでのコマンド実行を提供します。IT部門が端末群を管理するために使うものです。5900に加えてポート3283を使用します。
決定的に重要な点：macOSのインターフェイス上では、Screen Sharingとリモートマネージメントは排他的です。 両方を同時にオンにすることはできません。リモートマネージメントをオンにするとScreen Sharingは自動的にオフになり、macOSはその旨を通知します。ここで見落とされがちなのはその帰結です。共有設定を開いてScreen Sharingがオフになっているのを見て、誰も自分の画面を見られないと結論づけたなら、それは誤りかもしれません。代わりにリモートマネージメントがオンになっていて、別のサービス経由で同じ機能が提供されている可能性があるからです。
ですから毎回、両方の行を確認してください。 Screen Sharingがオフでリモートマネージメントがオンという状態は、堅牢な構成ではありません。取っ手が違うだけの同じ扉です。
リモートマネージメントにも、インフォメーションボタンの奥に細かな権限リストがあり、リモートユーザーが監視、操作、ファイルのコピー、項目の削除、マシンの再起動などを行ってよいかどうかを設定できます。勤務先がそのMacを管理しているためにリモートマネージメントがオンになっているなら、単純にオフにしてはいけません。まず端末群を管理している担当者に相談してください。オフにすると管理の仕組みが壊れる可能性があり、組織のポリシー違反になるおそれもあります。
MacがMDMに登録されているかを確認する
自分のMacを組織が管理しているかどうかがはっきりしない場合、それを教えてくれるのが次のコマンドです。
sudo profiles status -type enrollmentAppleの自動デバイス登録を通じて登録されているか、および現在アクティブなMDM登録があるかどうかが報告されます。小売店で購入して自分でセットアップした個人所有のMacなら、登録されていないと表示されます。勤務先や学校から支給されたマシンなら、通常はアクティブな登録が報告されます。
これが重要な理由は2つあります。第1に、管理下のMacではリモートアクセス設定がプロファイルによって強制されている可能性があり、変更しても元に戻ってしまうことがあります。第2に、管理下にある場合、アップデート自体もあなたではなく組織のソフトウェアアップデートポリシーによって制御されている可能性があり、26.6.1の入手方法が変わってきます。
インストール済みの構成プロファイルを一覧表示することもできます。
sudo profiles listこれでインストールされているものが表示されます。個人所有だと思っているマシンに見覚えのないプロファイルがあれば、調べる価値があります。
ファイアウォールを確認する
macOSにはアプリケーションファイアウォールが搭載されていますが、すべての構成で初期状態から有効になっているわけではありません。今回のCVEと関係なく、オンにしておく価値があります。
インターフェイスから： システム設定、ネットワーク、ファイアウォールと進んでオンにします。オプションボタンの奥では、どのサービスやアプリケーションが着信接続を受け付けてよいかを制御でき、ステルスモードも有効にできます。ステルスモードは、許可されていない相手からのpingやポートスキャンといった探索に対してMacが応答しないようにするものです。
ターミナルから：
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstateこれでファイアウォールがオンかどうかがわかります。
重要な制限が1つあります。macOSのアプリケーションファイアウォールは、共有設定で明示的に有効にしたサービスをブロックしません。Screen Sharingがオンなら、macOSはそこへの着信接続を意図されたものとして扱い、通過させます。ファイアウォールは有用な層ではありますが、使っていないサービスをオフにすることの代わりにはなりません。共有設定で有効になっているサービスをブロックする必要があるなら、それはアプリケーションファイアウォールではなく、ルーターかパケットフィルタのルールでやるべきことです。
実際に何が待ち受けているかを確認する
トグルを信じるのではなく確かめたい場合、画面共有ポートにバインドされているプロセスを表示するのがこのコマンドです。
sudo lsof -i :5900何も出力されなければ、そのポートで待ち受けているものはありません。SSHなら22、Apple Remote Desktopのポートなら3283に置き換えられます。
この種の監査は、個別のCVEとは無関係によい習慣です。Macのセキュリティとプライバシーガイドでは、FileVault、Gatekeeper、プライバシー権限、そして各種の共有サービスが実際に何を公開しているのかを含め、定期的に見直す価値のある設定をより幅広く扱っています。
どうしてもリモートアクセスが必要な場合の堅牢化
Macにリモートで接続する現実的な理由がある人はたくさんいます。自宅のサーバー、オフィスにあるマシン、サポートしている家族のコンピュータなど。そうした人にとって機能をオフにするという選択肢はありません。機能を残したまま露出を小さくする方法を説明します。
公開ネットワークではなくプライベートネットワーク経由でMacに到達する
最も効果の大きい単一の変更は、自分が管理していないネットワークへサービスをさらすのをやめ、代わりにMacとクライアントを同じプライベートオーバーレイ上に置くことです。
自宅やオフィスのネットワークへのVPNでも構いません。Tailscale、WireGuard、ZeroTierといったオーバーレイネットワークも同様に機能します。これらはデバイス間に暗号化されたメッシュを作り、各デバイスに一般のインターネットからは到達できない安定したプライベートアドレスを与えます。これを導入すれば、Screen Sharingは自分のデバイスだけが到達できるインターフェイス上でのみ待ち受けることになります。カフェのWi-Fiにいる攻撃者は、もはや意味のある形でこのサービスに隣接していません。あなたと共有しているローカルインターフェイス上にサービスが公開されていないからです。
このアプローチは、CVE-2026-65400のローカルネットワークという範囲を実務上ほぼ無力化できたはずのものであり、次に出てくる脆弱性に対しても同じ効果を持ちます。設定中に接続の問題にぶつかったら、macOS向けVPNトラブルシューティングガイドで構成プロファイル、DNS、スプリットトンネリングにまつわるよくある失敗パターンを扱っています。
5900は絶対にポートフォワードしない
ルーターからMacへポート5900を転送すると、画面共有サービスが公衆インターネット上に直接置かれ、自動スキャナーは数時間以内にそれを見つけます。ポート5900のVNCは、インターネット上で最も激しくスキャンされているポートの1つです。やめてください。すでにやっているなら、今すぐ元に戻してください。
同じことがApple Remote Desktopの3283、SSHの22にも当てはまります。どうしてもSSHを公開する必要があるなら、デフォルトポートから変更し、パスワード認証を無効にし、鍵認証を使ってください。それでも、より良い答えはやはりVPNです。
明示的な許可リストを持つ専用アカウントを使う
日常使いの管理者アカウントをリモートアクセス用のアカウントにしてはいけません。専用のアカウントを作り、必要な権限だけを与え、Screen Sharingの許可ユーザーリストにはそのアカウントだけを追加します。リモート経路が侵害されても、被害範囲は管理者セッションではなくそのアカウントに留まります。
そのアカウントには本当に強いパスワードを設定してください。リモートアクセスのインシデントが深刻な事態に発展する原因の多くは、パスワードの使い回しです。
許可ユーザーのリストは明示的に保ち、定期的に見直す
「すべてのユーザ」は便利ですが誤りです。古いアカウント、ゲスト的なアカウント、何年も前に別の用途で作ったサービスアカウントも含め、Mac上のすべてのアカウントが暗黙のうちに認可されてしまいます。リストは明示的に設定し、人が去ったときやアカウントを廃止したときには見直してください。
使っていないときはサービスをオフにする
Screen Sharingがたまにしか必要ないなら、使うときだけオンにして、終わったらオフにしてください。月に20分だけ動いているサービスと、3年間動きっぱなしのサービスとでは、露出のプロファイルがまったく異なります。
macOS Tahoe 26.6.1のインストール方法
このアップデートは、他のポイントリリースと同じくソフトウェアアップデート経由で配信されます。
- まずバックアップを取ります。Time Machineでもクローンでも構いませんが、必ず何かを用意してください。小さなアップデートでリスクも低いですが、このルールは変わりません。
- システム設定、一般、ソフトウェアアップデート の順に開きます。
- 確認が終わるのを待ちます。macOS Tahoe 26.6.1が利用可能なアップデートとして表示されるはずです。
- 「今すぐアップデート」をクリックし、パスワードを入力します。
- Macを再起動させます。Apple siliconなら、マシンとディスクにもよりますが、通常は最初から最後まで10〜20分程度です。
- 起動したら、ターミナルで
sw_versを実行するか「このMacについて」で確認します。バージョン26.6.1、ビルド25G76になっていればOKです。
ターミナルからなら、インターフェイスを使わずに一覧表示とインストールができます。
softwareupdate --listこれで利用可能なものが表示されます。該当するものをすべてインストールするには次のようにします。
sudo softwareupdate -i -a完了時に自動で再起動させたい場合は --restart を追加してください。
アップデートがまだ表示されない場合
Appleはポイントリリースの配信を段階的に行います。8月6日には、一部のM4およびM5 Macでは26.6.1がまだ表示されない一方で、他のマシンではすでに利用可能になっているという報告がありました。これらのケースは何もしなくても自然に解消しています。
ソフトウェアアップデートに何も表示されない場合は、次を試してください。
- 数時間待ってからもう一度確認する。段階的な配信は、全員に行き渡るまで丸1日かかることがよくあります。
- システム設定を完全に終了してから開き直し、再確認する。ソフトウェアアップデートのペインは状態をキャッシュしており、ひと押し必要なことがあります。
- ターミナルから
softwareupdate --listを実行する。Appleのサーバーに直接問い合わせるため、インターフェイスにまだ出ていないアップデートが表示されることがあります。 - 組織が管理しているMacの場合、ポリシーによってアップデートが延期されている可能性があります。
sudo profiles status -type enrollmentでその可能性を確認でき、該当する場合はタイミングをIT担当者が制御しています。 - 最後の手段として、Appleは単体のインストーラパッケージを公開しており、Mr. Macintoshが各リリースの直接リンクを定期的にまとめています。フルインストーラをダウンロードすれば段階的配信を回避できますが、ダウンロードサイズははるかに大きくなります。
インストールに失敗する場合
ポイントリリースはたいてい何事もなくインストールされますが、よくある失敗パターンは今回も当てはまります。空き容量の不足、ダウンロードの中断、準備の途中でのハングなどです。インストールが止まる／失敗するmacOSアップデートのガイドでは、正しい空き容量の確保方法、途中まで進んだダウンロードの削除、停止したインストールからの復旧を順に解説しています。
要点はこうです。ダウンロードサイズより明確に多い空き容量が必要になります。macOSはアップデートを展開・準備するための領域を必要とするからです。2.1 GBのデルタなら、20 GBの空きは過剰ではなく、ちょうど余裕のあるマージンです。
SonomaまたはSequoiaを使っている場合
Appleは2026年8月6日、サポート対象の古い2つのmacOSバージョンにも同じ修正を提供しました。
| macOSバージョン | 修正済みリリース | ビルド |
|---|---|---|
| macOS Tahoe 26 | 26.6.1 | 25G76 |
| macOS Sequoia 15 | 15.7.9 | 24G830 |
| macOS Sonoma 14 | 14.8.9 | 23J631 |
手順は同じです。システム設定、一般、ソフトウェアアップデート、インストール、再起動。
古いmacOSに留まることについて、言っておくべきことが2つあります。第1に、この個別の問題については、対応するパッチさえ適用すればSequoiaやSonomaのままでも問題ありません。劣った修正を受け取っているわけではなく、Appleは3系統すべてで同じCVEに対処しています。
第2に、それが当てはまるのはAppleがあなたのバージョンにセキュリティアップデートを提供し続けている間だけであり、その範囲はおおむね現行リリースとその2つ前までです。Sonoma 14はその枠のいちばん端にいます。理由があってSonomaを使っているなら、その理由は定期的に見直す価値があります。いずれ、新しいバージョンでしか修正されないCVEが出てくるからです。
古いバージョンには、目玉となるCVEが共通していても、現行リリースより狭い範囲の修正しか届かないこともあります。26.6.1は修正がちょうど1件なので今回は当てはまりませんが、「古いmacOSを使っているがアップデートは全部入れている」という立場が長期的に見て思ったより弱い理由はここにあります。
Intelという観点
Intel Macも他と同様に26.6.1を受け取り、こちらはより小さい898.9 MBのデルタになります。これを別立てで取り上げる理由は、それが何を象徴しているかにあります。
macOS 27はApple silicon専用です。Intel Macでは動かせないため、macOS Tahoe 26はそれらのマシンが受け取る最後のメジャーリリースということになります。Appleは、あるバージョンが現行でなくなってからおおむね3年間はセキュリティアップデートを提供するのが通例なので、Intel Macの所有者は今回とまったく同じ形のアップデート、つまりビルド番号が上がり、CVEが1件か数件、機能追加なし、というものを受け取り続けることになります。
その意味で26.6.1は、Intelハードウェアにとってのこれからの数年を先取りして見せるものです。アップデートはより退屈で、より重要になっていきます。評価すべき新機能は存在しないので、毎回の問いは入れるかどうかだけになり、その答えは常にイエスです。Intel Mac時代の終わりに関する解説では、完全な対応機種リストと、サポート期間が現実的にどうなるかを扱っています。
Intel Macを常時稼働のマシンとして使っているなら、上の監査セクションはとりわけ注意して読む価値があります。古いMac miniこそ、Screen Sharingを有効にしたまま押し入れに置き忘れられている可能性が最も高いマシンだからです。
サードパーティ製VNCに関する観察
このセクションは推測であり、その旨を明示しておきます。確立された事実だからではなく、特定の読者層にとって有用かもしれないから収録しています。
7月下旬にmacOS Tahoe 26.6が出荷された後、サードパーティ製のVNCクライアントからMacに接続できなくなったという報告が一部のユーザーから上がりました。報告にはRealVNCをはじめ、Windows、iOS、Linux上で動く各種クライアントが含まれ、RealVNCでは鍵長が大きすぎるというプロトコルエラーのようなメッセージが表示されたとされています。同じ報告の中で、Mac同士のScreen Sharingは正常に動作し続けていました。この点こそが、単なる一般的な不具合ではなく興味深いパターンだと感じさせる部分です。
一次情報であるフォーラムのスレッドを直接読むことはできなかったため、以下は二次的な説明に基づくものとして扱ってください。この挙動を認めるApple側の声明は把握していません。
仮説（あくまで仮説として）：26.6が画面共有の認証経路に何らかの変更を加え、その結果サードパーティ製VNCクライアントとの互換性が壊れた可能性があり、CVE-2026-65400も同じコードの中にあった可能性があります。認証処理を厳格化する変更があり、その10日後に同じコンポーネントの認証状態のバグが修正された、という流れは示唆的です。ただしAppleは両者を結びつける情報を一切公開しておらず、heiseは仕組みが不明なままだとしており、示唆的な流れは証拠ではありません。
実務上の意味は次のとおりです。
- 26.6の後でサードパーティ製VNCクライアントが動かなくなったなら、それは他の人からも報告されている既知のパターンです。あなただけではありませんし、おそらく設定ミスでもありません。
- 動かなくなったとしても、26.6.1が直すとは考えないでください。 このアップデートが対処しているのはセキュリティ上の問題です。サードパーティ製クライアントとの互換性を回復させることを示す情報はなく、回復しない可能性もあります。
- サードパーティ製VNCクライアントに頼ってMacに接続しているなら、物理的に触れにくいマシンをアップデートする前に、クライアントのベンダーにmacOS 26.6および26.6.1との互換性を確認してください。
- 以上のどれも、アップデートを見送る理由にはなりません。 サードパーティ製VNCクライアントが動くことと、認証バイパスが修正されていることのどちらかを選ぶなら、パッチを取り、別の接続手段を探してください。
よくあるトラブルと対処法
macOS Tahoe 26.6.1がソフトウェアアップデートに表示されない
症状： 8月6日にリリースされたはずなのに、ソフトウェアアップデートは26.6で最新だと表示し、26.6.1がどこにも見当たらない。リリース当日、M4およびM5 Macでこの報告が複数ありました。
対処： これはほぼ確実に不具合ではなく段階的配信によるものです。Appleは数時間から数日かけて、マシンの一部ずつにポイントアップデートを配信します。ソフトウェアアップデートのペインは結果をキャッシュするので、システム設定を完全に終了してから開き直してください。次にターミナルで softwareupdate --list を実行します。これはAppleのサーバーに直接問い合わせるため、インターフェイスがまだ表示していないアップデートが返ってくることがあります。管理下のMacなら sudo profiles status -type enrollment を実行し、MDMがポリシーでアップデートを延期していないか確認してください。その場合はスケジュールをIT担当者が制御しています。8月6日に報告されたケースは1日以内に自然解消しています。どうしてもすぐに必要で待てない場合は、単体のフルインストーラを使えば段階的配信を回避できますが、ダウンロードははるかに大きくなります。
ダウンロードは終わるのにインストールが完了しない
症状： ダウンロードが完了する（あるいは完了したように見える）が、その後Macが「準備中」や進まない進捗バーの状態で長時間止まり、目に見える進展がない。
対処： まずは、感覚的に十分だと思うより長く待ってください。ディスクがほぼ埋まった忙しいマシンでは、準備フェーズが本当に15分以上かかることがあります。本当に止まっているなら空き容量を確認してください。macOSはインストーラを展開・準備するために、ダウンロードサイズよりかなり多くの余裕を必要とします。Macを再起動してやり直せば、途中まで進んだ、あるいは壊れたダウンロードがクリアされます。2度目も失敗する場合は、キャッシュされたアップデートを削除して新規にダウンロードさせてください。止まる／失敗するmacOSアップデートのガイドでは、アップデートキャッシュを安全に削除する方法や、Macがインストール失敗のループで再起動を繰り返す場合の対処を含め、一連の手順を解説しています。
アップデート後にScreen Sharingが動かなくなった
症状： 26.6.1をインストールしたら、画面共有でMacへ／Macから接続できなくなった。
対処： まず、実際に何が有効になっているかを確認するところから始めます。システム設定、一般、共有を開き、Screen Sharingの行とリモートマネージメントの行の両方を確認してください。この2つは排他的であり、アップデートやポリシーの変更によって記憶と異なる状態になっていることがあります。接続元のアカウントが許可ユーザーのリストに入っているかを確認し、「すべてのユーザ」に頼らないでください。この設定が変更されている可能性があります。他のMacからScreen SharingやFinderで接続している場合は、まずローカルネットワークで試して、問題がサービス側なのか経路側なのかを切り分けてください。サードパーティ製VNCクライアントから接続している場合は前のセクションを参照してください。26.6以降、サードパーティ製クライアントの不具合を報告するユーザーがおり、この挙動は未確認ながら報告はされています。最後に、対象のMacで sudo lsof -i :5900 を実行し、実際に何かが待ち受けているかを確認してください。
リモートマネージメントがオフにできない
症状： 共有パネルでリモートマネージメントをオフにしても勝手にオンに戻る、あるいはトグルがグレーアウトして変更できない。
対処： これは管理下のMacに特有の症状です。MDMから配布された構成プロファイルはリモートマネージメントを強制でき、ローカルで変更しても再適用されます。sudo profiles status -type enrollment でアクティブなMDM登録があるかを確認し、sudo profiles list でどのプロファイルがインストールされているかを確認してください。そのMacが勤務先や学校のものなら、回避しようとしてはいけません。管理を解除するとポリシー違反になるおそれがあり、どのみち数分で元に戻される可能性が高いので、端末群を管理している担当者に連絡してください。そのMacが本当に個人所有で、自分が承認していない登録が見つかった場合は、深刻な事態としてエスカレーションする価値があります。個人所有マシンで最も安全な解決策は、データをバックアップしたうえでのクリーンインストールです。
Macが侵害されたかどうかわからない
症状： 共有ネットワーク上でScreen Sharingを有効にしたまま常時稼働のMacを運用しており、実際にこのバグを使われたかどうかを知りたい。
対処： 正直に言うと、消費者レベルでこれを確実に判定する方法はありません。AppleはCVE-2026-65400の侵害指標（IoC）を公開しておらず、仕組みも未公開で、Screen Sharingに認証した攻撃者が残すログの動きは正規のセッションとおおむね見分けがつきません。ここでは、証拠がないことは本当に「なかったことの証拠」にはなりません。
限界を承知したうえで、それでも確認できることはあります。コンソールを開き、気になる期間のシステムログを画面共有関連のアクティビティで絞り込んで見てみてください。ただしmacOSのログ保持期間には限りがあり、古いエントリは単に消えている可能性があります。システム設定の「ユーザとグループ」で見覚えのないアカウントがないか確認してください。共有パネルの許可ユーザーリストに、自分が追加していないエントリがないか確認してください。ログイン項目とバックグラウンド項目に見慣れないものがないか見てください。sudo profiles list を実行し、自分がインストールしていない構成プロファイルがないか確認してください。ルーターの接続デバイス一覧と、記録が残っていればそのログも確認してください。
特定のマシンに誰かがアクセスしたと考える具体的な根拠があり、そのマシンに機微な情報が入っているなら、本当に信頼できる唯一の対処は、macOSをクリーンインストールしたうえで、システム全体のバックアップからではなくデータだけを復元し、そのマシンでサインインしていたアカウントのパスワードを変更することです。これは重い対応であり、ほとんどの人にとっては正当化されません。Appleはこの問題が悪用された事例を把握していないとしています。
FAQ
Screen Sharingをオフにしていた場合でも、macOS Tahoe 26.6.1を入れる必要がありますか？
はい。AppleはCVE-2026-65400の悪用にScreen Sharingが有効である必要があるかどうかを一度も述べておらず、heiseもこの点は不明なままだと報じています。条件が不明で、アップデートのコストが再起動1回である以上、入れてください。トグルがオフだったことを安全だった証拠として扱わないでください。
CVE-2026-65400を簡単に言うと何ですか？
macOSのScreen Sharingサービスにおける認証バイパスです。Appleの表現では、ネットワーク上の攻撃者が有効な認証情報なしにScreen Sharingへ認証できる可能性がある、というものです。実務的には、同じネットワーク上の誰かがパスワードを知らないまま画面共有セッションを取得し得る、ということを意味します。Appleは状態管理の改善によってこれを修正しました。
この脆弱性は実際に悪用されましたか？
Appleは実際に悪用された事例を把握していないとしています。これは、実環境での攻撃の証拠がないときにAppleが用いる標準的な表現であり、Appleは把握している場合には悪用が確認された問題を明示的に注記します。今回そのフラグがないことには意味がありますが、誰も使わなかったことの保証ではありません。
これを使ってインターネット越しに私のMacを攻撃できますか？
通常の条件下ではできません。heiseは、Macがローカルネットワーク上にあり、該当ポートがルーターでフォワードされていなければ、インターネット越しのリモート画面共有は不可能だと指摘しています。現実的なシナリオは、攻撃者がすでに同じネットワークセグメントにいる場合です。共有オフィスのWi-Fi、学生寮、ホテル、カフェ、あるいは自分のネットワーク上の侵害されたデバイスなどが該当します。
26.6.1で新機能の追加やSafariの変更はありますか？
ありません。新機能はなく、Safariもバージョン26.6のままでこのアップデートでは更新されません。システムファームウェアも18000.161.9で変更ありません。macOS Tahoe 26.6.1はビルド25G76で、含まれるのはセキュリティ修正1件のみです。ベータシードもなく、リリースノートが1行だけなのはそのためです。
macOS SonomaやSequoiaを使っている場合はどうすればよいですか？
Appleは同じ修正をバックポートしています。macOS Sequoia 15.7.9（ビルド24G830）またはmacOS Sonoma 14.8.9（ビルド23J631）を適用してください。劣った修正ではなく、同じ保護が得られます。この問題に限って言えば、対応するパッチを速やかに適用する限り、古いmacOSに留まっていても問題ありません。
まとめ
macOS Tahoe 26.6.1は修正1件を運ぶ小さなアップデートですが、Appleがそれをどう出荷したかは、リリースノート以上のことを物語っています。ベータシードなし、新機能なし、そしてSequoia 15.7.9とSonoma 14.8.9への同日バックポート。いずれも、これをどの環境でも早急に塞ぎたかったベンダーの姿を示しています。CVE-2026-65400はローカルネットワーク上の攻撃者が有効な認証情報なしにScreen Sharingへ認証することを許すもので、Appleは状態管理の改善によってこれを修正しました。公開された記録から確認できるのは、ここまでです。
その記録に残る空白が有効／無効の問いであり、これは思い込みで解決するのではなく、そのまま抱えておく価値があります。Appleはサービスが動作している必要があるかどうかを述べていません。heiseは不明だとしています。Screen Sharingは初期状態でオフなので、自分は最初から無関係だったと結論づけたくなりますが、その結論を裏付ける公開情報はありません。仕組みに関するより詳細な主張が裏付けのないまま出回っており、アップデートの可否をそれで判断すべきではありません。
今週中に26.6.1、あるいは15.7.9や14.8.9をインストールしてください。そのうえで、システム設定、一般、共有に10分ほど費やし、1つではなく3つのリモートアクセススイッチすべてを確認してください。必要でない限りScreen Sharingとリモートマネージメントの両方がオフであることを確認し、リモートログインも別途チェックし、「すべてのユーザ」の設定は明示的なリストに置き換え、ファイアウォールをオンにしてください。Macへのリモートアクセスが本当に必要なら、そのマシンがたまたま接続しているネットワーク上に公開するのではなく、VPNやオーバーレイネットワーク経由で到達するようにし、ポート5900は決してフォワードしないでください。その構成であれば、今回のCVEはあなたにとってほぼ机上の話で済んでいたはずですし、次に来るCVEに対しても同じ働きをします。