Pre-auth RCE in Apple Screen Sharing: root in 60 seconds thanks to a forgotten error code

Research published on warez.sl0p.foo describes a critical vulnerability in the screensharingd screen-sharing daemon on macOS all the way up to version 26.5 (Tahoe). The problem affects every system with the “Screen Sharing” feature enabled, and it requires neither a password, nor a username, nor any involvement from the victim.

One forgotten register

At the heart of the bug lies a classic error-handling mistake. The daemon reads a four-byte SRP frame length off the network and then validates it. If the length turns out to be too large (≥ 32768), the “frame too large” branch fires — but instead of an error code, the function returns the stale status left over from the previous read operation, i.e. zero. And zero is interpreted by the calling code as “authentication completed successfully.”

As a result, the entire SRP mechanism — key generation, session computation and verification — simply never runs. The server sets the authenticated = 1 flag, sends the client a confirmation and moves on to the main RFB message-processing loop. No key exchange, no cipher negotiation: the connection operates in cleartext, even though the protocol would normally bring up a ChaCha20-Poly1305 layer.

From a byte to a root shell

Next, Apple’s proprietary file-copy protocol (message type 0x22) comes into play, running as root and granting arbitrary file reads and writes. The attack fits into a single TCP connection: the attacker sends an RFB version, security type 36 and one large block of data. Packed inside are two write transactions — a Perl reverse-shell script into /var/tmp/.r and a crontab into /var/at/tabs/root (necessarily with 0600 permissions, otherwise cron will ignore it).

Within a minute cron picks up the job and launches the stock, Apple-signed /usr/bin/perl, which opens a root shell for the attacker. Once triggered, both files self-destruct. The exploit depends on heap layout and succeeds roughly one time in 5–15, so by default it makes up to 20 attempts.

Separately, the authors note a second, independent weakness: the server rejects the public value A == 0, but not A ≡ 0 (mod N), which contradicts RFC 5054 and makes it possible to zero out the shared secret by sending A = N. It is not used in the exploit itself.

The patch and a curious detail

The vulnerability was fixed in macOS 26.6, released on July 27, 2026: the “frame too large” branch now returns a proper non-zero error code. Users who have not updated are advised to simply turn off screen sharing.

The most curious part is the disclaimer: by the authors’ own admission, the entire analysis, PoC and reproduction steps were produced entirely by AI agents on the basis of static analysis and automated testing, with no human involvement. Hence the caveat that the material may contain errors and requires independent verification.

Source: Lobsters