Parallels Desktop is virtualization software that lets a Mac run Windows or Linux inside a virtual machine. Security firm JFrog just disclosed a flaw in it, named ParaShells, that lets a regular, non-admin user account take full root control of the Mac itself, not just the virtual machine inside it. Root is the highest level of access on a Mac, and normally only an administrator can reach it. Parallels has shipped a fix, but it only works on newer Mac hardware, leaving a large group of users without a real path to safety.
What Is the ParaShells Vulnerability
ParaShells is a local privilege escalation bug, tracked as CVE-2026-90894. In plain terms, it lets an attacker who already has low-level access to a Mac jump straight to root, without a password and without admin rights.
| Detail | Value |
|---|---|
| Name | ParaShells |
| CVE ID | CVE-2026-90894 |
| CVSS Score | 7.8 (High) |
| Type | Local privilege escalation |
| Attack vector | Local only, no network access needed |
| Component | prl_disp_service background process |
| Fixed in | Parallels Desktop 27.0.0 / 27.0.1 |
| Affects | All versions before 27.0.0 |
The flaw lives inside prl_disp_service, a background process that Parallels Desktop runs with root privileges to manage networking and unpack virtual machine appliance files. JFrog found that this service listens on a world-writable socket, meaning any program running under any local account, admin or not, can talk to it directly.
When a user installs a VM appliance, the service builds an unpack command using tar -xf "%1" -C "%2", then splits that string into arguments with Qt’s QProcess::splitCommand function. Because the destination path in that command comes from user input and isn’t sanitized, an attacker can insert a double quote to end the path early and tack on extra tar flags. Using the --use-compress-program flag, an attacker gets tar to launch an arbitrary script, and since tar runs as root here, that script runs as root too.
JFrog confirmed a working proof of concept that plants a passwordless sudo rule and opens a root shell. The only requirement is that the attacker already has some code running under a regular user account. A few realistic ways that happens:
- A malicious Homebrew formula
- A poisoned npm install script
- A compromised build job or CI step
- A single weak local account on a shared machine
Who Is Most at Risk From This Vulnerability
Developer laptops and shared lab machines carry the highest risk here. Engineers routinely run installers, build scripts, and third-party packages under their own non-admin accounts, and any one of those could carry malicious code without obvious warning signs. On a Mac with Parallels Desktop installed, that low-privilege compromise becomes a full root compromise the moment the exploit runs.
- Developer machines: a single bad install script can hand over the whole Mac, not just a sandboxed VM.
- Shared lab or training computers: one weak student or guest account exposes every other account on that machine.
- Anyone using Parallels day to day: no admin rights are required on either side of the attack.
With that risk in mind, the next question is simple: is your version of Parallels Desktop exposed, and if so, what can you do about it.
Which Parallels Desktop Versions Are Vulnerable
Every Parallels Desktop release before 27.0.0 carries this flaw.
| Version | Status |
|---|---|
| Before 27.0.0 | Vulnerable |
| 27.0.0 | Fixed |
| 27.0.1 (build 58670) | Fixed |
JFrog tested and confirmed the exploit on version 26.4.0, build 57513, running on an Apple Silicon Mac. The advisory treats any build with the same appliance-install command template and world-writable socket as exposed, even if JFrog didn’t test it directly.
The Fix Is in Version 27, But Not Everyone Can Install It
Parallels patched the flaw starting with Parallels Desktop 27.0.0, and the follow-up release 27.0.1 (build 58670) also includes the change. JFrog’s advisory and the official CVE record both list 27.0.0 as the first safe version.
The catch is hardware support:
| Mac Type | Can Install Version 27? | Status |
|---|---|---|
| Apple Silicon (M1 and later) | Yes | Can get the fix |
| Intel-based Mac | No | Stuck on vulnerable 26.x line |
Intel-based Macs cannot install version 27 at all, because Apple’s own macOS 27 release dropped Intel support, and Parallels built version 27 to match it. Anyone still running an Intel Mac is locked into the 26.x line, which JFrog confirms does not include the fix, even in the latest 26.4.2 build.
How to Check and Fix It on Apple Silicon Macs
If your Mac uses an Apple Silicon chip (M1, M2, M3, or newer), updating closes the hole entirely.
- Open Parallels Desktop and check for updates, or download the latest installer directly from Parallels.
- Confirm you’re on build 27.0.1 (build 58670) or newer, since this build is confirmed to carry the fix.
- Restart the Mac after installing to make sure the updated
prl_disp_serviceprocess is running.
Updating is not an option for every Mac, though. Anyone on Intel hardware is locked out of version 27 entirely, so the approach below is different.
What to Do If You’re Stuck on an Intel Mac
Since there’s no patched version available for Intel hardware, the fix has to come from limiting exposure rather than updating the software.
- Restrict the Mac to trusted user accounts only, since the attack requires a local account to begin with.
- Avoid running unreviewed scripts, Homebrew formulas, or npm install hooks on any Mac with Parallels Desktop installed, since these are realistic ways an attacker’s code ends up running locally.
- Watch for unexpected changes to
/etc/sudoersor unusual child processes spawned byprl_disp_service, both of which point to this exact attack pattern. - On shared machines, such as lab or training computers with several local accounts, treat every account as a potential entry point until the underlying Mac itself is retired or upgraded to Apple Silicon.
Frequently Asked Questions
Does ParaShells work over the network?
No. The attack requires code already running locally on the Mac under a standard user account. It cannot be triggered remotely.
Do I need a virtual machine running to be at risk?
No. JFrog’s testing shows a standard Parallels Desktop install with the background service running is enough. No VM needs to be active.
Is there an official workaround from Parallels?
Parallels has not published a workaround or a statement about this specific vulnerability. The only confirmed fix is upgrading to version 27.0.0 or later, which is limited to Apple Silicon Macs.
Will Intel Macs ever get a fix?
There’s no confirmed timeline. Parallels has said it will keep releasing security and maintenance updates for the 26.x line that Intel Macs are stuck on, but it has not confirmed whether a fix for this specific flaw is coming to that line. Until it does, the mitigation steps above are the only real protection for Intel users.
