CVE-2026-65400: macOS Screen Sharing、認証バイパスの脆弱性が実際の攻撃で悪用中

エグゼクティブサマリー

CVE-2026-65400は、AppleのmacOS Screen Sharingサービス（screensharingdデーモンが実装)に存在する認証の問題です。Appleは、ネットワーク上の攻撃者が有効な認証情報を持たずにScreen Sharingへの認証を突破できる可能性があることを確認しています。同社は2026年8月6日、macOS Tahoe 26.6.1、Sequoia 15.7.9、Sonoma 14.8.9でこの欠陥を修正し、状態管理の改善による修正だと説明しています。

独自のリバースエンジニアリングによると、この欠陥はScreen Sharing認証ハンドシェイクにおけるプロトコルの状態管理上の弱点が原因とみられています。screensharingdはroot権限で動作するため、認証バイパスに成功した攻撃者は特権を持つネットワークサービスの内部に侵入することになります。この足がかりから、Screen Sharingが使用するファイル転送用ヘルパーを通じてroot権限レベルのファイルアクセスが可能になり、適切な書き込み可能な場所を見つければコード実行や永続化につなげられる可能性があります。

この脆弱性の悪用は理論上のものにとどまりません。CISAは2026年8月18日、CVE-2026-65400をKnown Exploited Vulnerabilities Catalogに追加し、BOD 26-04に基づく連邦政府機関の対応期限を2026年8月21日に設定しました。NCSC-NLは、TCP/5900が開放されたままインターネットに露出していたMacが侵害され、Monero(XMRig)マイナーが展開された事案を報告しています。

あるアンダーグラウンドフォーラムの脅威アクターも、TCP/5900がインターネットに露出しているホストが約24,000件含まれていると主張するダウンロード可能なリストを公開しています。この数字は、潜在的に露出しているホストに関する脅威アクター側の未検証の主張として扱うべきであり、24,000台のMacが実際に脆弱性を持つ、あるいは侵害されたことが確認されたわけではありません。ポート5900は複数のOSにまたがってVNCやリモートデスクトップサービスで使用されており、ポートが開いているという事実だけでは、そのホストがScreen Sharingを実行する未修正のMacであるとは断定できません。

脆弱性の概要

CVE-2026-65400は、screensharingdデーモンが実装するリモートアクセスサービス、macOS Screen Sharingに影響を及ぼす、認証前(pre-authentication)の重大な脆弱性です。このサービスはTCP/5900経由でAppleが独自に実装したRFB/VNCプロトコルの派生版を使用しており、SRP/RSA-SRPによる認証機構を備えています。

この脆弱性は、認証の状態管理における弱点に起因しており、ネットワーク上の攻撃者が有効な認証情報を提供しないまま、認証済み状態のScreen Sharingに到達できる可能性があります。Appleは2026年8月6日にリリースしたセキュリティアップデートで、状態管理の改善によりこの問題に対処しました。

この脆弱性の深刻度はCVSS 9.8(緊急)と評価されており、CISAのKnown Exploited Vulnerabilitiesカタログに追加されています。悪用が確認された事例には、インターネットに露出したMacの侵害と、暗号資産マイニングツールXMRigの展開が含まれます。

主要な詳細

macOS Screen Sharingとは

macOS Screen Sharingは、screensharingdデーモンが実装するApple製のリモートデスクトップサービスです。TCP/5900経由でApple独自のRFB/VNCプロトコル派生版を公開しており、ユーザーや管理者がMacをリモートで閲覧・操作できるようにします。このサービスはシステム設定 → 一般 → 共有 → 画面共有から有効化できるほか、Apple Remote Desktop経由でも有効化可能です。

クライアントが認証されると、Screen Sharingはリモートデスクトップ操作、ファイル転送、クリップボード共有、その他の管理機能をサポートします。そのファイル転送機能は、SSFileCopySenderとSSFileCopyReceiverというヘルパープロセスに依存しています。

CVE-2026-65400のセキュリティ上の影響が大きいのは、screensharingdがroot権限で動作しているためです。さらにSSFileCopySenderはkTCCServiceSystemPolicyAllFiles権限を保持しており、これによりFull Disk Access(フルディスクアクセス)が付与され、保護されたディレクトリに対する通常のTransparency, Consent, and Control(TCC)確認プロンプトを回避できます。

結果として、認証バイパスに成功すると、root権限で動作するサービスを介した特権的なファイル操作へのアクセスが可能になる恐れがあります。ただし、System Integrity Protection(SIP)は独立したセキュリティ境界として引き続き機能しており、保護されたシステム領域へのアクセスを制限し続けます。

Screen Sharing侵害が単一ホストにとどまらない理由

侵害されたMacが孤立したエンドポイントであることはほとんどありません。開発者用や管理用のシステムには、ソースコード、SSH鍵、クラウド認証情報、VPN設定、ブラウザセッションなど、他のシステムへのアクセスにつながりかねない機密情報が含まれている場合があります。

したがって、外部に露出したScreen Sharingサービスの認証前段階での侵害が成功すると、複数のセキュリティ境界を越えて影響が広がる可能性があります。

• 開発者用・IT管理用ワークステーション:ソースコード、SSH鍵、クラウド認証情報、認証済みのブラウザセッションが露出する恐れ。
• 管理用Mac:管理ツール、特権アカウント、他の企業エンドポイントへのアクセスにつながる恐れ。
• 家庭用・小規模オフィス用Mac:インターネットに露出したシステムは集中監視の対象になっていないことが多く、攻撃者から直接到達可能な場合がある。

したがって、CVE-2026-65400が引き起こす運用上のリスクは、影響を受けたMac単体にとどまりません。到達可能なTCP/5900、認証前の脆弱性、特権を持つScreen Sharingコンポーネントという組み合わせにより、侵害された単一のエンドポイントが、認証情報窃取や横展開の足がかりとなる可能性があります。

開示および悪用のタイムライン

影響を受けるバージョンと修正済みバージョン

CVE-2026-65400は、Appleが2026年8月6日にリリースしたセキュリティアップデート以前の、サポート対象macOSリリースに影響を及ぼします。以下のバージョンで修正が適用されています。

Appleは認証の状態管理を改善することでこの脆弱性に対処しました。組織は、特にTCP/5900経由でScreen Sharingが露出しているシステムについて、速やかに該当する修正済みリリースへアップグレードすべきです。

根本原因: 認証ステートマシンの弱点

Appleは、CVE-2026-65400を不適切な状態管理に起因する認証の問題だと説明しています。この脆弱性は、macOS Screen Sharingが使用する認証ステートマシンに影響を及ぼしており、ネットワーク上の攻撃者が、想定される認証情報の検証プロセスを正常に完了させることなく、認証済み状態に到達できる可能性があります。

独自のリバースエンジニアリングでは、この不具合についてより詳細な説明が示されています。公開されている調査によれば、脆弱な経路にはSRPフレーム長の検証とエラー処理の不備が関わっているとみられます。この脆弱な条件下では、認証処理の失敗が、認証失敗を正しく伝播させるのではなく、成功状態を返す、あるいは保持してしまう場合があります。これにより、有効な認証情報が検証される前に、screensharingdが接続を認証済み状態へと進めてしまう可能性があります。

重要なのは、この脆弱性がSRP暗号アルゴリズム自体の破綻ではないという点です。このセキュリティ境界が破られるのは、サービスが認証の検証と認証済みセッション状態との関係を確実に強制していないことが原因です。

認証ステートマシン

Screen SharingサービスはApple独自のRFB/VNCプロトコル派生版を使用し、SRPベースの認証機構を備えています。通常の接続では、クライアントとサーバーがセキュリティタイプをネゴシエートし、その後クライアントはセッションが認証済み状態に遷移する前に、必要な認証交換を完了することが求められます。

概念的には、想定されるフローは次のとおりです。

RFB Connection
      ↓
Security-Type Negotiation
      ↓
SRP Authentication
      ↓
Credential Validation
      ↓
Authentication Success
      ↓
Authenticated Session

脆弱な挙動が発生するのは、不正な形式の認証入力によって検証や状態処理が誤った形で失敗した場合です。認証交換が正常に完了していないにもかかわらず、サービスが確実に認証失敗状態へ遷移するのではなく、認証済み状態を保持または到達してしまうことがあります。

Malformed SRP Input
        ↓
Validation / State Error
        ↓
State Desynchronization
        ↓
Incorrect Authentication State
        ↓
Authenticated Session

公開されている調査では、同一のコードベースに関連する認証前の欠陥が説明されていますが、正確な内部メカニズムや、どの挙動をCVE-2026-65400固有のものとして特定すべきかについては、研究者の間でも見解が分かれています。したがって、詳細なステートマシンの挙動については、Appleの実装に関する確定的な情報としてではなく、あくまで研究に基づく解釈として扱うのが最も安全です。

この区別は重要です。確認されている根本原因は認証の状態管理上の弱点であり、パケットレベルの正確なメカニズムについては引き続き独自の調査に基づくものです。

認証フロー

macOS Screen SharingはTCP/5900経由でApple独自のRFB/VNCプロトコル派生版を使用します。クライアントが接続すると、サーバーとクライアントはRFBプロトコル情報を交換し、利用可能なセキュリティタイプをネゴシエートします。最新のScreen SharingはSRPベースの認証機構を使用しており、正規の認証済みセッションにはRSA-SRPが用いられます。

通常の条件下では、認証プロセスは定義された順序で進行します。クライアントがRFB接続を確立し、サーバーがサポートするセキュリティタイプを提示し、クライアントがApple SRPメカニズムを選択し、サーバーが認証証明を検証したうえで接続を認証済み状態へと遷移させます。この遷移が完了して初めて、クライアントは認証済みのScreen Sharing機能にアクセスできます。

上図は、この想定される挙動と、CVE-2026-65400に関連する脆弱な経路とを対比しています。

正常なフローでは、SRP証明が正常に検証され、検証が成功した後にのみ認証状態が更新されます。これにより、未認証の接続と認証済みのScreen Sharingセッションとの間の想定されたセキュリティ境界が維持されます。

脆弱なフローでは、不正な形式のSRP入力が認証処理中にエラーを引き起こす可能性があります。公開されているリバースエンジニアリングによれば、この脆弱な条件下では、その結果生じた検証失敗が認証ステートマシンを通じて正しく伝播しない場合があるとされています。これによりステートマシンが非同期状態に陥り、有効なSRP証明がないまま接続がAUTHENTICATED状態に遷移してしまう可能性があります。

重要な点は、CVE-2026-65400の悪用にはSRP暗号メカニズム自体を破ることが必要ないということです。むしろ弱点は、その周辺の認証ロジックにあります。すなわち、サービスは認証失敗が決して認証済みセッションにつながらないことを保証しなければなりません。

セキュリティの観点から見た重要な不変条件は次のとおりです。

有効な認証証明がなければ、認証済みセッションは存在しない。

CVE-2026-65400は、この脆弱な条件下において、想定される状態遷移に違反しています。

Appleは、影響を受けたscreensharingdのソースコードや、パケットレベルの正確なトリガーを公開していません。したがって、上図に示した脆弱なフローは、Appleの内部実装を確認・再構築したものではなく、研究に基づく概念モデルとして扱うべきです。

同一コードベースに存在する2つの認証前バグ

公開されている調査によれば、同じ開示期間中に、少なくとも2つの独立した認証前の欠陥がscreensharingdに影響を及ぼしていたとされています。これらの問題は類似した認証状態の挙動を共有していますが、正確な内部メカニズムについて、そしてどちらの挙動をCVE-2026-65400固有のものとして特定すべきかについて、研究者の間で見解が一致していません。

先行する認証前バグ

1つ目の問題は、CVE番号の割り当てのないまま2026年7月27日のmacOS 26.6で静かに修正されたと報告されています。fG!とCalifは、この欠陥を古い成功値が残留する条件だと説明しています。

このモデルでは、SRPフレームが長さやパース処理の検証チェックに失敗し、関数がエラー経路を通じて終了します。しかし、明確な認証失敗ではなく、既存の成功値が呼び出し元に返されてしまうことがあります。その結果、周辺のステートマシンは認証試行が成功したものと解釈してしまう可能性があります。

その後fG!は、対象のファイルパスが分かっている場合に任意のファイルを取得できることを示す、読み取り専用の概念実証コードnavi_the_clownを公開しました。公開されている調査ではまた、このバリアントは有効なアカウント名を必要としないとも報告されています。

CVE-2026-65400

CVE-2026-65400は2026年8月6日にAppleによって修正されました。独自のリバースエンジニアリングでは、この脆弱性を、不正な形式のSRP入力が検証処理を妨害し、認証ステートマシンを非同期状態に陥らせる認証状態の失敗と説明しています。

このモデルでは、想定される認証情報の検証プロセスが正常に完了していないにもかかわらず、接続が認証済み状態に到達してしまう可能性があります。

一部の公開分析では、この経路には有効なアカウント名が必要になる場合があると示されています。ただし、Appleはセキュリティ勧告の中で、有効なユーザー名を明示的な前提条件として文書化していません。ログイン画面でユーザー名が露出しているシステムでは、攻撃者にとってこの条件を満たすことは比較的容易かもしれません。

帰属に関する見解の相違

混乱の主な原因は、古い成功値が残留するメカニズムの帰属です。Huntressや一部の公開概念実証分析では、この挙動をCVE-2026-65400に直接結びつけています。一方Califは、この古い成功値の残留挙動を7月の先行する脆弱性として区別し、CVE-2026-65400については別途、認証状態の非同期問題として説明しています。

技術的な根本原因を説明するうえで、この違いは重要です。本記事では、どちらか一方の再構築を確定的なものとして提示するのではなく、公開された分析を相互に補完し合う研究報告として扱い、ベンダーが確認済みの情報と独自に再構築された挙動とを明確に区別しています。

Appleは、影響を受けたscreensharingdのソースコードや、パケットレベルの正確なトリガーを公開していません。したがって、研究者が説明する正確な内部ステートマシンの挙動は、Apple実装の確定的な記述ではなく、研究に基づくモデルとして扱われるべきです。

防御の観点から見れば、この区別によって緊急性が下がるわけではありません。攻撃者から到達可能な未修正のScreen Sharingサービスはすべて、認証前の悪用リスクがあるとみなし、修正、制限、または無効化すべきです。

コードレベルでの概念的な再構築

以下の疑似コードは、欠陥のあるSRPフレームハンドラを概念的に再構築したものです。これは逆アセンブルではなく、実際のAppleのソースコードでもありません。エラーの戻り値の欠落や古い成功値の残留によって、検証が失敗しているにもかかわらず認証ステートマシンが進行してしまう仕組みを理解するための思考モデルとしてのみ提示しています。

// Conceptual reconstruction — not actual Apple source
int srp_process_frame(Session *s, const uint8_t *frame, size_t len) {
    // A length or parsing check fails. Instead of propagating failure,
    // the function returns a stale success value to the caller.
    if (len < MIN_SRP_FRAME_LEN || frame[0] != EXPECTED_SRP_MSG_TYPE) {
        // Missing: return AUTH_FAILURE;  ← the conceptual fix
        goto cleanup;  // returns last_status, possibly still AUTH_SUCCESS
    }
    // Normal SRP proof validation would happen here.
    // In the vulnerable path it is skipped because the state machine
    // already believes the step succeeded.
cleanup:
    return last_status;  // may still be AUTH_SUCCESS from a prior step
}
// Caller sees AUTH_SUCCESS and advances state to AUTHENTICATED.
// The session may continue without the cryptographic protections
// that a completed SRP handshake would normally provide.

この再構築は意図的に単純化されています。Appleは影響を受けたソースコードを公開しておらず、公開されている研究者らは同一コードベース内で2つの関連する認証前の欠陥を報告しています。したがって、このステートマシンモデルは、検証済みのAppleソースコードや、確実なパケットレベルの悪用手順ではなく、研究に基づく説明として扱うべきです。

認証前という性質がリスクモデルを変える理由

CVE-2026-65400が認証前の脆弱性であるという性質は、通常の認証情報検証が行われる前に認証の壁が突破されてしまうため、そのリスクを大幅に高めています。

特に重要な要素が3つあります。

• アカウント制限だけでは不十分:Screen Sharingを特定のユーザーに限定しても、認証プロセス自体の中で発生する脆弱性には対処できません。
• パスワード変更では欠陥は解消しない:Screen SharingやVNCの認証情報をローテーションしても、根本的な認証状態管理の弱点は修正されません。
• ネットワーク露出が重要な条件:攻撃者は脆弱なScreen Sharingサービスに到達できなければなりません。NCSC-NLは、TCP/5900がインターネットからアクセス可能な状態にあったシステムの悪用を報告しています。

したがって、外部に露出した未修正のScreen Sharingサービスは、設定されているScreen Sharingのアカウントやパスワード設定にかかわらず、高リスクな攻撃対象領域として扱うべきです。

攻撃チェーン: インターネット露出から起こり得るコード実行まで

CVE-2026-65400は、直接的に任意のコマンド実行を可能にするものではありません。むしろ悪用に成功すると、Screen Sharingの認証境界を突破し、特権を持つファイル転送機能へのアクセスが可能になります。利用可能な書き込み可能な場所やmacOSのセキュリティ制御次第で、このアクセスはその後、機密データの窃取、永続化、あるいは起こり得るコード実行に利用される可能性があります。

公開されている調査によれば、悪用は比較的少数の不正な形式のプロトコルメッセージで引き起こすことが可能であり、ヒープグルーミングやASLRバイパスといった従来のメモリ破損技術には依存していません。

1. 偵察

攻撃者は、TCP/5900が開放されているホストのリストを入手または生成します。アンダーグラウンドフォーラムへの投稿では約24,000件のホストが挙げられていますが、この数字は脅威アクター側の未検証の主張として扱うべきです。同時期に行われた公開スキャンでは、数万件規模のインターネット向けポート5900サービスが発見されており、Califが引用する@osxreverserによる独自スキャンでは、到達可能なScreen Sharing搭載Macが約40,000台見つかったとされています。

# Example authorized discovery command
nmap -p 5900 --open -Pn target-range.example.com/24
# runZero query to identify Apple macOS hosts with port 5900
os:="Apple macOS%" AND port:5900 AND protocol:vnc

2. RFB / プロトコルハンドシェイク

クライアントはポート5900へTCP接続を確立し、RFBプロトコルのネゴシエーションを実行します。Apple Screen SharingはRFB 003.889バナーを使用し、Apple独自のSRP認証機構を含む、サポートするセキュリティタイプを提示します。

この段階では、プロトコルの識別が、汎用的なVNC実装と潜在的なApple Screen Sharingサービスを区別するうえで有用です。

3. SRP認証バイパス

クライアントはセキュリティタイプ36を選択し、不正な形式のSRPメッセージを送信します。脆弱な経路では、フレーム長の検証処理が早期に打ち切られる、あるいはステートマシンが非同期状態に陥ることで、古い成功値の残留やエラーの戻り値の欠落により、いかなる認証証明も検証されないうちに、デーモンが接続を認証済みとして扱ってしまいます。

4. 認証済みセッションの確立

この認証状態の失敗の後、想定される認証情報の検証プロセスが正常に完了していないにもかかわらず、接続が認証済みとして扱われる可能性があります。

公開されている調査によれば、CVE-2026-65400の非同期経路では、通常の認証済みセッションが完全に確立される前にこの失敗が発生するとされています。サービスがいったん接続を認証済みとして受け入れると、クライアントは通常であれば認証成功を必要とするScreen Sharing機能にアクセスできるようになります。

screensharingdはroot権限で動作するため、その結果得られるサービスのコンテキストは非常に強い特権を持ちますが、個々のヘルパープロセスは依然としてそれぞれの権限とmacOSのセキュリティ境界の対象となります。

5. SSFileCopyヘルパー経由の特権的ファイル操作

Screen Sharingは、SSFileCopySenderとSSFileCopyReceiverを通じてファイル転送機能を提供します。

SSFileCopySenderは特権を持つアクセス権で動作し、kTCCServiceSystemPolicyAllFiles権限を保持しているため、Full Disk Accessが付与されます。これにより、通常のTCC同意プロンプトをトリガーすることなく、保護されたユーザーデータへのアクセスが可能になる場合があります。

ただし、TCCとSIPは別個のセキュリティメカニズムです。Full Disk Accessが自動的にSystem Integrity Protectionを回避するわけではなく、特定の保護されたシステム領域は引き続き制限されたままです。

6. ファイルの読み書きと起こり得るRCE

該当するmacOSのセキュリティ制御次第では、特権を持つファイルアクセスにより、SSH鍵、ブラウザデータ、認証情報、ソースコード、その他の保護されたファイルを含む機密情報が露出する可能性があります。

ファイル書き込み機能もまた、実行をトリガーする適切な場所が書き込み可能であれば、永続化やコード実行への経路となる可能性があります。重要な違いは、これがCVE-2026-65400によって直接提供される自動的なコマンド実行ではなく、認証後の悪用チェーンであるという点です。

7. 侵害後の活動と永続化

特権的なアクセスを獲得すると、攻撃者はアクセスの維持、認証情報の窃取、あるいは侵害されたシステムの現金化を試みる可能性があります。

• LaunchDaemonなどの永続化メカニズムの作成または改変。
• 不正なSSH鍵の追加。
• ユーザーの起動スクリプトやその他の書き込み可能な実行場所の改変。
• XMRigなどの暗号資産マイニングソフトウェアの展開。
• ファイアウォール設定やその他のセキュリティ制御の改変。
• 窃取した認証情報や鍵を利用したその後の横展開。

NCSC-NLは、実際の悪用においてXMRigの展開を具体的に報告しています。不正なSSH鍵、LaunchDaemon、ファイアウォールの改変といったその他の痕跡については、NCSC-NLのキャンペーンで確認された痕跡としてではなく、あり得る調査対象として扱うべきです。

プロトコル交換の一例

以下のやり取りは、脆弱なセッション中に発生し得るプロトコルメッセージを概念的に示したものです。正確なバイト列は、具体的な概念実証コードの実装、および2つの認証前バグのうちどちらが標的とされるかによって異なります。これは確実な悪用手順ではありません。

# Conceptual protocol exchange (illustrative, not a verified exploit recipe)
Client → Server: RFB 003.889 banner
Server → Client: RFB 003.889 banner
Server → Client: supported security types, including Apple SRP (type 36)
Client → Server: selects Apple SRP (type 36)
Client → Server: malformed SRP authentication message
# Server state machine incorrectly advances to AUTHENTICATED
Server → Client: security result = success
# Session continues without the protections of a completed SRP handshake
Client → Server: authenticated Screen Sharing operation
Client → Server: privileged file-operation request
Server → Client: file-operation response (read or write data)

この再構築は防御的な分析や検知エンジニアリングに有用です。確認済みのワイヤーレベルの悪用トラフィックとして扱うべきではありません。

研究者が露出ホストを発見する方法

研究者と脅威アクターは、TCP/5900のリスナーを特定するために、同じ基本的なインターネットスキャン技術を使用します。Califが引用する@osxreverserによるスキャン(到達可能なMac約40,000台)で使用された正確なツールは公開されていませんが、その手法自体はよく知られています。IPv4アドレス空間全体に対してポート5900のTCP SYNスキャンを実行し、有望なホストに対してバナー取得を行い、RFBバージョンや可能であればOSを特定するというものです。

MasscanとZmapは最も一般的な高速スキャナーです。これらは単一のポートについて、公開IPv4空間全体を数時間でスキャンできます。その後、より低速で正確なバナー・サービス識別のためにNmapが使用されます。Shodan、Censys、runZeroは、同じデータに対する既製のクエリインターフェースを提供しています。

典型的な露出ホスト調査のワークフロー

• Masscan/zmap: 大規模なネットブロック(またはIPv4空間全体)に対してTCP/5900の開放をSYNスキャン。
• Nmapによるバナー取得: RFB 003.889バナーとセキュリティタイプの提示を識別。
• OSフィンガープリンティング: バナー情報とnmapのOS検出、あるいはrunZeroの資産データを組み合わせてmacOSかどうかを推測。
• ジオロケーション/ASNマッピング: 得られたリストについて国・ISP・組織別の内訳を作成。

得られた件数は、脆弱なMacの実数調査ではなく、インターネットから到達可能なポート5900サービスのスナップショットにすぎません。こうしたリストの多くのホストは、LinuxやWindowsのVNCサーバー、修正済みのMac、あるいはハニーポットである場合があります。したがって、アンダーグラウンドの約24,000件のリストや、@osxreverserによる約40,000件という数字は、上限値としての偵察用データセットと理解するのが最も妥当です。

スキャンコマンドの例

以下のコマンドは、所有しているネットワーク、または明示的な書面による許可を得たネットワークに対してのみ実行してください。

# High-speed SYN scan of a large range for TCP/5900
masscan -p5900 0.0.0.0/0 --max-rate 10000 -oG masscan-5900.grep
# Slower, accurate banner and service identification on the open hosts
nmap -p5900 -sV -sS -Pn --open -iL open-5900-hosts.txt -oA nmap-5900-banners
# Filter for Apple Screen Sharing banner in the nmap output
grep -i "RFB 003.889" nmap-5900-banners.nmap
# runZero query for Apple macOS hosts with port 5900
os:="Apple macOS%" AND port:5900 AND protocol:vnc
# Shodan query for VNC / Apple Remote Desktop services
shodan search "port:5900 RFB" --fields ip_str,port,org,os
# Censys query for VNC services on port 5900
censys search "services.port: 5900 and services.service_name: VNC" --pages 1

結果の解釈

TCP/5900が開放された約40,000件のホストのリストには、次のようなものが含まれます。

• Apple Screen Sharing / Apple Remote Desktopのリスナーであることが確認済みのもの(RFB 003.889バナー)。
• Linux、Windows、その他のOS上で動作する汎用的なサードパーティ製VNCサーバー。
• サービス自体は到達可能なままの、修正済みのMac。
• ハニーポット、NATリダイレクト、設定ミスのサービス。

特定のホストが未修正のMacであるかどうかを確認できるのは、対象を絞った許可済みの調査だけです。スキャン件数は露出状況の推定やパッチ適用の優先順位付けには有用ですが、脆弱性や侵害の証明にはなりません。

公開されている概念実証コード

GitHub上には、複数の実際に動作する概念実証実装が公開されています。これらはCVE-2026-65400の実際の悪用を示すものであり、プロトコルの挙動を理解する必要のある防御担当者や、隔離された環境での許可済みレッドチームテストにとって貴重な参考資料となります。

• panchocosil/CVE-2026-65400-poc — 読み取り専用のPython製PoC。TCP/5900に接続し、RFB/SRPハンドシェイクを実行して認証前バイパスを引き起こし、/etc/sudoers、/etc/passwd、/etc/master.passwdといったroot専用ファイルを読み取ります。このバグは不安定(racy)だと説明されており、再試行が必要になる場合があります。修正済みホストは検出され、再試行は行われません。
• acheong08/CVE-2026-65400 — 読み取り専用版から派生した拡張版Python製PoC。任意のファイル書き込みを追加し、RCEを実現します。永続化のためのLaunchDaemon plistの書き込みや、既存の特権ヘルパーツール(例: Microsoft AutoUpdate、ZoomDaemon、TeamsUpdaterDaemon)の上書きによる即時実行が可能です。
• HORKimhab/CVE-2026-65400 — read、write、execコマンドを備えた試作段階のPoC。リバースシェル機能も含む(SIP無効環境限定と報告されている)。
• initconf/zeek-screensharing-rce — ネットワークトラフィック中の同一プロトコル痕跡を観測するZeek検知パッケージ。

読み書き可能な公開PoCが存在することで、悪用の障壁は大幅に下がっています。防御担当者は、インターネットに露出した未修正のScreen Sharingリスナーはいずれも、既製のツールで侵害され得ると想定すべきです。

検証環境の構築と検証

検証環境の目的は、本番システムに対する完全な悪用可能性を証明することではなく、露出状況、パッチ適用状態、検知ロジックを検証することです。以下の構成は、許可済みのテストのためにネットワークおよびエンドポイントの痕跡を再現するものです。

検証環境の構成要素

• ターゲット: Screen Sharingが有効な、未修正のmacOS VMまたはベアメタルホスト(バージョンは26.6.1 / 15.7.9 / 14.8.9より前)。
• 攻撃者側: 同じ隔離されたネットワークセグメント上にある、Python 3と公開PoCをクローンしたLinuxまたはmacOSホスト。
• ネットワークキャプチャ: ターゲットセグメント上のtcpdump / Wiresharkで、RFB 003.889バナーとSRPのやり取りを観測。
• エンドポイントテレメトリ: ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACHイベントを捕捉するためのESコレクターまたはレッドチーム用テレメトリツール。
• ネットワーク検知: initconf/zeek-screensharing-rceパッケージを備えたZeekまたはSuricataのインスタンス。

ターゲットVMの準備

# Enable Screen Sharing (equivalent to System Settings → General → Sharing → Screen Sharing → On)
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.screensharing.plist
# Verify screensharingd is listening on TCP/5900
sudo lsof -i :5900
# Confirm the target is unpatched
sw_vers -productVersion
# Expected vulnerable output: 26.6, 15.7.8, 14.8.8, or earlier.

読み取り専用PoCの実行

# Clone the public PoC
git clone https://github.com/panchocosil/CVE-2026-65400-poc.git
cd CVE-2026-65400-poc
# Read /etc/sudoers (default target)
python3 poc_screensharing.py <TARGET_IP>
# Read /etc/master.passwd with 50 retries and a longer timeout
python3 poc_screensharing.py <TARGET_IP> /etc/master.passwd -r 50 -t 10
# Expected success output:
#   [+] Banner: RFB 003.889
#   [+] Security types include SRP (36)
#   [+] SecurityResult = 0 (authenticated)
#   [+] File content: ...
# Expected patched output:
#   [-] SecurityResult != 0 or SRP type not advertised
#   [-] Host does not appear vulnerable (or is patched)

セキュリティへの影響

CVE-2026-65400は、認証前バイパスとroot権限で動作するScreen Sharingサービスという要素が組み合わさっているため、セキュリティへの影響が大きい脆弱性です。攻撃に成功すると、有効な認証情報を必要とせずに特権的なファイル操作へアクセスできる可能性があります。

1. root権限によるファイルアクセス

screensharingdデーモンはroot権限で動作します。したがって、その認証ゲートを突破すると、攻撃者は単なるデスクトップ閲覧セッションではなく、root権限を持つサービス内部の認証済みセッションを得ることになります。SSFileCopySenderを通じて、攻撃者はSIPやその他のmacOS保護機能の制約下ではあるものの、rootがアクセスできるファイルの読み書きが可能になります。

2. 任意のファイル読み取りとデータ窃取

Full Disk Accessにより、パスがSIPで保護されていない限り、攻撃者はTCCダイアログをトリガーすることなく、ユーザーのキーチェーン、ブラウザプロファイル、クラウドトークン、SSH秘密鍵、ソースコード、/etc/sudoersなどのシステムの機密情報を読み取ることができます。

3. リモートコード実行と永続化

書き込み可能なシステム領域やユーザー領域への書き込みアクセスにより、複数のRCEおよび永続化の経路が可能になります。LaunchDaemon、シェル起動ファイル、SSH authorized_keysなどです。SIPが有効なシステムでは、cronベースの永続化は制限されます。永続化メカニズムは、再起動やユーザーのログアウトを乗り越えて残存する可能性があります。

4. SIPバイパスではなくTCCバイパス

SSFileCopySenderの権限はkTCCServiceSystemPolicyAllFilesを付与しており、これにより保護されたディレクトリに対する通常のTCCプロンプトが回避されます。ただし、System Integrity Protection(SIP)は引き続き特定のシステムディレクトリへの書き込みを制限します。このバグが破るのは認証とTCCの同意プロンプトであり、SIPを破るものではありません。

5. 横展開

侵害されたMacは、ネットワーク内部への足がかりとなります。Macから窃取されたSSH鍵、VPN設定、キャッシュされた認証情報は、他のシステム、クラウドテナント、あるいはIDプロバイダーへ移動するために利用される可能性があります。

6. リソースの不正利用と金銭的動機

実際の攻撃で確認されている活動には、XMRig Moneroマイナーの展開が含まれます。日和見的な攻撃者は現時点では暗号資産による利益を動機としていますが、同じ攻撃経路は今後、ランサムウェア、認証情報窃取、あるいはスパイ活動に転用される可能性があります。

7. サプライチェーンと信頼への影響

開発用やビルド用のMacが侵害された場合、攻撃者はソフトウェアプロジェクトへコードを注入したり、窃取した署名用IDで悪意のあるアップデートに署名したり、CI/CDパイプラインへ侵入したりする可能性があります。その影響範囲は、単一のエンドポイントを超えて広がります。

全体的な影響

CVE-2026-65400は、root権限を持つネットワークサービスに存在する認証前の脆弱性です。この脆弱性は認証の壁を取り除き、特権を持つヘルパーを通じてroot権限レベルのファイルアクセスを許し、インターネットに露出したシステムに対して実際に悪用されています。適切な対応は、フォレンジック調査によって攻撃者の活動が否定されるまで、到達可能で未修正のTCP/5900を持つMacはすべて侵害された可能性があるとみなすことです。

修正と緩和策

インターネットに露出したmacOSシステムに対する悪用が確認されているため、組織はCVE-2026-65400を優先度の高い脆弱性として扱うべきです。主な対策は、Appleのセキュリティアップデートを適用し、Screen Sharingの不要な露出を取り除くことです。

即座に取るべき対応

1. 影響を受けるシステムを直ちに修正する。
   macOS Tahoe 26.6.1、Sequoia 15.7.9、またはSonoma 14.8.9へアップグレードしてください。これらのリリースには、この脆弱性に対するAppleのセキュリティ修正が含まれています。
2. 不要な場合はScreen Sharingを無効化する。
   システム設定 → 一般 → 共有 → 画面共有に移動し、サービスを無効にしてください。
3. TCP/5900をインターネットからブロックする。
   Screen SharingやVNCサービスが信頼できないネットワークから直接アクセスされないようにしてください。
4. 必要なリモートアクセスを制限する。
   Screen Sharingが必要な場合は、信頼できるネットワークに限定し、TCP/5900を公開する代わりにVPN、ファイアウォールポリシー、踏み台ホストの背後に配置してください。
5. 過去に露出していたシステムを調査する。
   脆弱なバージョンを実行中にTCP/5900経由で到達可能だったMacを特定してください。適切なフォレンジック調査が完了するまで、これらのシステムは侵害されている可能性があるものとして扱ってください。
6. 侵害の痕跡を捜索する。
   想定外のSSH鍵、不正なLaunchDaemon、XMRigのような疑わしい高CPU使用率のプロセス、改変されたファイアウォールルール、通常とは異なるScreen Sharingセッション、その他の想定外のシステム変更がないか確認してください。

長期的な対策強化

• MDMを通じてセキュリティアップデートの適用を強制し、パッチ適用の遅延を減らす。
• インターネットに面したサービスの一覧を維持し、不要な露出を定期的に見直す。
• 信頼できないネットワークからのTCP/5900への受信接続を監視する。
• セキュリティ監視のためにScreen Sharingおよびファイル転送のテレメトリを収集する。
• 機密性の高い認証情報、ソースコード、署名用IDを保有するMacを、一般ユーザー向けネットワークから分離する。
• 不正な変更がないか、authorized_keys、LaunchDaemon、その他の永続化領域を定期的に監査する。
• Screen Sharingをインターネットに直接露出させる代わりに、リモート管理にはVPNまたは踏み台ホスト経由のアクセスを使用する。
• パスワードのローテーションのみを緩和策として頼らないこと。認証状態管理の欠陥自体を修正するか、サービスを無効化する必要があります。

検知に使える痕跡と指標

以下の痕跡は、防御担当者がCVE-2026-65400に関連する露出システム、不審なScreen Sharing活動、侵害後の潜在的な活動を特定するのに役立ちます。すべての指標が悪用を確定させるわけではありません。ネットワーク露出やプロトコル特性は発見・ヒューリスティックな兆候として扱い、エンドポイントやファイルシステムの痕跡は他の証拠と突き合わせる必要があります。

結論

CVE-2026-65400は、root権限を持つmacOS Screen Sharingサービスに存在する、認証前の重大な脆弱性です。Appleは、ネットワーク上の攻撃者が有効な認証情報なしにScreen Sharingへ認証できる可能性があることを確認しており、その修正を状態管理の改善によるものだと説明しています。独自の調査では、影響を受ける認証ステートマシンについて追加の知見が示されていますが、正確なパケットレベルのメカニズムについては、引き続き研究に基づくものです。

認証の壁が突破されると、攻撃者は特権を持つScreen Sharingのファイル転送機能に到達できる可能性があります。実際のインシデントでは、root権限の取得や暗号資産マイニングツールXMRigの展開など、その潜在的な影響が実証されています。さらなるRCEや永続化は、利用可能な書き込み可能な場所とmacOSのセキュリティ制御次第です。

報告されている約24,000件のアンダーグラウンドリストは、脆弱性を持つあるいは侵害されたMacの確定的な件数としてではなく、偵察用のリソースとして見るべきです。とはいえ、これはインターネットに露出したTCP/5900サービスがもたらすリスクを浮き彫りにしています。

組織は3つの対応を優先すべきです。影響を受けるMacの修正、Screen Sharingのインターネット露出の解消、そして過去に露出していたシステムの侵害の痕跡調査です。実際の悪用が確認されており、この脆弱性がCISA KEVに掲載されていることから、露出した未修正のシステムは優先度の高いセキュリティリスクとして扱うべきです。