Author: warez.sl0p.foo (advisory autonomously generated and validated by AI coding agents)
Published: 2026-08-01 (correction published 2026-08-02)
Source: https://warez.sl0p.foo/apple-screensharing-rce/
Summary
An advisory published on warez.sl0p.foo describes a pre-authentication flaw in the macOS Screen Sharing daemon (screensharingd) that, according to the authors, allows an unauthenticated network attacker to bypass Secure Remote Password (SRP) authentication and reach the remote framebuffer message loop as root. The report states the issue affects macOS builds up to and including 26.5 (“Tahoe”) when SRP security type 36 is in use, and that it was fixed in macOS 26.6 on 2026-07-27. No CVE identifier is assigned in the advisory. The advisory is described as produced and end-to-end validated by AI agents against a real target (a Mac mini M4 running macOS 26.4.1); a same-week correction (below) materially narrows the real-world impact on default systems.
Technical Details
The advisory attributes the bypass to a frame-length validation error in the SRP handling path. It states that when the daemon processes an SRP frame whose 4-byte length field is 32768 bytes or larger, the code returns a stale success status left over from the preceding 4-byte read rather than an error code. Per the advisory, the caller interprets that leftover zero as “SRP authentication complete,” so the connection proceeds without any cryptographic verification and continues in cleartext into the RFB (Remote Framebuffer) message loop.
The report says that once inside that loop, Apple’s proprietary file-copy protocol (described as message type 0x22) executes with root privileges, providing pre-authentication file read and write primitives across most of the filesystem. The advisory also notes a separate, independent SRP weakness: the server reportedly rejects a client public value of A == 0 but does not reject A ≡ 0 (mod N), which it says could permit a password bypass when A = N. No CVE numbers are provided for either issue, and the affected-version and fix details above are as stated by the source and are not independently confirmed here.
Impact
As described, the primary flaw gives an unauthenticated attacker root-level file read and write on a target that merely has Screen Sharing enabled, with no user interaction required. The advisory claims the original end-to-end chain achieved remote code execution as root and completed in roughly 60 seconds. Reaching code execution depends on System Integrity Protection (SIP) state, which the correction clarifies (see Mitigation). Affected: macOS ≤ 26.5 with SRP security type 36 enabled, per the source.
Mitigation
The advisory says the issue is fixed in macOS 26.6 (released 2026-07-27) and recommends updating immediately, or disabling Screen Sharing where the update cannot be applied. It also recommends keeping SIP enabled as defense-in-depth.
Correction (2026-08-02): the authors state that the original advisory presented the crontab-injection reverse shell as working against a stock macOS install, but that this is not the case — their test target had SIP disabled. With SIP enabled (the default on shipping Macs), the advisory says the authentication bypass and the root file read/write primitives still work, but the write to /var/at/tabs/root is refused and the chain does not reach code execution. The advisory speculates that other paths (for example sudo rules or shell initialization files) might be reached, but the corrected text does not claim a validated end-to-end RCE against a default, SIP-enabled system. Treat the pre-auth root file read/write as the confirmed impact on default systems and the full unauthenticated RCE as demonstrated only with SIP disabled.