Macの信頼済みアプリが差し替えられる問題〜Appleが脆弱性と認めない理由

Macにインストール済みのアプリの中身が静かに差し替えられる問題を、海外の研究チームが公表しました。差し替え後も正規アプリとして起動するため、警告は一切表示されません。ただしこの手口が成立するのは、すでにMacへの侵入を許した後です。Appleはこの問題を脆弱性と認めず、修正しない判断を下しました。その線引きはどこにあるのでしょうか。

対象はWebから入手して一度起動したアプリ

この手口が使えるアプリは限られます。対象となるのは、App Store以外から入手し、かつ一度以上起動されたアプリです。Mac App Store経由のアプリは所有者がシステム側のため、ログイン中のユーザー権限では書き換えられません。そして最大の条件が、攻撃者がすでにユーザー権限でコードを実行できる状態にあることでした。

仕組み自体は単純です。アプリをいったんアーカイブ化して展開し直すと、中身が変わっていても再検証が走らないと報告されています。研究チームのデモでは、差し替えたアプリが正規のものとして起動し、アクセス許可ダイアログがそのまま表示されました。

Appleが修正不要と判断した2つの理由

Appleは報告を受けたうえで、保護の仕組みは回避されていないと結論づけています。判断の土台になったのは、Gatekeeperの設計思想と、アクセス許可をめぐる責任の所在です。

Gatekeeperとは、Web経由で入手したアプリを初回起動の前に検証するAppleの公式セキュリティ機能です。Apple公式のセキュリティガイドは、ダウンロードしたソフトウェアを初めて開く際にユーザーの承認を求めると説明しました。つまりGatekeeperが見張るのは初回起動の前までであり、その後もアプリを監視し続ける役割は負っていません。今回の手口は初回検証を通過した後に起きるため、Appleの整理では守備範囲の外という位置づけになります。

もう一方の軸となったのが、アプリのアクセス許可を管理する仕組み（TCC）です。差し替えられたアプリがダイアログを表示しても、最終的に許可を与えるのは利用者自身になります。Appleはこれを保護機構の回避ではなく、ソーシャルエンジニアリングの問題として整理しました。

この判断は、Appleが進めてきたmacOSの防御強化の方向性とも一致しています。近年の攻撃はソフトウェアの欠陥を突く形から、ユーザー本人をだます形へと移ってきました。Appleの視点では、今回の報告も後者に分類されるでしょう。

一方の研究チームは、この整理に反論しています。macOS自体が変更を検知してアクセス許可を再要求している以上、変更を見つける仕組みはすでに動いているという指摘です。であれば、「バンドルに変更があった時点で署名を検証し直せばよい」という主張になります。

同じ研究チームの前回報告は5カ月で修正された

Appleの線引きを理解するうえで参考になるのが、同じ研究チームによる前回の報告でした。macOSのアーカイブユーティリティをめぐるもので、アプリのサンドボックスやTCCなどの保護をまとめて回避できる内容です。2025年10月に報告され、2026年3月公開のmacOS 26.4で修正されています。

	前回の報告	今回の報告
回避された保護	サンドボックス TCC アプリ保護	なし（Appleの見解）
ユーザーの操作	ほぼ不要	許可ダイアログの承認が必要
Appleの対応	報告から5カ月超で修正	修正不要と判断

2件を並べると、Appleの判断基準が見えてきます。分かれ目は保護機構そのものが破られたか、ユーザーの承認を経たかという一点でした。前者であれば時間はかかっても修正され、後者であればソーシャルエンジニアリングとして扱われます。

この基準そのものは筋が通っています。ただし利用者の立場に立つと、被害が出るかどうかは基準の内側か外側かとは無関係です。前回の報告にしても、修正までには5カ月以上かかりました。Appleが脆弱性と認めた場合でも、その間ずっと守られていたわけではありません。

侵入経路はHomebrewやAIエージェント

ここまでの条件を見ると、攻撃の成立には高いハードルがあるように思えます。しかし研究チームが挙げた侵入経路は、決して特殊なものばかりではありませんでした。共通しているのは、利用者が危険なことをしている自覚を持ちにくい点です。怪しいサイトを避けるという従来の心構えだけでは、どちらの経路も防ぎきれません。

パッケージマネージャー経由で持ち込まれる場合

研究チームは、npmやHomebrewを通じたサプライチェーン攻撃を経路の1つに挙げています。開発ツールやライブラリの配布元が汚染され、利用者が気づかないままコードを実行してしまうケースです。

Macで開発作業をする読者にとって、これらのコマンドは日常的に使うものでしょう。日常の作業動線がそのまま入口になり得るという点が、この報告の本当の論点だと考えられます。

AIエージェントが操作を代行する場合

もう1つ挙げられているのが、AIエージェントへのプロンプトインジェクションです。エージェントが外部の文章を読み込む過程で、意図しない命令を実行させられる手口を指します。

Apple Intelligenceをめぐるセキュリティ研究の指摘でも、AIが個人情報に近い領域で動くことのリスクが取り上げられていました。エージェントに操作を任せる範囲が広がるほど、こうした経路は現実味を増していきます。

App Store縛り以外にできる対策

最も確実な回避策は、Mac App Storeのアプリだけを使うことです。ただし主要なアプリの多くはそこで配布されておらず、現実的な選択肢とは言えません。

現実的にできるのは、入手経路を開発元の公式サイトに限ることです。検索結果の広告枠や、まとめサイト経由のダウンロードリンクは避けたほうが安全でしょう。パッケージマネージャーやスクリプトを使う際も、配布元と実行内容を確認する習慣が効いてきます。

そして今回の手口に対して最も直接的に効くのが、アクセス許可の要求が想定外のタイミングで出たら承認しないという判断でした。使い慣れたアプリが突然デスクトップや書類フォルダへのアクセスを求めてきたときは、いったん手を止めてください。この一手間が、正規アプリになりすました相手を止める最後の関門になります。

Appleが修正しない以上、この関門を守るのは利用者側の役目です。