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. 

  The disclosure of a new hardware-level exploit has raised new concerns about the long-term security implications of immutable silicon vulnerabilities across Apple's entire ecosystem. Paradigm Shift researchers have revealed usbliter8, a working SecureROM exploit compromising the boot chain of Apple A12 and A13 processor-based devices.  In 2019, checkm8 emerged as the first publicly released unpatched attack on these chip generations. By exploiting a flaw within the BootROM, the code that runs before iOS and all higher security controls, the exploit is able to bypass protections at the earliest stage of the initialization process. Physical access, a USB connection, and manual placement of the device into DFU mode are required to perform the attack, but the significance lies in the vulnerability itself. This vulnerability is not able to be remedied by updating firmware, updating operating systems, or restoring devices since it occurs in silicon rather than software. In addition to the niche jailbreak development impacted by this disclosure, Apple hardware that is still supported, including iPhones, iPads, Apple Watches, and other Apple devices, now carry a permanent hardware weakness that can be exploited throughout the device's operational lifetime.  Along with presenting a notable research discovery, USBliter8 also presents a significant hardware security incident due to the permanent nature of the vulnerability exploited by it. The affected SecureROM code is therefore physically embedded within the processor while the device is being manufactured, placing it beyond Apple's control once the device leaves the factory. This is in contrast to conventional vulnerabilities that can be mitigated by updating firmware or operating systems.  During a coordinated engagement with Apple Product Security on June 18, 2026, researchers revealed the exploit and accompanying proof of concept, demonstrating that a successful attack can be carried out in less than two seconds before Apple's trusted boot sequence takes over. There remains a strict physical access requirement for the attack: a target device must be manually placed into Device Firmware Update (DFU) mode and connected to an RP2350-based microcontroller platform using USB. Nevertheless, there is a considerable range of hardware impacted.  Publicly supported targets include devices built on Apple's A12 and A13 application processors, in addition to the S4 and S5 systems-on-chip used across Apple Watch and HomePod products. There are a number of products, such as the iPhone XS, iPhone XR, iPhone 11, two-generation iPhone SE, multiple iPad models, Apple Watch Series 4 and 5, the first-generation Apple Watch SE, HomePod mini, and others, which continue to see active deployment.  Research indicates that support for A12X and A12Z processors may be technically achievable in the future, but this has not yet been implemented. The architectural differences in USB memory handling do not seem to affect devices based on A11 silicon, while A14 and newer generations appear to be immune due to improved DART configuration and memory isolation controls within the boot environment. The disclosure also highlights an aspect of modern device security that is seldom encountered: there are some vulnerabilities that are beyond the reach of all software-based defense mechanisms available to vendors as well as users. The vulnerability can not be eliminated by iOS updates, firmware revisions, factory restores, or standard hardening measures since the vulnerability lies within immutable SecureROM code. It remains imperative to maintain the latest software versions, enforce strong authentication controls, and adhere to sound security practices to protect against conventional threats; however, those measures do not alter the hardware trust anchor targeted by USBliter8.  In identifying the most practical long-term mitigation strategy for organizations and individuals seeking to reduce exposure, Paradigm Shift identified migration to devices utilizing A14 or newer silicon. While Apple has not publicly addressed the research as of publication, the researchers stated that Apple Product Security has been notified and disclosure procedures have been completed before technical details and exploit code can be released. There is a great deal of variation in the security implications associated with the various operating environments in which affected devices are used.  For the average consumer, the requirement for physical possession, DFU mode access, and specialized hardware greatly narrows the scope of potential exploitation. Individuals who operate under elevated threat conditions, including journalists, corporate executives, activists, government employees, and others whose devices may be seized, inspected, or held for extended periods, face a significantly different risk profile. In such scenarios, a compromised device based on A12, A13, S4, or S5 could be affected by persistent boot-level intrusions that are anchored underneath the operating system itself, even after software updates are applied. Thus, device lifecycle planning now includes security considerations instead of just procurement, with the newer A14-generation hardware and later platforms posing the most obvious route to avoiding this type of exposure.  In addition to the immediate technical accomplishments, researchers are closely tracking whether usbliter8 follows a similar path to checkm8 that was established nearly seven years ago. Along with the research, a proof-of-concept code was released that gained significant attention from the security community. It quickly gained hundreds of GitHub stars and indicated strong interest from researchers and developers alike. It is widely anticipated that jailbreak-focused tools will emerge in the near future, but the more consequential question is whether the exploit will evolve into a mature hardware research and forensic framework for A12 and A13 devices. Ultimately, Checkm8 has become the primary tool for examining and interacting with older Apple hardware in a manner previously not possible for defenders, researchers, and forensic practitioners.  While USBliter8 has not yet reached that level, its publication provides the first public insight into a generation of Apple silicon which, until now, has been largely beyond the reach of unpatched SecureROM exploits. With the advent of USBliter8, we are reminded that not all security risks originate with software, and not all can be resolved through patching.  By exposing a hardware-rooted vulnerability that remains widely deployed, this research contributes to a heightened awareness of the long-term security implications of silicon-level trust boundaries. However, organizations and individuals responsible for sensitive data should reassess their device custody practices, hardware refresh strategies, and exposure to high-risk environments as a result of the exploit.  Usbliter8 remains a significant landmark in Apple security research and is being examined by the security community in order to fully comprehend its impact. It demonstrates how important it is not only to secure the software on a device, but also the device itself.