CVE-2026-84568 および CVE-2026-84570 に関する公開されたソースガイド付き分析であり、LDAP/OD 入力、NFS 配信、ヘルパーディスパッチ、Gatekeeper の挙動、デバイスノード境界に対する再現可能な証明を含みます。
公開状況 — 2026年10月。 Apple は 2026年9月14日に、macOS Sequoia 15.8、macOS Tahoe 26.7、macOS Golden Gate 27 において両方の脆弱性を修正しました。このリポジトリの再現プログラムは、意図的に未パッチの Mac を含む、隔離された許可済みのラボ環境でのみ使用することを目的としています。
検証状況。 含まれているオンホストバリデータは、影響を受ける macOS 26.4（ビルド 25E246、arm64）のラボホスト上で正常に実行されました。ヘルパーディスパッチテスト、完全なループバック NFS 配信チェーン、パス名/資格情報プローブ、Gatekeeper 差分、および nodev/デバイス境界テストはすべて PASS を返しました。Gatekeeper テストでは、アセスメントが有効化されていました。アプリは構造的に有効でしたが、Team ID を持たないアドホック署名でした。明示的な spctl アセスメントはそれを拒否しました。NFS マウントには noexec も検疫も設定されていませんでした。そして LaunchServices は承認ステップなしでそれを実行しました。各バリデータは cleanup_result=PASS も返し、独立した実行後チェックにより、一時ディレクトリのレコード、マウント、ファイル、および /etc/exports の変更が削除または復元されたことが確認されました。Python ハーネスは、実際の automount/Apple 属性スキーマを持つ一時的な OpenLDAP サーバーに対して別途実行されました。automountKey と apple-user-homeurl の両方のルートが、作成/読み戻し/タイムアウト/復元のチェックに合格しました。これらの観察は、その影響を受けるビルドと含まれているハーネスを特徴づけるものであり、パッチ適用済みリリースに関する主張ではありません。
研究クレジット: Mr.Gedik（@h4ck2s3c）。CVE-2026-84568 は Apple のアドバイザリにおいて Mr.Gedik に公にクレジットされ、CVE-2026-84570 も Mr.Gedik にクレジットされています。
これは研究の公開版です。Apple が公開したアドバイザリ、Apple のオープンソースコード、および含まれている再現可能なラボ資料によって裏付けられた情報のみを含みます。非公開のケース識別子、非公開の通信、非公開の成果物、および無関係な研究は意図的に除外されています。
2つの CVE は攻撃対象領域を共有していますが、独立した根本原因を表しています:
| CVE | Apple が公開した影響 | クライアント側の境界 |
|---|---|---|
| CVE-2026-84568 | ネットワークディレクトリの攻撃者が root 権限で任意のコードを実行する可能性がある | ディレクトリによって制御された fstype が、automountd によって選択される実行可能パスに影響を与えた |
| CVE-2026-84570 | アプリが Gatekeeper チェックをバイパスする可能性がある | ディレクトリによって制御された NFS automount が、アプリケーションの来歴とデバイスノードポリシーの両方の境界を越えた |
Apple は両方の問題を、macOS Golden Gate 27、macOS Tahoe 26.7、および macOS Sequoia 15.8 のセキュリティコンテンツにおいて autofs の下に記載しています。
macOS の automount マップは実行可能な制御データです。マップの行はファイルシステムタイプを選択し、マウントオプションを提供し、リソースを識別し、最終的に特権マウントディスパッチに影響を与えます。2026年9月のアップデート以前は、2つの検証の失敗により、ディレクトリから提供されたデータがクライアント上のセキュリティ境界を越えることが可能でした:
fstype が、意図された /sbin/mount_<type> ヘルパー名前空間を脱出し、NFS 経由で配信された実行可能ファイルに解決される可能性がありました。nodev ポリシーを無効化する可能性がありました。結果として生じたネットワークマウントには noexec も検疫ポリシーも設定されていなかったため、明示的な Gatekeeper アセスメントに失敗したアプリでも、そこから起動することができました。これらは関連する観察であり、互換可能なメカニズムではありません。nodev は特殊デバイス vnode が解釈されるかどうかを制御しますが、Gatekeeper を実装するものではありません。noexec は VFS 境界での実行を制御します。Gatekeeper はアプリケーションの信頼性と来歴を別途評価します。CVE-2026-84570 のバリデータは各境界を独立して報告するため、nodev フラグの欠如がそれ自体で Gatekeeper バイパスの証明として提示されることは決してありません。
ディレクトリへの書き込みアクセスは入口の前提条件であり、結果として得られる権限ではない。automountやユーザーホームの属性を変更することは、利用する各Mac上で実行可能なパス名を選択することや、NFSマウントのカーネルポリシーを弱めることと同等ではない。これらの変換はクライアント上で発生する。
stat()はENOTDIRを返した。したがって、非特権でのrealpath()やstat()の結果は、ここではautomountdの有効な代理とはならない。nodevバイパスを必要としない。完全な84568チェーンは、その配信マウントがnodevとnosuidを保持したまま成功した。デフォルトのautomount設定は、/home配下にディレクトリに裏付けられた入力を公開する:
/etc/auto_master: /home auto_home -nobrowse,hidefromfinder
/etc/auto_home: +auto_home
/etc/auto_home: +/usr/libexec/od_user_homes
最初のインクルードはautomountレコードを解決します。executable-mapインクルードはod_user_homesを呼び出し、ユーザーホーム情報を解決してマップ行を出力します。どちらの経路もautomountパーサーに収束します。
公開ハーネスは両方のディレクトリ形式を明示的に保持しています:
| 経路 | ディレクトリ入力 | 結果として得られるautofsキー/値 |
|---|---|---|
automount | RDNがautomountMapName=auto_homeマップ配下のautomountKey=<key>であるRFC 2307エントリ。値はautomountInformation内 | <key> → 生のマップ行 |
userhome | 既存のユーザーエントリ。値はapple-user-homeurl内 | ユーザーのレコード名キー → <home_dir><url>…</url></home_dir>でラップされたマップ行 |
この区別は運用上は重要ですが、脆弱なシンクにおいては重要ではありません。どちらの値も最終的にMac上でパースされるファイルシステムタイプとマウント引数に影響を与えるからです。
flowchart LR
DS["LDAP / Open Directory"]
AM["AutomountInformation"]
UH["User home attribute"]
GM["getmapent_od()"]
OUH["od_user_homes"]
MAP["Automount map line"]
PARSE["parse_entry() / set_mapent_opts()"]
TYPE{"fstype"}
NFS["Dedicated NFS path"]
GENERIC["Generic helper path"]
EXEC["run_mount_cmd()"]
DS --> AM --> GM --> MAP
DS --> UH --> OUH --> MAP
MAP --> PARSE --> TYPE
TYPE -->|exactly nfs| NFS
TYPE -->|another value| GENERIC --> EXEC
関連する公開ソースパスには以下が含まれます：
od_user_homes.c：ディレクトリのユーザーレコードを解決し、ホームURLを出力します。ns_od.c：ディレクトリのautomountデータを取得します。autod_parse.c：fstypeとマウントオプションを解析します。autod_mount.c：マウントヘルパーを選択して起動します。Appleが公開しているautofs-322ツリーは、修正前のコンテキストとして有用です。影響を受けるビルドでの実行時の挙動が依然として決定的な証拠であり、本記事は公開リポジトリに2026年9月の最終パッチ差分が含まれていると主張するものではありません。
修正前のデフォルトのautofs.confはAUTOMOUNTD_MNTOPTS=nosuid,nodevを提供します。これらはVFSのマウントポリシーであり、Gatekeeperの同義語ではありません：
| レイヤー | 意図される判定 | 影響を受けるビルドでの観察結果 |
|---|---|---|
nosuid | マウントからのset-user-ID/set-group-IDによる権限昇格を無視する | 両方のバリデータで引き続き存在していた |
nodev | マウントからのキャラクタ/ブロックスペシャルファイルを解釈しない | 通常の84568配信マウントでは存在していたが、84570テストでは細工されたdevオプションによって削除された |
noexec | マウントされたファイルシステムからの実行を拒否する | テストした両方のNFS automountには存在しなかった |
| ファイル単位の隔離 | com.apple.quarantineにダウンロードファイルの来歴を保持する | マウントされた実証用アプリとバイナリには存在しなかった |
| マウントの隔離 | ファイルシステムにXNUのMNT_QUARANTINEポリシービットを付与する | テストしたNFS automountには存在しなかった |
| Gatekeeper評価 | アプリが起動を信頼できるかどうかを判定する | グローバルに有効化されていた。明示的な評価は実証用アプリを拒否したが、LaunchServicesは依然としてNFSからそれを実行した |
Appleの公開XNUヘッダーは、MNT_NOEXEC、MNT_NODEV、MNT_QUARANTINEを別個のフラグとして定義しています。これらのレイヤーを分離しておくことは重要です。84570の証拠はポリシー障害の連鎖であり、1つのフラグが他のすべての役割を果たしているわけではありません。
fstypeが実行可能なパス名になる影響を受けるヘルパーディスパッチロジックは、解析されたファイルシステムタイプのトークンをパス名の一部として扱っていました。簡略化した形では次のようになります：
path = "/sbin/mount_" + fstype;
stat(path);
posix_spawn(path, ...);
欠けていた境界は、ファイルシステム識別子と信頼済みヘルパーのベース名との間にありました。/ と .. を含む値は、意図されたヘルパーの名前空間から抜け出す可能性がありました。
このリポジトリで使用されているコンパクトなテスト値は次のとおりです:
fstype: nfs/../../../home/c8a/p
constructed: /sbin/mount_nfs/../../../home/c8a/p
target: /home/c8a/p
値は意図的に正確に nfs にはなっていないため、専用の NFS 分岐ではなく汎用ヘルパーディスパッチに到達します。その最初のコンポーネントは、トラバーサルコンポーネントが処理される前に、依然として実際の mount_nfs ヘルパーを指しています。
決定的な操作は、特権ヘルパーディスパッチパスによって実行される stat() と posix_spawn() です。リポジトリの path_resolution_probe.c は、実際に NFS マウントされたプローブバイナリに対して両方の操作を繰り返します。/bin/echo や他のローカルバイナリで代用することはありません。これは重要です。影響を受けたホストでは、root と標準ユーザーで直接ルックアップの結果が異なっていたためです。
修正前のパーサーは fstype に 32 バイトのバッファを使用しており、最大で 31 バイトの非 NUL バイトしか残りません。ASCII のマップキーでは、その予算は次のとおりです: