Critical Flaw in Mac's Popular Video Player IINA Lets a Single Link Hijack Your Mac

A critical vulnerability has been found in IINA, the popular video player for Mac. If a user clicks a malicious link and approves "Open IINA", attackers can execute arbitrary commands on their Mac. The flaw carries a CVSS score of 8.8 out of 10 and has been fixed in version 1.4.3.

IINA is an open-source video player with over 44,000 stars on GitHub, and it has become the de facto standard among Mac users — particularly in Japan, Korea, and China, where many switched to it from VLC.

The vulnerability was discovered by security researcher stackpointer and published on May 21, 2026 as a VulnCheck advisory. The identifier is CVE-2026-47114.

What actually happens

The attack flow is simple. The attacker embeds a link of the form `iina://open?...` in a web page, email, or social media post. This is the special URL format that tells macOS to "open this video in IINA".

When the user clicks the link, the browser shows a pop-up: "Do you want to open this link in 'IINA'?". If the user assumes it's a regular video link and presses "Open", the commands embedded in the URL execute on their Mac. That is what this vulnerability allows.

According to the technical write-up published by the researcher, the proof-of-concept already demonstrates listing a directory with `/bin/ls` and creating marker files with `/usr/bin/touch`. The commands run with the same privileges as the currently logged-in macOS user.

A noteworthy point: "a valid video file is not required" for the attack to succeed. The command portion is processed first, regardless of whether the URL points to a playable video. A realistic scenario is one where the user clicks the link, thinks "the video didn't play", and walks away — while something has already run behind the scenes.

The technical root cause

Technically, this is a class of bug called "argument injection", classified as CWE-88.

IINA internally uses the mpv playback engine, and the URL scheme handler was designed to pass parameters received via URL straight through as mpv startup options. By mixing special parameters such as `mpv_options` or `input-commands` into the URL, an attacker can get mpv to interpret and execute them as internal commands — that is the core of the attack.

The patch in version 1.4.3 introduces an allowlist for parameters coming through the URL scheme and rejects dangerous options. The release notes bluntly describe it as "Fixed a security issue allowing command injection when opening a iina:// URL".

Who is affected

The vulnerable population is every macOS user with IINA installed at version 1.4.2 or earlier. Updating to 1.4.3 resolves the issue.

"User approval is required" sounds reassuring, but in practice this kind of prompt has become almost ceremonial. Many users see "Do you want to open this link in IINA?" while browsing what they believe is a video link, and reflexively press "Open". If IINA is set as your default video player, you are probably even more accustomed to ignoring such prompts.

What to do right now

The fix is simple: update IINA to 1.4.3 or later.

Pick one of the following update paths:

You can confirm your version from "IINA" → "About IINA" in the menu bar. If it shows 1.4.2 or earlier, update sooner rather than later.

As an interim mitigation, don't click unfamiliar video links, and especially be cautious about links starting with iina:// or video links arriving from unknown domains. Select "Cancel" on the approval prompt in those cases.

Why URL schemes get targeted

App-specific URL schemes (`zoom://`, `slack://`, `vscode://`, and so on) are convenient, but they are also a known breeding ground for this kind of vulnerability. There are three reasons.

First, they let arbitrary web content feed parameters into an installed app. Parameters that the app should validate carefully end up flowing in from anywhere on the web. The attacker only needs to drop a link into a normal-looking web page.

Second, protocol prompts carry very little cognitive friction. Users are so used to "Do you want to open this in [App]?" prompts that they no longer read them. The OS- or browser-level confirmation barely functions as authentication or warning in practice.

Third, designs that route parameters straight into internal commands are common. IINA was feeding URL parameters directly into mpv's startup options. The same structural mistake has happened repeatedly across macOS and Windows apps — it is a classic hole.

macOS users should keep in mind that any app installed outside the Mac App Store (those distributed via DMG or `.app` directly) may register URL schemes. The most realistic defense is to keep your everyday apps updated.

Closing thoughts

For today's Japanese macOS users, IINA is effectively a "standard installation". The user base is large, and the trigger for the attack — "click a link, approve open" — is something people do every day. That combination puts this in the category of vulnerabilities every Mac user should be aware of.

The good news is that a fix is already out, and applying it takes seconds. Open IINA tonight and hit "Check for Updates..." once — that's the entire to-do list.

References

• ▸ NVD - CVE-2026-47114 (IINA URL scheme argument injection command execution)
• ▸ VulnCheck - IINA Command Execution via iina://open URL Scheme
• ▸ stackpointer - IINA 1.4.2 URL Scheme Command Execution (researcher's technical write-up)
• ▸ GitHub - IINA v1.4.3 release notes
• ▸ GitHub - fix commit 1e6f432
• ▸ IINA official site