Parallels Desktop: Lücke macht jedes Mac-Konto zu Root — Intel-Macs bekommen den Fix nicht

Wer auf dem Mac Windows oder Linux in einer virtuellen Maschine laufen lässt, hat mit hoher Wahrscheinlichkeit Parallels Desktop installiert. Genau dort steckt eine Lücke, die ein gewöhnliches Benutzerkonto ohne Administratorrechte zu Root macht — also zur höchsten Berechtigungsstufe des Mac-Systems selbst, nicht nur der virtuellen Maschine. Entdeckt hat sie das Sicherheitsteam von JFrog, das die Lücke ParaShells getauft und als CVE-2026-90894 mit 7,8 von 10 Punkten bewertet hat.

Der Fehler steckt laut JFrog erst in Parallels Desktop 27 nicht mehr. Das Problem daran: Version 27 läuft ausschließlich auf Macs mit Apple-Chip. Wer noch einen Intel-Mac hat, kann sie nicht installieren — und für die Version 26, auf der Intel-Nutzer bleiben sollen, gibt es nach JFrogs Angaben bislang keinen Fix.

Das Wichtigste in Kürze

• CVE-2026-90894 („ParaShells“): lokale Rechteausweitung in Parallels Desktop für Mac, CVSS 7,8, entdeckt von JFrog.
• Ein normales lokales Konto ohne Adminrechte kann Code als Root auf dem Mac ausführen. Eine laufende VM ist nicht nötig.
• Nicht aus der Ferne ausnutzbar: Der Angreifer muss bereits Code auf dem Mac ausführen — etwa über ein manipuliertes Homebrew-Paket, ein npm-Installationsskript oder ein Konto auf einem gemeinsam genutzten Rechner.
• Nachgewiesen auf Version 26.4.0 (Build 57513) auf Apple Silicon. Ältere Builds hat JFrog nicht geprüft und stuft sie vorsorglich als betroffen ein.
• Fix laut JFrog in Parallels Desktop 27.0.0; aktuell ist 27.0.1. Version 27 setzt Apple Silicon und macOS Sonoma 14.7 voraus.
• Intel-Macs bleiben auf Version 26 — und die hat den Fix laut JFrog nicht, auch nicht das aktuelle 26.4.2. Parallels hat sich bisher nicht geäußert.
• Keine bekannten Angriffe in freier Wildbahn.

Wie die Lücke funktioniert

Parallels Desktop betreibt im Hintergrund einen Dienst namens prl_disp_service, der mit Root-Rechten läuft. Das muss er auch: Er richtet das Netzwerk der virtuellen Maschinen ein, registriert VMs und entpackt sogenannte Appliances, also fertige VM-Pakete. Programme auf dem Mac sprechen mit diesem Dienst über einen Unix-Socket.

Drei Schwächen greifen ineinander. Erstens ist dieser Socket auf dem getesteten System für jeden Prozess beschreibbar — jedes Programm kann sich verbinden. Zweitens prüft der Login-Aufruf nur die Kennung des verbindenden Prozesses, die der Kernel liefert; eine Signatur von Parallels ist nicht nötig, und ein Nicht-Admin-Konto wird akzeptiert. Drittens baut der Dienst beim Installieren einer Appliance den Entpack-Befehl als eine einzige Textzeile zusammen — tar -xf "%1" -C "%2" — und zerlegt sie anschließend mit einer Qt-Funktion wieder in einzelne Argumente.

Der Zielordner der neuen VM ist dabei vom Aufrufer wählbar. Steht in seinem Namen ein Anführungszeichen, endet das Zitat vorzeitig, und alles, was danach kommt, wird zu zusätzlichen Optionen für tar. JFrog nutzte die Option --use-compress-program, mit der tar unter macOS ein externes Programm vorschaltet. Weil tar hier als Root läuft, läuft auch dieses Programm als Root. Im Test schrieb es eine sudo-Regel ohne Passwortabfrage und öffnete eine Root-Shell. Das ist keine klassische Shell-Injection mit Semikolons, sondern eine Argument-Injection: Es wird kein zweiter Befehl eingeschleust, sondern ein bestehender bekommt gefährliche Schalter untergeschoben.

Warum eine lokale Lücke trotzdem zählt

„Nur lokal“ klingt nach Entwarnung, ist es aber auf Entwicklerrechnern nicht. JFrog nennt die typischen Wege, über die fremder Code ohnehin als normaler Nutzer läuft: eine manipulierte Homebrew-Formel, ein npm-Paket mit bösartigem Installationsskript, ein kompromittierter Build-Job — oder schlicht ein zweites, schwach gesichertes Konto auf einem gemeinsam genutzten Mac in Schulung oder Labor. Jeder dieser Wege endet normalerweise bei den Rechten des angemeldeten Nutzers. Mit ParaShells endet er bei Root: Systemsoftware austauschen, Daten anderer Nutzer lesen, sich über launchd dauerhaft einnisten.

Dazu kommt: Der Angriff braucht keine laufende virtuelle Maschine. Es reicht, dass Parallels installiert ist und der Dienst läuft — und der startet auf einer Standardinstallation automatisch beim Systemstart.

Der Fix — und wer ihn nicht bekommt

Nach JFrogs Angaben startet Parallels Desktop 27 den tar-Befehl als feste Argumentliste statt als zerlegte Textzeile; ein Anführungszeichen im Ordnernamen bleibt damit ein Ordnername. Die Zeitangaben sind allerdings widersprüchlich: JFrogs Zeitleiste nennt den 1. September als Tag des Fixes in 27.0.0, laut Parallels‘ eigenen Release Notes erschien 27.0.0 bereits am 25. August und 27.0.1 am 1. September. Wer die aktuelle 27.0.1 (Build 58670) installiert, ist in beiden Lesarten auf der sicheren Seite. Parallels selbst hat zu der Lücke nichts veröffentlicht; die Liste der Sicherheitskorrekturen des Herstellers wurde seit Mai 2025 nicht aktualisiert.

Das eigentliche Problem betrifft Intel-Macs. Parallels hat den Intel-Support mit Version 27 gestrichen und begründet das mit Apples Fahrplan: macOS 26 Tahoe ist die letzte Version für Intel-Hardware, macOS 27 läuft nur noch auf Apple Silicon. Intel-Nutzer sollen auf Parallels Desktop 26 bleiben, für das der Hersteller am 25. August „künftige Sicherheits- und Wartungsupdates“ zusagte. Drei Wochen später wurde ParaShells öffentlich — und JFrog schreibt ausdrücklich, dass die 26er-Linie einschließlich der aktuellen 26.4.2 vom 8. September die Änderung am Entpack-Befehl nicht enthält. Ob und wann der Fix dort ankommt, hat Parallels nicht gesagt.

Für Intel-Macs wiederholt sich damit ein Muster, das wir schon bei Apples eigenen Sicherheitsupdates gesehen haben: Die Hardware läuft noch Jahre, die Software-Pflege dünnt aus.

Prüfen, ob der eigene Mac betroffen ist

Zwei Befehle im Terminal genügen, beide verändern nichts. Der erste zeigt die installierte Version, der zweite die Rechte des Dienst-Sockets:

defaults read "/Applications/Parallels Desktop.app/Contents/Info" CFBundleShortVersionString
ls -l /var/run/prl_disp_service.socket

Zeigt der zweite Befehl srwxrwxrwx und der erste eine Version der 26er-Reihe, sollte der Mac laut JFrog als angreifbar gelten, bis ein gefixter Build bestätigt ist. Beide Befehle zeigen nur die Exposition — nicht, ob die Lücke bereits ausgenutzt wurde.

Was jetzt zu tun ist

• Apple-Silicon-Mac: auf Parallels Desktop 27.0.1 oder neuer aktualisieren.
• Intel-Mac: Es gibt derzeit keinen Build, den JFrog als gefixt bezeichnet. Bis dahin: lokale Konten auf das Nötigste beschränken, keine fremden Nutzer auf dem Rechner, und Software-Quellen wie Homebrew und npm mit Bedacht wählen. Wer Parallels nur selten braucht, kann den Dienst bis zum nächsten Einsatz abschalten.
• Verwaltete Flotten: Update-Richtlinien prüfen. Parallels warnt, dass eine Regel, die neue Hauptversionen automatisch verteilt, auf Intel-Macs Version 27 zu installieren versucht und scheitert.
• Nach dem Update gilt: Ein Angreifer, der bereits Root hatte, kann sich über launchd festgesetzt haben. Das Update räumt das nicht auf. Wer einen Verdacht hat, prüft die LaunchDaemons und LaunchAgents.

Einordnung

Die Lücke selbst ist ein Lehrbuchfall — ein Root-Dienst, der Befehle als Text zusammenklebt, ist eine der ältesten Fehlerklassen überhaupt, und die Argument-Injection über tar ist elegant, aber nicht neu. Bemerkenswert ist der Umgang damit: ein Hersteller, der schweigt, eine Fix-Version, die ein Teil der Kunden nicht installieren kann, und eine Zusage für Sicherheitsupdates der alten Linie, die drei Wochen später auf die Probe gestellt wird. Für Parallels ist das die Gelegenheit, das Versprechen einzulösen. Für Intel-Mac-Nutzer ist es ein weiteres Signal, wie lange sie sich noch auf ihre Plattform verlassen können.

Häufige Fragen

Sind meine virtuellen Maschinen betroffen?

Nein, die Lücke liegt auf der Mac-Seite. Gefährdet ist das macOS-System, auf dem Parallels läuft — nicht Windows oder Linux in der VM.

Kann jemand die Lücke über das Internet ausnutzen?

Nein. Der Angreifer braucht bereits laufenden Code auf dem Mac als normaler Nutzer. Das ist die Hürde — und gleichzeitig eine, die über manipulierte Pakete oder Skripte häufiger fällt, als man denkt.

Ich habe einen Intel-Mac. Was soll ich tun?

Abwarten, ob Parallels den Fix in Version 26 nachreicht, und bis dahin lokale Konten und Software-Quellen streng halten. Wer Parallels selten nutzt, kann es bis dahin deinstallieren oder den Dienst deaktivieren.

Ist die App-Store-Version auch betroffen?

JFrog schreibt, die App-Store-Ausgabe starte ihre Dienste möglicherweise anders, beschreibt das zugrunde liegende Risiko aber als dasselbe. Eine Entwarnung ist das nicht.

Quellen: Advisory und Blogbeitrag von JFrog Security Research (15.09.2026), Berichterstattung von The Hacker News und Help Net Security (16.09.2026), CVE-Eintrag CVE-2026-90894, Release Notes von Parallels. Abgerufen am 16.09.2026. Eine Stellungnahme von Parallels lag zum Zeitpunkt der Veröffentlichung nicht vor.