If you think a VNC password is a low-risk convenience feature, this one's for you. 🚨
CVE-2026-43760 is a logic bug in macOS screensharingd — the daemon behind Screen Sharing and Remote Management. It affects Macs with the legacy "VNC viewers may control screen with password" option enabled, a setting many admins use for cross-platform remote access since it skips the need for a local macOS account or Apple ID.
The root cause: file-copy helpers SSFileCopySender and SSFileCopyReceiver kept running as root — even for VNC sessions with no real macOS identity behind them.
The attack chain researchers demonstrated:
- Connect via legacy VNC password only — no macOS account required
- Abuse the file-copy write primitive to drop a rogue file into
/private/etc/sudoers.d/ - That file grants passwordless
sudoto a non-admin account - One command later → full remote root shell
No memory corruption. No ROP chains. Just intended functionality abused against its own trust assumptions — a textbook confused-deputy flaw.
Apple scored it CVSS 5.5. Independent researchers scoring the complete chain (root read + root write + command execution) put it as high as 8.8.
🔑 Key takeaway: rotating your VNC password does NOT fix this. It's an authorization flaw, not a weak-credential issue.
✅ Patched in macOS Tahoe 26.6 & Sonoma 14.8.8 (July 27, 2026)
✅ Disable legacy VNC authentication
✅ Audit /private/etc/sudoers.d/ for unexpected files
✅ Never expose port 5900 directly to the internet
Full write-up with detection indicators, Terminal commands, and a hardening checklist:
🔗 https://www.xpert4cyber.com/2026/08/macos-screen-sharing-vulnerability-cve-2026-43760.html
Would love to hear if anyone here has run into legacy VNC configs like this in the wild. 👇
Top comments (0)