macOS画面共有のCVE-2026-65400。資格情報なしで認証が通る状態管理の不備

Macの画面共有は、社内のヘルプデスクが遠隔で操作を代行したり、開発者が別室のビルドマシンを覗いたりするために、必要なときだけ有効にする機能です。その待ち受けポートが社外から届く位置にあり、しかも資格情報の検証が途中で成立してしまう。これがAppleがCVE-2026-65400として修正した認証の問題です。Appleの記述は「ネットワーク上の攻撃者が、有効な資格情報なしでScreen Sharingへ認証できる可能性がある」というものです。

Appleは2026年8月6日、macOS Tahoe 26.6.1とmacOS Sequoia 15.7.9とmacOS Sonoma 14.8.9の3本を同時に公開し、いずれの更新もこの1件だけを扱っています。オランダのNCSC-NLは8月12日に助言を更新し、5900番ポートがインターネットから到達できたシステムで実際の悪用が観測されたこと、その全事例でroot権限が奪われMoneroのマイナーが設置されたことを公表しました。CISAは8月18日にKnown Exploited Vulnerabilities(KEV)カタログへ追加し、是正期限を3日後の8月21日、あわせてフォレンジックトリアージを要求する区分としています。

この記事は、Macを業務で使う組織の情報システム担当と開発者に向けて、CVEレコード、Appleのセキュリティコンテンツページ、NVD、CISAのKEVカタログと拘束的運用指令、NCSC-NLの助言、Appleの製品ドキュメントという一次情報をもとに、何が起きるのか、どの版まで上げるのか、露出をどう確認するのか、侵害の有無をどう見るのかを整理します。攻撃を再現する手順は扱いません。ポートの確認やログの調査は自組織が管理する端末とネットワークに限って行ってください。他者の資産に対する調査は許可がなければ不正アクセス行為の禁止等に関する法律に触れる可能性があります。記述は執筆時点(2026年9月5日)に確認できた範囲に限ります。

画面共有が有効なMacで何が起きるのか#

まず、この機能がどこに置かれているかを確認します。Appleのユーザガイドは画面共有を「ネットワーク上の他のコンピュータの利用者が、自分のMacへリモート接続してデスクトップを見て操作できるようにする機能」と説明しています。有効にすると、相手側はファイルやウインドウを開いて移動して閉じることができ、アプリを起動でき、Macを再起動することもできます。無効にすれば、同じネットワーク上の他のコンピュータは接続できません。

待ち受けは5900番です。Appleが公開しているポート一覧は、5900/tcpをRemote Framebuffer(RFC 6143)として掲載し、サービス名をrfb、使う製品をApple Remote DesktopとScreen Sharingとしています。同じ一覧には88/tcpのKerberosの行に「Screen Sharingの認証を含む」という注記もあり、画面共有の認証が単一の経路ではないことがうかがえます。

Appleが公表しているCVE-2026-65400の影響は、資格情報なしで画面共有へ認証できる可能性がある、というところまでです。そこから先に何ができるのかについて、Apple自身は書いていません。公的機関としてはNCSC-NLが、観測された事例で攻撃者がroot権限を取得しMoneroのマイナーを設置したと公表しています。画面が覗かれるだけの話ではなく、端末そのものを掌握される事象として扱われている、という理解が実務上の出発点になります。

被害の広がり方も、単独の端末では終わりません。業務用のMacには、ソースコード、SSHの秘密鍵、クラウドのアクセストークン、パスワードマネージャのローカルデータベース、社内システムへのセッションが載っています。端末が掌握されるということは、その端末が持っている資格情報の系統がまとめて疑わしくなるということです。暗号資産の採掘が目的の攻撃であっても、同じ経路で別の目的の攻撃者が入れることに変わりはありません。

Appleの「TCP and UDP ports used by Apple software products」は、5900番のTCPをRemote Framebufferとして掲載し、RFCの欄に6143、サービス名の欄にrfb、使う製品の欄にApple Remote DesktopとScreen Sharingを記載しています。5900番のUDPも同じ製品の欄で、Remote Framebufferに加えてRTPとRTCPが挙げられています。88番のTCPはKerberos(RFC 4120)で、使う製品の欄に「Kerberos, including Screen Sharing authentication」と書かれています。同ページは冒頭で、製品によってはここに記載のないポートやサービスを使う場合があること、macOSのアプリケーションファイアウォールはポート単位ではなくアプリ単位でアクセスを制御することを注記しています。

一次資料で確定できる事実#

CVEレコードから見ていきます。cveawg.mitre.orgのAPIで取得できるレコードは、割り当て組織の短縮名がapple、予約日が2026年7月22日、公開日が2026年8月6日18時17分(UTC)、最終更新が2026年8月19日です。CNAであるAppleが記述した説明文は次の1文だけです。

An authentication issue was addressed with improved state management.
This issue is fixed in macOS Sequoia 15.7.9, macOS Sonoma 14.8.9, macOS Tahoe 26.6.1.
An attacker on the network may be able to authenticate to Screen Sharing without valid credentials.

日本語にすると、状態管理の改善によって認証の問題に対処した、この問題はmacOS Sequoia 15.7.9とmacOS Sonoma 14.8.9とmacOS Tahoe 26.6.1で修正されている、ネットワーク上の攻撃者が有効な資格情報なしでScreen Sharingへ認証できる可能性がある、となります。

Appleのセキュリティコンテンツページ3本は、いずれも「Screen Sharing」という見出しの下にこの1件だけを載せ、公開日を2026年8月6日としています。報告者の記載は3本とも同じで、Alfredo Pesoli(@__rev)via Bynario Atlas(bynar.io)です。同じ内容はFull DisclosureメーリングリストへAPPLE-SA-08-06-2026の連番で投稿されており、Appleの製品セキュリティのPGP鍵で署名されています。

主要な値を並べると次のようになります。

CVEレコードのproblemTypesの欄は、CNAが記入した部分では「An attacker on the network may be able to authenticate to Screen Sharing without valid credentials」という影響の文言がそのまま入っており、CWE番号はありません。CWE-287はCISAのADPコンテナが付けたものです。この構造を押さえておくと、後で述べる評価の割れ方が読みやすくなります。

Appleの「About the security content of macOS Tahoe 26.6.1」は、リリース日を2026年8月6日とし、Screen Sharingの項目に「Available for: macOS Tahoe」「Impact: An attacker on the network may be able to authenticate to Screen Sharing without valid credentials」「Description: An authentication issue was addressed with improved state management.」「CVE-2026-65400: Alfredo Pesoli (@__rev) via Bynario Atlas (bynar.io)」と記載しています。macOS Sequoia 15.7.9のページ(148171)とmacOS Sonoma 14.8.9のページ(148172)も、対象OSの記載を除いて同一の内容です。ページ冒頭には、Appleは調査が終わりパッチまたはリリースが提供されるまでセキュリティ問題を公表しないという方針が記載されています。

影響を受ける版と修正版の対応#

CVEレコードのaffectedとNVDが生成したCPEの照合条件を突き合わせると、対象は次のとおりです。

版の確認で注意する点が3つあります。

1つ目は、Tahoe系がその後さらに更新されている点です。Appleのセキュリティリリース一覧によれば、macOS Tahoe 26.6.2が2026年8月17日に公開されており、執筆時点のmacOSの最新版は26.6.2です。26.6.1で止めても本件の修正は入っていますが、Tahoe系の端末は26.6.2まで上げるのが素直な判断になります。SequoiaとSonomaについては、執筆時点で15.7.9と14.8.9より新しいセキュリティ更新は一覧に載っていません。

2つ目は、本件の対象として明示されていない系列です。Appleが CVE-2026-65400 について対象と修正版を示したのは、Tahoe 26、Sequoia 15、Sonoma 14 の3系列です。macOS Ventura 13以前については、影響を受けるかどうかも修正版を出す予定があるかどうかもAppleから示されていません。影響が無いことが確認されたわけではないため、手元にVentura以前のMacが残っていて画面共有を使っている場合は、影響の有無が未確認であるという前提で、サポート中のOSへの更新か、機能の停止か、端末の入れ替えを検討することになります。

3つ目は、確認の方法です。資産管理台帳の値ではなく、稼働している端末そのもので版を見ます。ターミナルからであれば sw_vers の出力を、GUIであればアップルメニューのこのMacについてを見ます。MDMを入れているならインベントリの取得日時とあわせて確認します。

# 稼働中のmacOSのバージョンとビルドを確認する
sw_vers

# ProductVersionの値を、系列ごとの修正版の番号と突き合わせる

Appleの「Apple security releases」の一覧には、2026年8月6日の行としてmacOS Tahoe 26.6.1、macOS Sequoia 15.7.9、macOS Sonoma 14.8.9の3件が並んでいます。同じ日にiOSやtvOSなど他のプラットフォームの更新はありません。その後の行として、2026年8月17日にmacOS Tahoe 26.6.2が公開されています。ページ冒頭の記載では、執筆時点でのmacOSの最新版は26.6.2です。2026年8月6日の行に並ぶmacOSの系列はTahoe 26、Sequoia 15、Sonoma 14で、macOS Ventura 13以前の項目はこの日の行にはありません。

CVSSの9.8を付けたのは誰か#

NVDのページを開くと9.8という数字が目に入りますが、この値の出どころを確認しておく価値があります。NVDに記録されたCVSS v3.1のエントリは、sourceが134c704f-9b21-4f2e-91b3-4a467353bcc0、typeがSecondaryです。この識別子はCISAのADP(Authorized Data Publisher)であるVulnrichmentのもので、CVEレコード側でもshortNameがCISA-ADPのコンテナにcvssV3_1として同じ値が入っています。つまり9.8はAppleが付けた値ではなく、NVDのPrimary評価でもありません。Appleは自社のセキュリティコンテンツページでCVSSを公表しない方針を取っており、本件でもスコアは付けていません。

ベクトルを分解すると評価の意味がはっきりします。AV:Nはネットワーク経由で到達できること、AC:Lは特別な条件がいらないこと、PR:Nは事前の権限が不要なこと、UI:Nは利用者の操作が不要なことを表し、ここまででexploitabilityScoreは満点の3.9になります。影響側はC:H/I:H/A:Hで、impactScoreは5.9です。合計してベーススコアが9.8になります。

一方、NCSC-NLは自身の助言NCSC-2026-0280で、同じCVEに対してCVSS(v3)7.1と表示し、優先度をNormaalつまり通常としています。同じ脆弱性に対して7.1と9.8という2つの数字が並んでいるわけですが、これは矛盾ではありません。CVSSのベーススコアは評価者が想定した攻撃の前提と影響の範囲で変わります。NCSC-NLは助言の初版を8月7日に出し、8月12日の更新で公開PoCの存在と実際の悪用を追記していますが、スコアの表示は7.1のままです。CISAのADPは8月14日にSSVCの判定を記録しており、悪用が観測された後の評価です。

社内で優先度を説明するときは、数字だけを持ち出さないほうが説明しやすくなります。CVSSのベーススコアは技術的な深刻度の指標で、悪用の実態や自組織の露出は含みません。CISAが記録したSSVCの3つの答え、つまりExploitation: active(悪用が起きている)、Automatable: yes(攻撃の手順を全自動化できる)、Technical Impact: total(悪用後に資産を完全に掌握される)のほうが、対応の速さを決める材料としては直接的です。

EPSSも見ておきます。FIRSTが公開しているEPSSは、その脆弱性が今後30日以内に実際に悪用される確率を推定するモデルです。CVE-2026-65400の2026年9月4日時点の値は0.09905で、パーセンタイルは0.95248です。確率としては約9.9%ですが、全CVEの中では上位5%に入る水準という読み方になります。KEVに載っている時点で悪用は起きているので、この記事の文脈ではEPSSは補助的な指標です。スコアの読み方そのものは次の記事で整理しています。

NCSC-NLの助言NCSC-2026-0280は、バージョン1.0.1として2026年8月12日に公開され、初版1.0.0は2026年8月7日です。ページ上の時刻表示は現地時刻と協定世界時が混在するため、ここでは日付だけを示します。1.0.1の改訂理由は「Publieke PoC code beschikbaar en actief misbruik bekend」(公開PoCコードが利用可能で、実際の悪用が確認された)と記載されています。優先度はNormaal、特徴はImproper Authenticationです。CVEの欄には「CVE-2026-65400 - CVSS (v3) 7.1」と表示されています。対象製品はApple macOS Sequoia、macOS Sonoma、macOS Tahoeです。

KEVへの収録と3日間の是正期限#

CISAのKEVカタログは、実際の悪用が確認された脆弱性の一覧です。CVE-2026-65400のエントリは、vendorProjectがApple、productがmacOS、vulnerabilityNameが「Apple macOS Improper Authentication Vulnerability」、dateAddedが2026-08-18、dueDateが2026-08-21、knownRansomwareCampaignUseがUnknown、forensicTriageがYes、cwesがCWE-287です。

この日に追加された4件を並べると、期限の付き方の差が見えます。

4件とも期限は収録の3日後ですが、フォレンジックトリアージの要求は3件だけに付いています。BOD 26-04の本文は、表の中の「& forensic triage」という表記について、期限内に修正または緩和を完了することに加えて、その資産が侵害されているかどうかを評価するフォレンジックトリアージを実施しなければならない、と説明しています。forensicTriageがYesとは、直すだけでは足りず、すでに入られていないかを確かめることをCISAが求める水準だと判断した、という意味です。

BOD 26-04が是正期限を決める変数は4つです。資産が公開されているか、KEVに載っているか、攻撃を自動化できるか、悪用後の技術的影響が部分的な制御か完全な掌握か。CVE-2026-65400はKEV掲載、自動化可能、完全掌握という3つがそろっているため、公開資産では最短の区分に落ちます。

拘束の範囲も押さえておきます。BOD 26-04は米国の連邦文民行政機関(Federal Civilian Executive Branch)の情報システムを対象とする拘束的運用指令です。2026年8月21日という日付は、日本の組織を法的に拘束するものではありません。日本の組織にとっての価値は、CISAが実際の悪用を確認したと判断した事実と、直すだけでなく侵害調査まで求める水準だと判断した事実の2つで、これらは社内で優先度を上げるための客観的な根拠として使えます。

なお、KEVのエントリにあるrequiredActionの文言は、ベンダーの指示に従って緩和策を適用し、BOD 26-04とForensics Triage Requirementsの指針への準拠を確保すること、クラウドサービスについては該当する指針に従い、緩和策が利用できない場合は製品の使用を中止すること、そして各資産のインターネット露出の評価は利用者側の責任であること、を求めています。最後の一文は日本の組織にもそのまま当てはまります。自分の環境で5900番がどこまで届くのかを測るのは、CISAでもAppleでもなく運用している側の作業です。

CISAの2026年8月18日の告知「CISA Adds Four Known Exploited Vulnerabilities to Catalog」は、実際の悪用の証拠にもとづいて4件を追加したと述べ、CVE-2026-33824(Microsoft Internet Key Exchange (IKE) Service Extensions Double Free Vulnerability)、CVE-2026-55040(Microsoft SharePoint Weak Authentication Vulnerability)、CVE-2026-59310(Broadcom VMware vCenter Path Traversal Vulnerability)、CVE-2026-65400(Apple macOS Improper Authentication Vulnerability)を列挙しています。あわせて、BOD 26-04がFCEB機関の脆弱性管理要件を定めるものであり、KEVカタログに載り悪用後に資産の完全な掌握を許す脆弱性のうち、公開資産にあるものの迅速な是正を優先するよう求めていると説明しています。

悪用として公的機関が公表している内容#

一次資料として確認できる悪用の事実は2つの系統に分かれます。

1つはCISAです。KEVへの収録そのものが実際の悪用の証拠にもとづく判断であり、8月18日の告知にもその旨が書かれています。CISAのADPが記録したSSVCのExploitationがactiveであることも同じ判断の表れです。ただしKEVカタログにも告知にも、攻撃者や手口の具体的な記載はありません。

もう1つはNCSC-NLです。助言NCSC-2026-0280の8月12日の更新には、次の趣旨が記載されています。NCSCは報告を受け取り、そこから、5900番ポートがインターネットから到達可能だった複数のシステムでこの脆弱性の実際の悪用が観測されたことが判明した。それらのすべての事例で、対象システムのroot権限が取得され、Moneroの暗号資産マイナーが設置されていた。あわせてNCSC-NLは自組織のアラートページで、悪用の前提として画面共有が有効であることと5900番ポートがインターネットから到達できることを挙げています。

この2つが、公的機関が公表している範囲です。技術的な機構やPoCの詳細を解説した文章はセキュリティベンダーや個人の研究者から出ていますが、それらは公的機関の発言ではありません。社内報告を書くときは、悪用が起きているという事実の根拠がCISAとNCSC-NLであること、機構の説明は第三者の解析であることを分けて書いておくと、後の説明が楽になります。

暗号資産の採掘を目的とする侵害は、目立った破壊を伴わないため気づくのが遅れがちです。端末が重い、ファンが回りっぱなし、バッテリーの減りが早いといった利用者からの申告が初期の手がかりになることがあります。仕組みと見つけ方は次の記事で整理しています。

認証の状態管理が崩れる位置#

Appleが公表しているのは「状態管理の改善によって認証の問題に対処した」という1文だけです。ここから先は第三者の解析になりますが、プロトコルの構造を押さえておくと、なぜこの種の不備が成立しうるのかは理解できます。

5900番で話されるRFB(Remote Framebuffer)は、RFC 6143として文書化されています。RFC 6143の手順では、プロトコルバージョンの合意、セキュリティタイプの合意、SecurityResultの送信、初期化メッセージという順で接続が確立します。SecurityResultは4バイトの符号なし整数で、0がOK、1が失敗です。つまりこの系のプロトコルでは、ゼロが成功を表す値になります。

RFC 6143はさらに、セキュリティハンドシェイクの後について「両端が本文書に記載のない拡張セキュリティタイプで合意した場合、以降の通信が暗号化された経路や別の形に変えられた経路の上で行われる可能性がある」と注記しています。Appleの画面共有はこの拡張の枠組みを使っており、複数の解析はSRP(Secure Remote Password)にもとづく認証が実装されていると説明しています。

SRPはRFC 2945で定義された認証と鍵交換の方式です。クライアントとサーバがそれぞれ乱数から公開値を作り、パスワード検証子を使って共通のセッション鍵を導出し、最後に互いの鍵が同一であることを証明し合います。RFC 2945は証明の段階について「サーバは自身のKを使ってMを計算し、クライアントの応答と比較する。一致しない場合、サーバはクライアントのチャレンジに答えようとする前に、処理を中止しエラーを通知しなければならない」と定めています。SRPの安全性は、この比較と中止がサーバ側で確実に行われることに依存します。

CVE-2026-65400について公開されている解析は、この比較そのものが正しくない、という話ではありません。複数の解析が一致して述べているのは、SRPの状態機械へ到達する前の段階で処理が分岐し、認証済みという状態が立ってしまう、という構図です。フレーム長の検査に失敗した経路が、その直前に行われた読み取り操作の戻り値をそのまま返してしまい、呼び出し側はゼロという値を成功と解釈する。結果として鍵の導出も証明の検証も行われないまま、セッションが認証済みとして扱われる、という説明です。Huntressの解析記事は同じ現象について、暗号による保護が確立しないまま接続が継続するため平文のセッションになる、とも書いています。

ここで押さえておきたいのは、この種の不備が「認証処理そのものの暗号的な弱さ」ではなく「戻り値の意味の取り違え」から生じている点です。CWEの分類がCWE-287 Improper Authenticationになっているのも、認証が完全に欠けているCWE-306ではなく、証明の仕方に不備があるという上位の分類が選ばれた結果と読めます。0を成功として扱う規約と、0をエラーなしとして扱う規約が同じコード経路で混ざると、失敗経路が成功として上位へ伝わることがあります。自分たちのコードでも起こりうる話です。

再現の手順はここでは扱いません。公開されているPoCの入手や実行は、自組織が所有し検証の許可を得た隔離環境に限ってください。

RFC 6143「The Remote Framebuffer Protocol」は、RFBを「フレームバッファの水準で動作するため、あらゆるウインドウシステムとアプリケーションに適用できる、リモートのGUIへアクセスするための単純なプロトコル」と定義しています。7.1.3のSecurityResult Handshakeでは、サーバが4バイトの符号なし整数を送り、値0がOK、値1がfailedであると規定されています。7.1.2の末尾には「セキュリティハンドシェイクの段階の後、両端が本文書に記載されたもの以外の拡張セキュリティタイプで合意した場合、以降の通信が暗号化された経路や別の形に変えられた経路の上で行われる可能性がある」という注記があります。

RFC 2945「The SRP Authentication and Key Exchange System」は、SRPをパスワードにもとづく安全な接続の折衝に適した認証機構と位置づけ、認証の過程で安全な鍵交換も行うため、セッション中の秘匿性や完全性の保護を有効にできると述べています。ホストは利用者のパスワードを、利用者名とパスワード検証子とソルトの3つ組として保存します。認証の最終段階では、クライアントがMを送り、サーバは自身のKからMを計算して比較します。RFCは「一致しない場合、サーバはクライアントのチャレンジに答えようとする前に、処理を中止しエラーを通知しなければならない。そうしないと利用者のパスワードの安全性を損なう可能性がある」と規定しています。

同じ取り違えを自分のコードで起こさないために#

この記事の読者には開発者も含まれるので、機構の話を自分たちのコードへ引き戻しておきます。公開されている解析が描いている構図は、macOSに固有の話ではありません。戻り値の規約が混ざったまま、失敗経路が成功として上位へ伝わる。同じ形は、認証やセッション管理を自前で書いているどのコードでも起こります。

材料は3つです。

1つ目は、ゼロの意味が層によって違うことです。プロセスの終了コードやシステムコールの規約では、ゼロが成功でありエラーなしを表します。一方、RFC 6143のSecurityResultでもゼロがOKです。読み取り関数の戻り値としてのゼロと、認証結果としてのゼロが同じ変数を通ると、区別する材料が失われます。エラー処理と結果の受け渡しを同じ整数の型で兼ねている場合は、その境界を疑う価値があります。

2つ目は、失敗経路のほうが検査から漏れやすいことです。正常系は日常的に動くので、壊れればすぐに気づきます。長さの検査に引っかかった場合、想定外のメッセージ型を受け取った場合、途中で切断された場合といった経路は、通常の利用では通りません。テストが正常系に偏っていると、失敗経路の戻り値が何であるかは誰も見ていない状態になります。

3つ目は、状態を立てる場所です。認証済みという状態を1つのフラグで表し、そのフラグを立てる判断を戻り値の真偽だけに委ねると、判断を誤ったときの被害が最大になります。

対処の方向は3つあります。

• 結果と誤りを別の型で表す。成功時の値と失敗時の理由を同じ整数に詰め込まず、言語が用意している直和型や例外の仕組みへ寄せます。混ざりようがなくなれば、この種の取り違えは構文の段階で止まります。
• 既定を拒否にする。認証済みのフラグは、明示的に検証が成功したという1か所だけで立てるようにし、それ以外のすべての経路では未認証のまま抜けるようにします。判定に失敗したときに通してしまう設計を、判定に失敗したときは落とす設計へ変えます。
• 失敗経路にテストを書く。異常な長さ、想定外の順序、途中の切断といった入力に対して、状態が認証済みにならないことを確認する試験を用意します。プロトコルを自前で実装している場合は、正常系のテストと同じ数だけ異常系のテストがあるかを見ます。

最小権限の設計も同じ方向で効きます。仮に認証の判断を誤ったとしても、その先で動く処理がroot権限でファイルを読み書きできなければ、被害の大きさは変わります。今回の件で影響が端末の掌握まで届いたのは、認証の後段で動く補助的な処理が強い権限を持っていたという説明が、複数の解析から出ているためです。権限の分離は、認証が破られた場合の保険として働きます。

CVE-2026-43760との違い#

同じ画面共有まわりで、2026年7月にもCVEが公開されています。CVE-2026-43760です。混同されやすいので、Appleとcve.orgの記載で並べて整理します。

違いは4点あります。

1点目は前提条件です。報告者であるBynarioは自社ブログで、CVE-2026-43760はScreen SharingまたはRemote Managementが有効で、かつ従来型のVNCの選択肢である「VNC viewers may control screen with password」が設定されている環境が対象であり、攻撃者がそのVNCパスワードを知っている必要がある認証後の問題だと説明しています。これに対しCVE-2026-65400は、Appleの記述のとおり有効な資格情報を必要としません。利用者の限定やVNCパスワードの変更といった従来の締め方が効かないのはこのためです。

2点目は影響の範囲の記述です。CVE-2026-43760についてCISAのADPは、公開されているPoCが、リモートの未認証の攻撃者による任意ファイルの読み取りが可能であることを示していると注記し、あわせてPoCの作者がSIPで保護されていないファイルの書き込みとTCCの迂回も可能だと述べていることを記録しています。つまり同じCVE番号に対して、報告者が説明する認証後の問題と、ADPが記録する未認証の読み取りという2つの像が並んでいます。Appleはこの2つの関係について何も公表していません。

3点目は修正版の系列です。CVE-2026-43760のNVDのCPE照合条件は、14.0以上14.8.8未満と26.0以上26.6未満の2区間で、Sequoia 15系の区間はありません。CVE-2026-65400は3系列すべてが対象です。7月の更新を当てたからといって、8月の更新が不要になるわけではありません。

4点目は扱いの重さです。CVE-2026-43760はKEVに収録されていません。SSVCのExploitationもpocどまりです。実務としては、7月と8月の更新を両方適用したうえで、侵害調査の起点はKEVに収録された8月のほうに置く、という整理になります。

NVDに登録されたCVE-2026-65400は、sourceIdentifierがproduct-security@apple.com、公開日時が2026-08-06T22:18:14、執筆時点のvulnStatusはAnalyzedです。cvssMetricV31にはtypeがSecondaryの評価としてベーススコア9.8が記録され、exploitabilityScoreは3.9、impactScoreは5.9です。weaknessesはCWE-287で、typeはSecondaryです。CISA由来の項目としてcisaExploitAddが2026-08-18、cisaActionDueが2026-08-21、cisaVulnerabilityNameが「Apple macOS Improper Authentication Vulnerability」として記録されています。CPEの照合条件は3区間で、14.0以上14.8.9未満、15.0以上15.7.9未満、26.0以上26.6.1未満です。参照にはAppleの3本のセキュリティコンテンツページ、Full Disclosureへの投稿、NCSC-NLの助言、CISAのKEVカタログが含まれます。

最初の数時間で決める順番#

更新の適用や設定変更は、侵害の痕跡を消してしまうことがあります。CISAのBOD 26-04実装ガイダンスは、証拠の収集を修正より先に置き、可能な場合は証拠や成果物の収集前にシステムを変更したり修正したりしないこと、と明記しています。ただし、この順序は侵害が疑われる端末に対するものです。露出がなく、ログにも異常の兆候がない大多数の端末については、更新を止めてまで証拠保全を待つ必要はありません。台数の多いMacの群を扱う組織では、先に対象を切り分けるところから始めます。

Macが社外から届く位置に置かれる経路#

NCSC-NLが挙げた前提は、画面共有が有効であることと、5900番がインターネットから到達できることの2つでした。既定では画面共有は無効なので、この2つがそろうには理由があります。組織で実際に見かける経路を整理しておくと、洗い出しの網が漏れにくくなります。

• ヘルプデスクの運用で有効にしたまま戻していない。遠隔支援のために一時的にオンにし、作業後にオフへ戻す運用にしていない場合、その端末はずっと待ち受けを続けます。
• リモートマネジメントが入っている。Apple Remote DesktopやMDMで管理する目的でリモートマネジメントを有効にしている場合も、5900番の待ち受けは発生します。Appleのガイドが説明するとおり、画面共有とリモートマネジメントは同時にオンにできない関係なので、共有の設定画面で画面共有がオフに見えていても、リモートマネジメント側で入っていることがあります。
• ビルド用やテスト用のMacを常設している。iOSやmacOS向けのアプリを作っている組織では、CIのビルドマシンや実機検証用のMacをオフィスやデータセンターに常設し、遠隔から画面を見られるようにしていることがあります。この用途の端末は利用者が張り付いていないため、異常に気づくのが遅れます。
• クラウド上のMacを借りている。時間貸しのMacインスタンスは、提供事業者やネットワークの構成によってはパブリックIPが割り当てられます。既定で割り当てるかどうかは事業者やサブネットの設定で変わるため、パブリックIPの有無、経路、セキュリティグループの受信規則、ポート転送を個別に確認します。
• 自宅や拠点のルータでポート転送を設定している。在宅勤務の端末へ社外から入るために、ルータで5900番を転送する設定を個人が入れているケースがあります。組織の資産管理からは見えにくい経路です。
• UPnPで穴が開いている。家庭用ルータのUPnPが有効な場合、端末側の要求で受信ポートが自動的に開くことがあります。意図した設定として記録に残らないため、見落としやすい経路です。

洗い出しの順序としては、まずMDMや構成管理のインベントリで画面共有とリモートマネジメントの状態を機械的に拾い、次に該当した端末がどのネットワークにいるかを確認する、という流れが速く終わります。インベントリを持っていない場合は、業務でMacを使っている部署へ、遠隔支援やビルドマシンの用途で画面共有を使っているかを聞くところから始めます。

到達性を落とす設定とMDMでの一括管理#

更新の適用と並行して、そもそも到達できる状態だったのかを確認します。Appleのユーザガイドが説明する画面共有の設定は、システム設定のサイドバーから一般を選び、共有を開いた先にあります。ここで確認したい項目は4つです。

• 画面共有がオンになっているか。オフであれば、同じネットワーク上の他のコンピュータは接続できません。
• リモートマネジメントがオンになっていないか。Appleのガイドは、画面共有とリモートマネジメントを同時にオンにはできないと説明しています。どちらかが入っていれば5900番の待ち受けは発生します。
• 「アクセスを許可」の設定がすべてのユーザになっていないか。特定のユーザだけに絞れているか。
• 「VNCビューアーがパスワードで画面を操作することを許可」がオンになっていないか。

4つ目の従来型のVNCパスワードは、CVE-2026-43760の前提条件として報告者が挙げていた設定です。CVE-2026-65400に対しては効きませんが、切っておく理由は別にあります。この経路は共有の秘密を1つ置くだけの認証で、利用者ごとの識別が残りません。

待ち受けの状態は、端末側からも確認できます。自組織が管理する端末で実行してください。

# 5900番のTCPを待ち受けているプロセスを確認する
sudo lsof -nP -iTCP:5900 -sTCP:LISTEN

# 画面共有のサービスの状態を確認する
sudo launchctl print system/com.apple.screensharing

台数が多い組織では、端末を1台ずつ見るのは現実的ではありません。MDMで機能そのものを管理下に置きます。Appleは、MDMで管理されているMacをリモート操作する場合の手段としてEnable Remote Desktopコマンドを案内しており、このコマンドはObserveとControlの選択肢を有効にした状態で、すべての利用者に対してリモートマネジメントをオンにすると説明しています。裏返せば、MDM側でこのコマンドを配っていないか、配っている対象がどこまで広がっているかを棚卸しする必要があります。あわせて、Apple Platform Deploymentには画面共有の宣言的構成が用意されており、macOS 14以降のデバイスチャネルとユーザチャネルに対応しています。

MDMを入れていない組織にとっては、今回のような案件が導入の検討材料になります。数百台のMacに対して、版の把握、更新の強制、共有機能の一括停止を人手でやり切るのは難しいためです。

境界の側では、5900番が社外から届く経路を潰します。ルータのポート転送、UTMの受信規則、クラウドのセキュリティグループ、拠点間VPNの経路が対象です。外部からの疎通確認は自組織が保有するIPアドレスに対してのみ行い、実施の記録を残します。他者の資産へのスキャンは行いません。恒久的には、遠隔操作の入口をインターネットへ直接向けず、認証済みの経路の内側へ寄せる設計に変えるのが確実です。

Appleのユーザガイド「Turn Mac screen sharing on or off」は、画面共有を「ネットワーク上の他のコンピュータの利用者が自分のMacへリモート接続し、デスクトップを表示してMacを操作できるようにする機能」と説明し、共有中は相手側がファイルやウインドウを開いて移動して閉じること、アプリを開くこと、Macを再起動することまでできると記載しています。設定はアップルメニューからシステム設定を開き、サイドバーの一般をクリックして共有を選びます。「リモートマネジメントがオンの場合はオフにする必要があり、画面共有とリモートマネジメントを同時にオンにはできない」と明記されています。選択肢として「Anyone may request permission to control screen」と「VNC viewers may control screen with password」があり、後者を有効にするとパスワードの入力が必要になります。「Allow access for」ではすべてのユーザか特定のユーザかを選べます。オフにする手順は、同じ画面で画面共有をオフにするだけです。

侵害の有無を確かめる観点#

露出していた端末については、修正版を当てて終わりにせず、入られていないかを見ます。macOSでの調査の材料は、ユニファイドログ、Endpoint Securityのイベント、永続化の痕跡、資源消費の異常の4つです。

ユニファイドログは保持期間が限られており、端末の使い方によっては数日から数週間で古い記録が押し出されます。まず退避させます。

# ユニファイドログをアーカイブとして収集する(端末の外へ退避させる)
sudo log collect --output /Volumes/EvidenceDrive/mac01_system_logs.logarchive

# 収集したアーカイブからscreensharingdの記録を絞り込む
log show --archive /Volumes/EvidenceDrive/mac01_system_logs.logarchive \
  --predicate 'process == "screensharingd"' --info

# 端末上で直近の記録だけを見る場合
log show --predicate 'process == "screensharingd"' --info --last 7d

見る観点は、想定していない時間帯の接続、想定していない送信元アドレス、想定していない利用者名です。業務のヘルプデスクが使っている時間帯と送信元の範囲を先に把握しておくと、判断が速くなります。記録されるメッセージの書式はmacOSの版で変わるため、まず絞り込んだ出力を眺めて、その端末で何がどう残るのかを確認してから条件を詰めます。

Endpoint Securityの枠組みでは、画面共有の接続に対応するイベント型が用意されています。EDRを入れている組織であれば、この系統のイベントが製品側で収集されている可能性があります。Huntressは自社の解析記事で、画面共有の接続イベントを見る際の着眼点として、セッションの利用者名がrootになっていること(macOSでは既定で無効な利用者)、認証の種別がRSA-SRPではなくSRPだけになっていること、ファイルコピーの補助プロセスがUIDとGIDの組み合わせで0と80として動いていることを挙げています。これは第三者による観測にもとづく指標で、Appleが公表した検知指標ではありません。自組織のEDRで同等の情報が取れるかを、まず製品側の仕様で確認します。

永続化の痕跡は、暗号資産の採掘を目的とする侵害では特に見る価値があります。マイナーは再起動をまたいで動き続ける必要があるためです。

# LaunchDaemonとLaunchAgentを更新時刻つきで一覧する
ls -laT /Library/LaunchDaemons /Library/LaunchAgents
ls -laT ~/Library/LaunchAgents

# sudoの追加ポリシーが置かれていないか確認する
sudo ls -la /private/etc/sudoers.d

# CPUを継続的に使っているプロセスを確認する
top -o cpu -l 2 -n 15

見覚えのないplistがある場合、その中で指すプログラムのパスと署名の状態を確認します。追加のsudoポリシーは、CVE-2026-43760の報告者が悪用の到達点として説明していた場所でもあります。攻撃者が管理者相当の権限を残す常套手段なので、露出していた端末では確認の対象に含めます。

資格情報の棚卸しも忘れないでください。root権限が取られていた可能性がある端末は、その端末に置かれていた秘密の系統がまとめて疑わしくなります。整理すると次のようになります。

ログを端末の中だけに置いていると、侵害された時点で調査の材料そのものが操作されうる状態になります。転送先を持っているかどうかで、この作業の確度が変わります。何をどこへ何日残すのかという設計は、事故が起きてからでは間に合いません。

再発時に効く構えとして残すもの#

今回の対応が終わったあとに残しておくと、次に同じ種類の脆弱性が出たときの負担が変わる項目が5つあります。

1つ目は、Macの版と共有機能の状態を常時把握できる仕組みです。今回いちばん時間を食うのは、対象がどこに何台あるのかを数える作業です。MDMのインベントリでも構成管理のエージェントでも構いませんが、OSの版と画面共有の有無を毎日拾えていれば、次の案件では最初の1時間で対象が確定します。

2つ目は、遠隔操作の入口の設計です。5900番をインターネットへ直接向ける構成は、機能の脆弱性が1件出るたびに露出資産になります。認証済みの経路の内側へ寄せる、送信元を絞る、そもそも別の遠隔管理の仕組みへ寄せるといった選択肢を、平時のうちに比較しておきます。BOD 26-04が是正の緊急度を決める4つの変数の先頭に資産の露出を置いているのは、そこが期限の区分を最も大きく動かすからです。同じ脆弱性でも、外から届かない位置にある端末は、届く位置にある端末とは扱いが変わります。

3つ目は、ログの外部転送です。macOSのユニファイドログは保持期間が短く、端末が侵害された場合は記録の信頼性も落ちます。EDRやログ基盤へ転送しておけば、転送済みの分は端末の外に残ります。

4つ目は、更新の運び方です。Appleの更新は不定期に出て、しかも今回のように1件だけを扱う臨時の更新も混ざります。Appleのセキュリティリリースのページを見る担当と頻度を決め、KEVへの収録を監視する仕組みと組み合わせておくと、判断の起点が安定します。

5つ目は、端末が持っている秘密の量を減らすことです。root権限が取られた場合の影響は、その端末に何が置かれていたかで決まります。長期の秘密鍵を端末へ置かない、資格情報の有効期限を短くする、業務システムのセッションを長く保持しないといった設計は、侵害の後始末の量を直接減らします。

対応チェックリスト#

画面共有を開けたままにしない#

CVE-2026-65400が示しているのは、認証の状態を管理する処理に1か所の取り違えがあるだけで、その手前に積み上げた締め方がまとめて効かなくなるという構図です。許可する利用者を絞っても、従来型のVNCパスワードを長く複雑にしても、認証済みという状態が別の理由で立ってしまえば通り抜けられます。守りの層は、そもそもその処理へ到達させないところに置く必要があります。

一次資料から確定できるのは、Appleが2026年8月6日にmacOS Tahoe 26.6.1とmacOS Sequoia 15.7.9とmacOS Sonoma 14.8.9で修正したこと、Appleの記述が状態管理の改善による認証の問題への対処であること、CISAが8月18日にKEVへ収録し3日後の期限とフォレンジックトリアージを求める区分としたこと、NCSC-NLが5900番の露出したシステムでroot権限の取得とMoneroのマイナー設置を観測したと公表したことです。CVSSの9.8はCISAのADPが付けた値であり、NCSC-NLは同じCVEに7.1を表示しています。数字の出どころまで見ておくと、社内での説明が正確になります。

作業の順番だけ、もう一度確認します。露出している端末を切り出す、疑いのある端末は証拠を先に取る、5900番の外部到達を止める、画面共有を止められるものは止める、修正版を当てる、ログと永続化の痕跡で確かめる。この6つです。そのうえで、遠隔操作の入口をインターネットへ向ける必要が本当にあったのか、端末の版と共有機能の状態を毎日拾えているか、ログは端末の外にも残っているかという3つを検討します。次に似た脆弱性が出たとき、そこに答えがあるかどうかで、費やす時間が変わります。