CVE-2026-65400 — macOS-Bildschirmfreigabe: Pre-Auth-Root-Dateilesen (Read-only-PoC)

Read-only-Proof-of-Concept. Er demonstriert die Authentifizierungsumgehung, indem er eine Datei liest, die nur Root lesen kann, von einem verwundbaren Host. Er schreibt nichts auf das Ziel: kein LaunchDaemon, keine Shell-Startdatei, keine Crontab, keine RCE-Kette.

Lauf gegen einen Mac, der mir gehört (macOS Tahoe 26.5.2, ungepatcht). Seriennummer geschwärzt.

Zusammenfassung

screensharingd — der Daemon hinter macOS Bildschirmfreigabe / Apple Remote Management (TCP 5900) — kann dazu gebracht werden, eine nicht authentifizierte Verbindung als authentifiziert zu behandeln. Kein Benutzername, kein Passwort, keine Interaktion auf dem Ziel.

Der native Authentifizierungspfad des Daemons verwendet SRP (Secure Remote Password). Sein Frame-Längen-Validator liefert einen veralteten Erfolgsstatus zurück, sodass die Verbindung als authentifiziert markiert wird, bevor irgendeine Anmeldeinformation geprüft wurde. Apples Formulierung im Advisory — „improved state management" — passt dazu: Die Kryptografie wurde nie gebrochen, sondern die sie umgebende Zustandsmaschine.

Hinter diesem Tor angekommen läuft die Sitzung im Klartext weiter, und die privilegierten Dateikopie-Helfer (SSFileCopySender / SSFileCopyReceiver) besitzen vollen Festplattenzugriff (Full Disk Access). Das ergibt Pre-Auth beliebiges Lesen und Schreiben von Dateien als Root unter Umgehung von TCC — und von dort ist Remote-Code-Ausführung nur einen LaunchDaemon oder eine Shell-Startdatei entfernt.

Pre-Auth. Remote. Root. Standardkonfiguration — sobald die Bildschirmfreigabe aktiviert ist.

Betroffene Versionen

Erfordert, dass Bildschirmfreigabe / Remote Management aktiviert und erreichbar ist. Das Härten der Konten hilft nicht — das Entfernen von Benutzern, das Deaktivieren von Legacy-VNC und das Rotieren von Passwörtern bieten keinen Schutz, weil der Fehler vor der Authentifizierung erreicht wird.

Exploitation-Status

Das ist nicht theoretisch. Es wird in freier Wildbahn ausgenutzt.

In freier Wildbahn beobachtete Aktivitäten gegen den im Internet exponierten Port 5900: abgelegter SSH-Public-Key für Persistenz, gelöschte Logs und Shell-Historie, geänderte Paketfilter-Regeln sowie der eingesetzte XMRig 6.26.0-Monero-Miner.

Verwendung

Python 3, nur Standardbibliothek. Keine Abhängigkeiten.

python3 poc_screensharing.py <IP>                          # reads /etc/sudoers
python3 poc_screensharing.py <IP> /etc/passwd
python3 poc_screensharing.py <IP> /etc/master.passwd -r 50

-p, --port      target port (default 5900)
-u, --user      username sent in the SRP step-1 frame (default root)
-r, --retries   retry count (default 25) — the bug is heap-racy
-t, --timeout   socket timeout in seconds (default 8.0)

Hinweise zur Zuverlässigkeit

• Der Bug ist race-bedingt. Er hängt vom Heap-Layout ab und schlägt nicht bei jedem Versuch zu; deshalb wiederholt der PoC. Wenn es in 25–50 Versuchen nicht klappt, versuche es später erneut.
• Der Daemon drosselt. Wer ihn mit Requests bombardiert, wird gedrosselt — warte ~1 Minute.
• Gepatchte Hosts werden erkannt, nicht wiederholt. Ein SecurityResult != 0 oder eine Sicherheitstyp-Liste ohne SRP (36) beendet die Schleife und meldet den Host als nicht verwundbar.

Erkennung

Endpoint-Security-Ereignis ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH:

• authentication_type: SRP ohne RSA-Komponente — legitime Sitzungen melden RSA-SRP. Das ist der Indikator mit dem höchsten Signalwert.
• Sitzungs-Benutzername root — das Konto ist unter macOS standardmäßig deaktiviert.
• SSFileCopySender, der mit UID/GID 0 80 läuft und während einer Bildschirmfreigabe-Sitzung Systempfade über _LOOKUP / _OPEN / _STAT / _CLOSE berührt.

Gegenmaßnahmen

1. Patchen auf 26.6.1 / 15.7.9 / 14.8.9. Das ist die einzige echte Lösung.
2. Wenn du nicht patchen kannst, deaktiviere Bildschirmfreigabe / Remote Management vollständig.
3. Setze TCP 5900 niemals dem Internet aus — mit oder ohne dieses CVE.

Credits

Die Forschung stammt nicht von mir. Dieses Repository ist eine Reproduktion und ein Write-up.

• Pedro Vilaça (fG!, @osxreverser) — ursprünglicher Pre-Auth-Bug
• bl4sty (navi_the_clown) — Wire-Format und Ausnutzungstechnik
• bynar.io — CVE-2026-43760
• Huntress (Bryan Masters, Stuart Ashenbrenner) — Leitfaden zur Erkennung

Rechtliches

Nur für autorisierte Sicherheitstests, defensive Validierung und Schulungszwecke. Führe es gegen Systeme aus, die dir gehören oder für die du eine ausdrückliche schriftliche Genehmigung zum Testen hast. Der Screenshot oben zeigt einen Mac, der mir gehört. Die Verwendung gegen Systeme, die du nicht kontrollierst, ist in den meisten Rechtsordnungen illegal. Der Autor übernimmt keine Haftung für Missbrauch.

Veröffentlicht erst, nachdem der Hersteller-Patch öffentlich verfügbar war, und bewusst auf eine Lese-Primitive beschränkt.

Deutsch

screensharingd, der Daemon der macOS-Bildschirmfreigabe (TCP 5900), kann sich als authentifiziert behandeln lassen, ohne dass jemand Anmeldedaten vorgelegt hat. Sein Frame-Längen-Validator im SRP-Fluss liefert einen veralteten Erfolgsstatus zurück, sodass die Verbindung vorschnell als authentifiziert behandelt wird. Apple beschreibt es als „improved state management": Die Kryptografie wurde nie gebrochen, sondern die sie umgebende Zustandsmaschine.

Von dort an läuft die Sitzung im Klartext weiter, und die privilegierten Dateikopie-Helfer (SSFileCopySender / SSFileCopyReceiver) haben vollen Festplattenzugriff (Full Disk Access), was beliebiges Lesen und Schreiben als Root ermöglicht und TCC umgeht — und von dort bis zur Remote-Code-Ausführung ist es nur ein LaunchDaemon entfernt. Pre-Auth, remote, Root und in der Standardkonfiguration.

Dieser PoC ist read-only: Er demonstriert den Bypass, indem er eine Datei liest, die nur Root lesen kann, und schreibt nichts auf das Ziel.

Was zu tun ist: auf 26.6.1 / 15.7.9 / 14.8.9 aktualisieren — das ist die einzige echte Lösung. Wenn das nicht möglich ist, deaktiviere die Bildschirmfreigabe. Passwörter rotieren oder Konten löschen nützt nichts, denn der Fehler wird vor der Authentifizierung erreicht. Und Port 5900 sollte nicht dem Internet ausgesetzt sein.

Verwende es nur gegen Geräte, die dir gehören, oder mit schriftlicher Genehmigung.