Security researchers at JFrog disclosed the vulnerability on Tuesday, assigning it the identifier CVE-2026-90894 and the nickname "ParaShells." JFrog rates the flaw 7.8 out of 10 on the CVSS severity scale. The bug does not allow remote attacks over a network. An attacker needs code already running on the machine as an ordinary local user, but once that condition is met, exploitation does not require administrator rights, a signed Parallels client, or an active virtual machine.
What Parallels Desktop Is and Why This Matters
Parallels Desktop runs Windows and Linux inside virtual machines on a Mac. It installs a background service called prl_disp_service that runs as root, because its work includes setting up host networking and unpacking virtual machine packages. The flaw is on the Mac side of the product, so the machine at risk is the Mac itself rather than the virtual machines on it.
That distinction is important. Many Mac users who run Parallels think of security risks as something that might affect the virtual Windows or Linux environment inside. ParaShells skips the guest entirely and compromises the Mac host directly.
How the Attack Works
The exploit chains together three separate weaknesses, none of which would be enough on its own.
The vulnerability combines three security weaknesses: a world-writable Unix socket, weak local client authentication, and argument injection during appliance extraction. On a default installation, prl_disp_service listens through /var/run/prl_disp_service.socket. JFrog researchers found that the socket could have 0777 permissions, allowing any local process to connect.
The login call that follows, PrlSrv_LoginLocal, checks only the credentials the kernel reports for the connecting process. It needs no Parallels code signature and works for an account that is not an administrator.
The third piece is where things get technically interesting. To install a virtual machine appliance, the service builds its unpack command as one line of text, tar -xf "%1" -C "%2". It then splits that text back into separate arguments using Qt's QProcess::splitCommand. The caller chooses part of that text, because it picks the folder the new virtual machine goes into. A double quote inside the folder name closes the quoting early, so whatever the attacker put after it becomes extra options for tar instead of part of a path.
The option JFrog used was --use-compress-program, which tells macOS tar to hand the archive to another program first. Because tar is running as root here, that program runs as root too. JFrog's test script wrote a passwordless sudo rule and opened a root shell.
In the lab demonstration, the sequence plays out in seconds: connect to the socket, send a crafted appliance install request with a poisoned directory path, and watch the compression program execute as uid 0. JFrog assembled this into a one-liner but has chosen not to publish that script, releasing the technical breakdown without the ready-to-fire weapon.
Yuval Moravchick, JFrog's vulnerability research team lead, explained: "The chain is short: A world-writable Unix socket, a login that trusts peer credentials rather than a Team ID, and an appliance unpack path that builds tar arguments using Qt string splitting. A quote in the parent path injects --use-compress-program=, and macOS tar runs the attacker's script as uid 0."
Who Is Most at Risk
The danger is highest on developer laptops, where a single poisoned Homebrew formula or malicious npm preinstall script can go from local user to full control, and on shared university and corporate machines that have many local accounts.
The threat model here is real and not hypothetical. Software developers routinely run third-party tools through package managers like Homebrew or execute npm scripts from projects they pull from the internet. Every one of those code paths represents a potential entry point for an attacker who knows the machine has Parallels installed. On a shared training lab or university computer lab Mac with a dozen local accounts, a single weak password or compromised student account is all it takes.
"From root, the attacker can replace system software, read other users' data, and persist via launchd," Moravchick noted. That last point about launchd persistence is particularly concerning because an attacker who establishes root access through this chain can survive a reboot by registering their own background processes with macOS's system daemon manager.
JFrog also confirmed no virtual machine needs to be actively running. The vulnerable service, prl_disp_service, starts automatically via a launch daemon at load, runs as root, and exposes the socket regardless of whether any VM is open. Simply having Parallels Desktop installed is enough to create the exposure.
The Patch Is Out, With a Catch
JFrog reported CVE-2026-90894 to Parallels maker Alludo, which fixed it in Parallels Desktop v27.0.0, released at the beginning of September 2026. The fix is real, but getting to it is not straightforward for a meaningful portion of Parallels' user base.
Parallels Desktop 27 needs a Mac with an Apple silicon chip. Its system requirements list Apple silicon only for the processor and macOS Sonoma 14.7 or newer for the operating system. On earlier releases of macOS, including Ventura 13, the installer sets up an older version of the product instead. Parallels removed Intel Mac support in version 27 and says the change follows Apple's plans rather than its own.
For Intel Mac users, the situation is murky. Intel users are told to stay on Parallels Desktop 26. "Parallels Desktop 26 fully supports Intel-based Mac computers today, and that will not change," the company wrote on 25 August, three weeks before this flaw became public, adding that Intel users can keep using version 26 and "expect future security and maintenance updates."
The problem is that according to JFrog, "Hosts that stay on the 26.x line, including 26.4.2, do not have that extract change." JFrog does not say it tested 26.4.1 or 26.4.2, and its writeup says it did not check older builds.
Parallels has not published a statement about CVE-2026-90894, and its list of security fixes, which maps each flaw to the version that repairs it, has not been reviewed since May 2025 and does not include this one. That leaves Intel Mac users running Parallels in a difficult position: a confirmed flaw, a fix that requires hardware they do not have, and no public acknowledgment from the vendor about plans for their platform.
The release notes for Parallels Desktop 26.4.2, which shipped on September 8, describe a single change related to Enterprise edition deployment and say nothing about a security fix for the extract path.
What Organizations Should Do Now
JFrog's immediate guidance comes in three parts: find every Mac in your environment running Parallels Desktop, restrict who can log in to those machines locally, and upgrade to version 27.0.0 or later where possible.
Two commands can confirm exposure without making any changes to the system. Running defaults read "/Applications/Parallels Desktop.app/Contents/Info" CFBundleShortVersionString reports the installed version, and ls -l /var/run/prl_disp_service.socket shows the socket permissions. JFrog says a socket showing srwxrwxrwx on a build at or near 26.4.0 should be treated as exposed until a patched build is confirmed.
Administrators using device management to push updates should check version rules before pushing anything. Parallels warns that a policy which sends out new major versions automatically will try to install version 27 on Intel Macs and fail.
One more complication: none of the published material says whether installing a fixed build removes access an attacker has already taken. JFrog notes that an attacker who reaches root can keep a foothold through launchd, which a product update would not clear. For any machine where compromise is suspected, an update alone is not enough.
