Apple’s built-in Screen Sharing service is supposed to expose only a login prompt to the network. Instead, a subtle mistake in how it handles one oversized authentication message can allegedly skip authentication altogether and drop an attacker straight into the server’s normal message-processing loop.
According to the published technical analysis, the flaw affects the SRP authentication implementation used by screensharingd. Rather than rejecting an oversized authentication frame, the daemon reportedly returns a stale success value left over from an earlier network read. The caller interprets that zero return value as “authentication completed successfully” and proceeds as if the user had already logged in.
That distinction matters because the rest of the connection is then processed as ordinary Screen Sharing traffic. No password verification, no session key establishment, and no encrypted session are ever created. The entire connection continues in cleartext despite the protocol advertising authenticated encryption.
The report attributes the problem to a tiny logic error in the authentication routine. A four-byte frame length is read from the network, converted from big-endian format, and checked against a size limit. When the length exceeds that limit, the error path is expected to return a failure code. Instead, it reportedly copies the success status from the previous read operation and exits.
From the server’s perspective, authentication has succeeded even though the Secure Remote Password exchange never finished.
Once past that point, Apple’s proprietary file-copy protocol becomes accessible. The analysis describes two powerful capabilities exposed by this interface:
- reading arbitrary files as root;
- writing arbitrary files as root with attacker-controlled contents and permissions.
Those primitives are enough to build a complete remote compromise. The demonstrated proof of concept writes two files during a single TCP connection: a small reverse-shell payload and a root crontab entry that executes it. Because cron is enabled by default on the tested system, the payload is launched automatically within roughly one minute, yielding a root shell.
One particularly interesting aspect of the report is that the exploit never attempts to defeat cryptography. Instead, it avoids cryptography entirely.
The Screen Sharing protocol normally derives encryption keys only after the SRP exchange successfully completes. Since the authentication state machine is reportedly skipped, the key derivation and cipher initialization routines are never reached. No session keys are generated, no proof is verified, and the encrypted transport layer is never installed.
The report also points out a second, independent weakness in the server’s SRP validation. Instead of checking whether the client’s public value is congruent to zero modulo the protocol’s prime, the implementation reportedly rejects only the literal value zero. The author notes that this issue was not used in the demonstrated exploit but could represent another security problem on its own.
The affected service is Apple’s built-in Screen Sharing daemon (screensharingd), which runs with root privileges. The attack requires only that Screen Sharing be enabled on the target machine. No username, password, or user interaction is required according to the published analysis.
The reported testing environment was a Mac mini M4 running macOS 26.3, and the exploit transcript shows successful compromise of a system running macOS 26.4.1. The report states that Apple addressed the frame-length validation issue in macOS 26.6 by ensuring the oversized-frame path returns a proper error instead of the stale success status.
For administrators, the practical advice is straightforward: install macOS 26.6 or later, or disable Screen Sharing on systems where it is not needed.
The incident is also a reminder of how security-critical software can fail because of surprisingly small implementation mistakes. In this case, the difference between rejecting a malformed packet and accepting it reportedly comes down to propagating the wrong return value through a single error path. That tiny control-flow mistake is enough to bypass the entire authentication mechanism and expose functionality that was never meant to be reachable before login.