IINA Vulnerability Explained: Update to 1.4.4, the 1.4.3 Fix Was Incomplete

IINA, the popular open-source video player for Mac, has a security flaw in version 1.4.3 and earlier: if a user clicks a crafted link and approves "Open IINA", attackers can execute arbitrary commands on their Mac (tracked as CVE-2026-47114, CVSS 8.8 out of 10). If your IINA is on 1.4.4 or later, nothing needs to be done; on 1.4.3 or earlier, you need to update. The catch worth knowing: version 1.4.3, initially released as "the fix", later turned out to be an incomplete patch — so the people who most need to re-check their version are those who updated to 1.4.3 and assumed they were done.

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 complete fix, version 1.4.4, followed on June 24, 2026, replacing the leaky 1.4.3 patch, and the project's own security advisory (GHSA-w5xh-98j7-jp5q) is now published as well. This article walks through which versions are safe, what a single link can do, and why the first fix fell short.

Behind "I Just Clicked a Video Link Once": What Leaves the Mac

A "vulnerability in a video player" sounds like at worst a playback glitch, but the actual shape of this bug is "trying to open a video hands the entire Mac to someone else," so it helps to start by listing what gets carried out after that click.

The people who drop these IINA links into the wild are not limited to ransomware crews going after corporations. The motives that get most pointed here belong to scam accounts that promise "early subtitled drops" to fans of Korean and Asian dramas, pirate-streaming sites that want to lift footage and assets from the viewer's Mac while pretending to serve up a free episode, ex-partners who want a window into a former lover's laptop, and rival freelancers who want a pre-delivery edit lifted off a competitor's machine. What they come to take is the macOS "Photos" library, the website passwords in the iCloud Keychain, that unfinished Final Cut or Premiere project, the conversation history in Messages.app, Safari's autofill, and the keystore files of any crypto wallets — in short, the entire blend of work and personal life packed onto a single Mac. The instant "Open in IINA" is pressed, a shell inside that user's session is what the other side gets. The video may never play, but failure-to-play is not what determines whether the attack succeeded.

In security terminology this is a one-click RCE delivered through URL-scheme abuse. There is no phishing form to fill in; a single tap on what looks like a video link on social media is enough to run commands under the logged-in user. What follows that first execution is the rest of the playbook: a persistence LaunchAgent, extraction of SSH private keys from ~/.ssh/, harvesting of Slack and mail session tokens, access to Time Machine backups. What the user is left with on their screen is the vague feeling that "the video didn't open" — the actual loss never surfaces in any UI.

CVSS 8.8 is only the technical gauge. What a Mac user who casually watches videos in IINA actually loses is not the fact that a command ran once; it is the photo library, the in-flight work project, the saved passwords, and the "online self" that is still logged into every service.

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 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, and why the 1.4.3 fix fell short

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.

Version 1.4.3, released May 20, 2026, addressed this with a patch that blocked the dangerous `input-commands` option by name. That turned out not to be enough. mpv exposes other options that can be bent into command execution, and later analysis showed that command injection was still possible on 1.4.3 through alternate routes such as `log-file`.

In response, version 1.4.4, released June 24, 2026, changed the approach entirely: options accepted through the URL scheme now go through an allowlist (only explicitly approved items pass; everything else is rejected), closing the remaining bypasses. The project's official security advisory (GHSA-w5xh-98j7-jp5q, CVSS 8.8), published June 25, treats both the incomplete 1.4.3 patch and the complete 1.4.4 fix under the same CVE-2026-47114. Because no new CVE number was assigned, anyone who only saw the early "fixed in 1.4.3" reports could easily conclude they are safe when they are not.

Who is affected

The vulnerable population is every macOS user with IINA installed at version 1.4.3 or earlier. Version 1.4.3 carries the initial patch but still has the bypass described above, so it counts as affected. Updating to 1.4.4 or later 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: update to 1.4.4 or later

The fix is simple: update IINA to 1.4.4 or later. Start by checking your version — with IINA running, open "IINA" → "About IINA" in the menu bar. If it shows 1.4.3 or earlier — including exactly 1.4.3 — you need to update.

Pick one of the following update paths:

One operational note from the maintainers: the in-app automatic update is delivered 24 hours after a release goes live on GitHub. Right after a new version ships, "Check for Updates..." may not show it yet — in that case the official site or Homebrew will get you there directly.

Regardless of version, it also pays to avoid opening video links you were not expecting. Be especially cautious about links starting with iina:// or video links arriving from unknown domains, and 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.

The path from 1.4.3 to 1.4.4 also illustrates why these fixes are hard to get right. A blocklist — rejecting dangerous items by name — fails the moment a single dangerous item is missed. The allowlist that 1.4.4 adopted — accepting only what has been vetted — is the reliable pattern, and for an externally reachable input surface like a URL scheme it is the one that should be used from the start. For macOS users, the practical takeaway is that any app installed outside the Mac App Store (those distributed via DMG or `.app` directly) may register URL schemes, and keeping your everyday apps updated remains the most realistic defense.

Is it being exploited? The situation as of July 23, 2026

Roughly two months after disclosure, as of July 23, 2026, this vulnerability is not listed in the KEV catalog — the list of flaws confirmed to be used in real attacks, maintained by the US government agency CISA — and no reports of it being exploited in the wild have surfaced. No new CVE numbers have been assigned to IINA since the original disclosure either; the additional fix in 1.4.4 is tracked as a continuation of the same CVE-2026-47114, not as a new flaw.

That said, all an attacker needs is to get someone to click a link and press "Open", and the technique is fully documented in the public advisories and the researcher's write-up. With a user base this large, there is no reason to stay on an old version. The current release is 1.4.4, and the maintainers have announced that version 1.5.0, with a redesigned interface, is in the works. Whichever version you end up on, there is exactly one thing to check: whether the number in "About IINA" reads 1.4.4 or higher.

References

• ▸ NVD - CVE-2026-47114 (IINA URL scheme argument injection command execution)
• ▸ GitHub Security Advisory - GHSA-w5xh-98j7-jp5q (IINA official advisory)
• ▸ 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.4 release notes (complete fix)
• ▸ GitHub - IINA v1.4.3 release notes (initial, incomplete fix)
• ▸ GitHub - 1.4.3 patch commit 1e6f432
• ▸ IINA official site