トップ/記事一覧/Mac動画プレイヤーIINAの脆弱性、安全なのは1.4.4以降。1.4.3は修正不完全
iina-cve-2026-47114-cover-ja

Mac動画プレイヤーIINAの脆弱性、安全なのは1.4.4以降。1.4.3は修正不完全

Macで人気のオープンソース動画プレイヤー「IINA」にCVSS 8.8の脆弱性が見つかりました。悪意あるリンクをクリックして起動許可をするだけで、攻撃者があなたのMacで任意のコマンドを実行できる恐れがあります。GitHubスター4.4万を超える人気アプリで、開発元は修正版1.4.3を公開済み。即時アップデート推奨です。

ニュース2026年5月22日公開 4日前更新
目次
この記事のポイント

Macで人気のオープンソース動画プレイヤー「IINA」にCVSS 8.8の脆弱性が見つかりました。悪意あるリンクをクリックして起動許可をするだけで、攻撃者があなたのMacで任意のコマンドを実行できる恐れがあります。GitHubスター4.4万を超える人気アプリで、開発元は修正版1.4.3を公開済み。即時アップデート推奨です。

Mac向けで人気のオープンソース動画プレイヤー「IINA」には、バージョン1.4.3以前に、細工されたリンクをクリックして「IINAを開く」を許可するだけで攻撃者があなたのMacで任意のコマンドを実行できる脆弱性(情報セキュリティ上の欠陥。管理番号CVE-2026-47114、深刻度スコアCVSSは10点満点中8.8)があります。手元のIINAが1.4.4以降なら対処は不要、1.4.3以前なら更新が必要です。注意したいのは、当初「修正版」として公開された1.4.3は塞ぎ方が不完全だったことが後から判明している点で、「1.4.3に上げたからもう大丈夫」と思っている人こそバージョンの再確認が要ります。

IINAはGitHubでスター数4.4万を超えるオープンソースの動画再生アプリで、特に日本・韓国・中国のMacユーザーの間で「Macの動画プレイヤーといえばIINA」と言われるほど定番の存在になっています。VLCの後継として乗り換えた人も多いはずです。

脆弱性を発見したのはセキュリティ研究者のstackpointer氏で、VulnCheckのアドバイザリとして2026年5月21日に公開されました。その後、抜け道を残していた1.4.3を置き換える完全な修正版1.4.4が2026年6月24日に公開され、開発元の公式セキュリティアドバイザリ(GHSA-w5xh-98j7-jp5q)も出そろっています。この記事では、どのバージョンなら安全なのか、リンクひとつで何が起きるのか、なぜ最初の修正では足りなかったのかを整理します。

「動画リンクを一回クリックしただけ」の後ろで、Macから出ていくもの

「動画プレイヤーに脆弱性」と聞くと再生がカクつく程度の問題に思えてしまいますが、この脆弱性の本質は「動画を開こうとしただけでMac全体が他人の操作下に入る」という話なので、まずクリックの先で何が持ち出されるかを並べておきます。

この種のIINAリンクを撒く側は、企業システムを狙うランサム集団に限りません。むしろ動機が露骨なのは、韓ドラ・華流・アジア映画ファンに「字幕付き先行配信」と称してリンクを撒く詐欺アカウント、海賊版配信を装って閲覧者のMacから素材ごと盗みたい闇サイト運営、別れた相手のMacを覗きたい元交際相手、フリーランスの映像クリエイターから編集中の素材や納品前データを抜きたい同業ライバルです。彼らが取りに来るのは、Macの「写真」ライブラリ、iCloudキーチェーンに保存されたサービスのパスワード、納品前のFinal Cut/Premiereプロジェクト、メッセージ.appの会話履歴、Safariのオートフィル、暗号資産ウォレットのkeystoreファイル。Mac一台に詰め込んだ仕事と私生活のすべてです。「IINAで開く」を一度押した瞬間、それらにアクセスできる権限が相手のシェルに渡ります。動画は再生されないかもしれませんが、再生されないことが攻撃成立を妨げる条件にはなっていません。

サイバーセキュリティの言葉で言えば、これはURLスキーム経由の「ワンクリックRCE(クリック誘導型のリモートコード実行)」です。フィッシングサイトで資格情報を入力させる手間すらいらず、SNSに貼られた1本の動画リンクをタップさせるだけでログインユーザー権限のコマンドが走ります。最初のコマンド実行の後に続くのは、永続化のためのLaunchAgent登録、SSH秘密鍵 (~/.ssh/id_*) の抜き出し、Slackやメールに残ったセッショントークンの収集、Time Machineバックアップへのアクセス。利用者の側に残るのは「あれ、動画が開かなかったな」という違和感だけで、Macから何が持ち出されたかは画面に何も表示されないままです。

CVSS 8.8 はあくまでテクニカルな目盛りであって、IINAで日常的に動画を見ているMacユーザーが現実に失うのはコマンドが一発走った事実ではなく、写真ライブラリ・仕事中のプロジェクトファイル・保存済みパスワード・SNSにログインしたままの自分という「オンライン上の本人」そのものです。

何が起きるのか

攻撃の流れはシンプルです。攻撃者はWebページ・メール・SNSの投稿などに、`iina://open?...` という形のリンクを仕込んでおきます。これは「IINAでこの動画を開いて」とMacに伝える特殊な形式のURLです。

利用者がそのリンクをクリックすると、ブラウザは「『IINA』でこのリンクを開きますか?」というポップアップを表示します。動画系のリンクだと思って「開く」を押した瞬間、URLに仕込まれたコマンドがあなたのMacで実行される――というのがこの脆弱性です。

発見者が公開している技術解説記事によると、PoC(実証コード)では `/bin/ls` でディレクトリを列挙したり、`/usr/bin/touch` でマーカーファイルを作成したりが確認されています。実行されるコマンドは、その時点でMacにログインしているユーザーの権限と同じです。

攻撃の流れ

  • 1.攻撃者がSNS・ブログ・メール等に細工した iina://open?... リンクを投稿
  • 2.利用者がそのリンクをクリック
  • 3.ブラウザが「IINAでこのリンクを開きますか?」と確認
  • 4.利用者が「開く」を承認
  • 5.IINAが起動し、URLに仕込まれた任意のコマンドが実行される

注意したいのは、攻撃の成立に「有効な動画ファイルが必要ない」点です。URLが動画として正しく開けるかどうかに関係なく、コマンド部分は先に処理されてしまいます。リンクを開いて「動画が再生できないだけ」と思っていたら、裏側ではすでに何かが実行されていた、というシナリオが現実的です。

脆弱性の中身。なぜ最初の修正1.4.3では足りなかったのか

技術的には「引数注入(Argument Injection)」と呼ばれる種類の問題で、CWE分類では「CWE-88」に該当します。

IINAは内部でmpvという動画再生エンジンを使っていて、URLスキーム経由で受け取ったパラメータをそのままmpvの起動オプションに渡してしまう設計になっていました。`mpv_options` や `input-commands` のような特殊なパラメータをURLに混ぜると、mpvが内部コマンドとして解釈・実行してしまう、というのが攻撃の核心です。

2026年5月20日公開のバージョン1.4.3の修正コミットは、危険な `input-commands` オプションを名指しでブロックする対応でした。ところがこの塞ぎ方では足りませんでした。mpvには外部からコマンド実行につなげられるオプションが他にもあり、`log-file` などの別ルートを使えば1.4.3でも依然としてコマンド注入が可能だったことが、後の調査で判明します。

これを受けて2026年6月24日公開のバージョン1.4.4では、方針そのものを転換し、URLスキームから受け付けるオプションをホワイトリスト方式(安全と確認した項目だけを通し、それ以外は全部弾く方式)に切り替えて残っていた抜け道を封鎖しました。開発元が翌6月25日に公開した公式セキュリティアドバイザリ(GHSA-w5xh-98j7-jp5q、CVSS 8.8)も、1.4.3の不完全修正と1.4.4の完全修正をまとめて同じCVE-2026-47114として扱っています。新しいCVE番号が振られていないため、「CVE-2026-47114は1.4.3で修正済み」という初期の情報だけを見て安心してしまいやすい構図になっています。

影響を受ける利用者

対象はIINAをmacOSにインストールしている全ユーザーで、バージョンが1.4.3以前の場合です。1.4.3は当初の修正が入っているものの前述の抜け道が残っているため、対象に含まれます。1.4.4以上にアップデートすれば解消します

項目内容
CVE番号CVE-2026-47114
CVSS8.8(深刻度「高」)
対象macOSのIINA 1.4.3以前
(1.4.3は修正が不完全)
修正版1.4.4(2026年6月24日公開)
公開日2026年5月21日
発見者stackpointer(VulnCheck経由)
攻撃の前提利用者がリンクをクリックし
「IINAで開く」を承認すること
実行権限macOSの現ユーザーと同等
悪用報告2026年7月23日時点で確認なし

「ユーザー承認が必要」と聞くと安心しがちですが、現実にはこの種のプロンプトは形骸化しやすいものです。Web上で動画リンクと見せかけられたものを開くとき、「IINAでこのリンクを開きますか?」と聞かれて反射的に「開く」を押してしまう利用者は少なくありません。特にIINAをデフォルトの動画プレイヤーに設定している場合、この手の確認に慣れきっている可能性が高いです。

対処方法。1.4.4以上へアップデートする

対応は単純で、IINAを1.4.4以上にアップデートするだけです。まずバージョンを確認しましょう。IINAを起動した状態でメニューバーの「IINA」→「About IINA」で表示されます。1.4.3以下なら(1.4.3ちょうどの人も含めて)更新が必要です。

アップデート手順は以下のいずれか:

アップデート方法

  • App内アップデート: IINAを起動→メニューバーの「IINA」→「Check for Updates...」
  • Homebrew経由: ターミナルで brew upgrade --cask iina
  • 公式サイト: iina.io から最新版をダウンロード

なお開発元によると、アプリ内の自動アップデートはGitHubでのリリース公開から24時間後に配信される運用です。新しい版が出た直後は「Check for Updates...」を押しても表示されないことがありますが、その場合は公式サイトかHomebrewから直接更新できます。

あわせて、バージョンにかかわらず身に覚えのない動画リンクをむやみに開かない習慣も有効です。特に iina:// で始まるリンクや、見慣れないドメインから飛ばされてきた動画リンクには、承認プロンプトで「キャンセル」を選ぶのが安全です。

なぜURLスキームは狙われるのか

アプリ独自のURLスキーム(`zoom://` `slack://` `vscode://` など)は、便利な反面、こうした脆弱性の温床になりやすい仕組みです。理由は3つあります。

ひとつ目は、ブラウザ経由で外部からアプリに引数を渡せること。本来アプリ側で慎重に検証すべきパラメータが、Web上の任意の場所から注入できる状態になります。攻撃者は普通のWebページにリンクを貼るだけで攻撃を発動できます。

ふたつ目は、プロトコルプロンプトの認知負荷の低さです。「このアプリで開きますか?」というプロンプトに利用者は慣れすぎていて、内容を確認せずに「開く」を押す傾向があります。OSやブラウザ側が表示するこの確認は、認証や警告として機能しにくいのが現実です。

3つ目は、パラメータが内部コマンドへ直接渡る設計がしばしば見られること。IINAも、URLパラメータをmpvの起動オプションにそのまま流していました。同じ構造の問題は過去にも他のmacOSアプリ・Windowsアプリで繰り返し発生しており、いわば古典的な穴です。

そして1.4.3から1.4.4への経緯は、この種の修正の難しさをよく示しています。「危険なものを名指しで弾く」ブロック方式は、弾き漏らしがひとつでもあれば突破されます。1.4.4が採った「許可したものだけ通す」ホワイトリスト方式のほうが確実で、URLスキームのような外部入力の窓口では本来こちらが定石です。macOSユーザーとしては、Mac App Store外で配布されるアプリ(DMGや`.app`を直接インストールするもの)にこうしたURLスキームの仕組みがある可能性を意識しつつ、普段使うアプリのアップデートをこまめに行うことが、いちばん現実的な防御になります。

実際に悪用されているのか。2026年7月23日時点の状況

脆弱性の公開から約2ヶ月が経った2026年7月23日時点で、米国の政府機関CISAが「実際に攻撃に使われている脆弱性」をまとめたリスト(KEVカタログ)への登録はなく、この脆弱性が実際の攻撃に使われたという報告も確認されていません。また、記事の初出以降にIINAで新しいCVE番号が採番された事実もありません。1.4.4での追加修正も、新しい脆弱性としてではなく同じCVE-2026-47114の続きとして扱われています。

とはいえ、攻撃に必要なのは「リンクを開かせて承認を押させる」ことだけで、手口はすでに公開アドバイザリと発見者の解説で詳しく説明されています。利用者の母数が大きいアプリなので、古い版を使い続ける理由はありません。IINAの最新版は1.4.4で、開発元はUIを刷新した次期バージョン1.5.0の準備中も予告しています。今後どの版を使うにせよ、確認すべきことはひとつだけ。「About IINA」に表示される数字が1.4.4以上かどうかです。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go