Apple's macOS Screen Sharing Flaw Is Being Exploited in the Wild

[MacRumors]

The screen sharing flaw that Apple rushed out a fix for earlier this month has already been exploited in the wild, according to the Netherlands' National Cyber Security Center (NCSC-NL).

On August 6, Apple released macOS Tahoe 26.6.1, an update to the ‌macOS Tahoe‌ operating system that came out last year. The update came a little over a week after Apple released macOS Tahoe 26.6.

In its security support document, Apple said that the update addressed a vulnerability that could allow an attacker to authenticate to Screen Sharing without valid credentials – in short, a bad actor could view a user's Mac screen and remotely take control of their keyboard and mouse. It appears however that hackers have already been taking advantage of the flaw.

As first reported by ArsTechnica, the NCSC-NL said that it had been notified of abuse of the vulnerability, "observed on multiple systems on which port 5900 was accessible from the internet." The reason is that when screen sharing is enabled, macOS's firewall intentionally exposes this port.

"In all these cases, root had been accessed on the affected system and a Monero crypto miner had been placed," the NCSC-NL added. In other words, a targeted Mac's resources are used to mine cryptocurrency.

When pushing the fix – which was also included in macOS Sonoma 14.8.9 and macOS Sequoia 15.7.9 – Apple said it had addressed the authentication issue with "improved state management." Users who have not updated their Macs should do so as soon as possible. Even for those who have updated, use of a VPN is also recommended when screen sharing is active.

If you're not sure if your macOS version is up-to-date, you can check by going into your Mac's System Settings and selecting General ➝ Software Update.

Article Link: Apple's macOS Screen Sharing Flaw Is Being Exploited in the Wild

 

[vegetassj4]

Thank goodness for hardware firewalls. However, if one connected to a public LAN that didn't isolate each computer......🧐

 

[phenste]

personal alternative: never installing Tahoe to begin with

 

[jchap]

personal alternative: never installing Tahoe to begin with

The fix was also required and issued for Sonoma and Sequoia; it is not particular to Tahoe.

 

[kemal]

How vulnerable is a computer behind a cable modem, etc. with a local IP address (10.0.*.*, 192.168.*.*)?

 

[MilaM]

How vulnerable is a computer behind a cable modem, etc. with a local IP address (10.0.*.*, 192.168.*.*)?

I would like to know that too. Most internet routers should block incoming connections from the Internet by default. Unless you explicitly forward all (or selected) ports to your Mac of course. But the article above is very not clear about that.

 

[StuBeck]

How vulnerable is a computer behind a cable modem, etc. with a local IP address (10.0.*.*, 192.168.*.*)?

Likely not very vulnerable, but it's impossible to tell because there can be lots of different configurations. A cable modem from early 2010s will have worse security than one made this year most likely. What they block will also be different.

Turning off screen sharing will fix it immediately, as there aren't reports that this is turning on the service, just actively exploiting one that's turned on.

 

[chucker23n1]

observed on multiple systems on which port 5900 was accessible from the internet.

I wonder how many people that affects in practice. At home, you'll generally have a router with NAT, so you'd have to explicitly open the port. At colleges, workplaces, etc., there would be a firewall.

Some people might have their modem directly connected, but that seems rare these days.

The fix was also required and issued for Sonoma and Sequoia; it is not particular to Tahoe.

And may affect older macOS versions as well (I haven't seen anything about someone checking); it's just that Apple no longer provides security releases for those.

 

[maika1305]

Where are the keyboard warriors shouting that staying put is the best option? Do you even understand how software works?

 

[Bokito]

As I suggested in the other thread Apple should backport this fix to 10.14 and later (if needed) since those OSes are in active use. If they’re not vulnerable Apple should communicate that. They now leave open a very serious security issue that’s easy to exploit and gives a bad actor instant root access. That’s very, very bad.

 

[ignatius345]

Of note: the default setting for Screen Sharing is OFF on macOS. So, unless you've specifically switched it on AFAIK you're not vulnerable to this particular exploit.

 

[Unregistered 4U]

Glad I use Apple’s more secure OS’s!

 

[bzgnyc2]

Of note: the default setting for Screen Sharing is OFF on macOS. So, unless you've specifically switched it on AFAIK you're not vulnerable to this particular exploit.

Agree at this point more details on the vulnerability need to be shared.

Does the vulnerability persist if Screen Sharing is Off? Note that Apple generally leaves every possible "daemon" or "service" running regardless of whether it is being used / turned off. So depending on the nature of the vulnerability just having this off may not be enough.

And/or what if "Allow access for": "Only these users" is selected but no users are listed (default is to list Administrators)? Again that should be a further block but depending on what the bug is that faulty state management allows to be bypassed, not clear if that mitigates the issue for unpatched systems (which I suspect includes everything before Sonoma).

To avoid risks like this I always set my systems:
1) Enable Firewall (which for some reason defaults to off despite all the kabuki theater of Apple security)
2) Don't allow Apple nor signed software to bypass the firewall (self-exempting oneself from rules and policies tell me you aren't doing it right so even suggesting to do this tells me Apple's software shouldn't be exempted)
3) Ensure everything in Sharing is off as well as all options under them (belts and suspenders people belts and suspenders)

That's on top of other basic security practices and generally working from behind a firewall'd network (NAT or corporate)

Still not sure it's enough.

 

[bzgnyc2]

Glad I use Apple’s more secure OS’s!

Which are?

 

[Steve Adams]

Which are?

Linux and Windows.....

 

[ikramerica]

10.0.1.1 shows port 5900 closed/timeout, so does it matter if 5900 is open on 10.0.1.12 for example? At least for external attack?

 

[chucker23n1]

Does the vulnerability persist if Screen Sharing is Off?

No.

Note that Apple generally leaves every possible "daemon" or "service" running regardless of whether it is being used / turned off.

It's the opposite: they generally design their daemons such that they only run when a socket is open. That's also true of screensharingd. You can easily try this yourself:

1. With Screen Sharing disabled, open Activity Monitor, and search for screensharingd. You probably won't find it.
2. Now in Terminal, do telnet localhost 5900. This will fail with "connection refused", as there's nothing listening. screensharingd still won't be running, of course.
3. Now turn it on. Notice that screensharingd still isn't running!
4. Finally, try telnet localhost 5900 again. This time, it'll work, and the very act of connecting to that port is what actually launches the daemon.

This is a mechanism in launchd with security and energy benefits. Instead of having screensharingd constantly listening for connections, launchd does the listening:

    <key>Sockets</key>
    <dict>
        <key>Listener</key>
        <dict>
            <key>Bonjour</key>
            <string>rfb</string>
            <key>SockServiceName</key>
            <string>vnc-server</string>
        </dict>
    </dict>

1) Enable Firewall (which for some reason defaults to off despite all the kabuki theater of Apple security)

I don't think that would do anything useful in this scenario. If you don't want Screen Sharing to accept connections, just leave it off. If you do, you'll also need to let the firewall allow it in.

3) Ensure everything in Sharing is off as well as all options under them (belts and suspenders people belts and suspenders)

Sure, but that's the default anyway.

 

[chucker23n1]

10.0.1.1 shows port 5900 closed/timeout, so does it matter if 5900 is open on 10.0.1.12 for example? At least for external attack?

You need to try with localhost (or 127.0.0.1, or ::1).

 

[inventor7777]

How vulnerable is a computer behind a cable modem, etc. with a local IP address (10.0.*.*, 192.168.*.*)?

I would like to know that too. Most internet routers should block incoming connections from the Internet by default. Unless you explicitly forward all (or selected) ports to your Mac of course. But the article above is very not clear about that.

10.0.1.1 shows port 5900 closed/timeout, so does it matter if 5900 is open on 10.0.1.12 for example? At least for external attack?

Most reasonably modern routers should block this by default. That means any ISP provided equipment, name brand routers, firewalls like OPNsense, etc, unless you explicitly create a port forwarding entry.

If you have a strange setup with the Mac directly connected to a cable modem (small box with a coax input and an Ethernet output), and your IP is something other than:

• 10.0.0.0/8
  Range: 10.0.0.0 to 10.255.255.255
  Example: 10.0.0.1 to 10.255.255.254
• 172.16.0.0/12
  Range: 172.16.0.0 to 172.31.255.255
  Example: 172.16.0.1 to 172.31.255.254
• 192.168.0.0/16
  Range: 192.168.0.0 to 192.168.255.255
  Example: 192.168.1.1 (common for home routers), 192.168.0.1

Then yes, you'd be at risk as modems do not have firewalls, that is what a router/firewall is for.

 

[CarAnalogy]

5900 should never, ever be exposed directly to the internet anyway. At best, you’re going to be constantly flooded with brute force login attempts.

The real issue here is that authentication can be bypassed entirely.

This is also dangerous on untrusted public networks where devices are allowed to communicate with each other.

I wish macOS had better built in firewall controls. Windows has actually mitigated things like this by automatically calling networks “public” until told otherwise, denying all incoming connections.

 

[Unregistered 4U]

Which are?

The ones not listed in the article? I guess the article does only mention macOS, so “all of the other ones”.

 

[txscott]

Screen share with headless MacMini running MacOS 26.6.1 over the internet.

Random internet port on router forwards to port 22 on Mac. Insure all other ports are locked down on router.
Mac runs Murus Firewall, an easier way to configure Mac firewalls. Use Murus to create a PF rules set that locks down all ports but port 22 and provides services equivalent to Fail2Ban and Port Knocking.
Access with private key only and insure other usually recommended security settings for sshd, like denying root logins, are configured on the Mac instance of sshd.
Use screen sharing on the Mac via ssh tunnel. Something like:

ssh -f -L 5900:localhost:5900 user@path.to.router -p <your port> sleep 10; open vnc://localhost:5900

All data, including your login, is encrypted. Sleep command holds the tunnel open until vnc connects. Once connected it forks to a ackground process and will stay open until you close the VNC session.

Same advice for Linux or BSD, the only difference is the tool or tools used to configure the firewall. The only cost is Murus, a well respected and inexpensive product.

 

[phenste]

The fix was also required and issued for Sonoma and Sequoia; it is not particular to Tahoe.

thank you for letting me know! updating to 15.7.9 tonight 🙂

 

[Think|Different]

I had these open as relics and was exploited by this two months ago. The “hackers” managed to steal some funds after stopping them once before I realized what was going on. I had no idea at the time it was an exploit and not just stale “never had a problem in 20 years” mistakes. Sad but glad it’s fixed!!

 

[chucker23n1]

I wish macOS had better built in firewall controls. Windows has actually mitigated things like this by automatically calling networks “public” until told otherwise, denying all incoming connections.

In practice, I haven't found Windows's scopes of Domain/Private/Public to be that great (for example, it's not very transparent which external hosts it considers to be in which scope, and don't get me started about the Scope tab, where you can add IP addresses, but not host names, the dialog is not resizeable no matter how long your list, and there's no way to add comments, so you end up with this giant list of IP addresses).

But… yes. macOS's built-in firewall is even more limited. I also don't love that most of its settings are now cramped inside a sheet.

(edit) Having said that, this is irrelevant for most users anyway. Almost nobody actually has their Mac publicly exposed — at home, you'll likely have it behind a router, and even if you don't, your ISP may put you behind CGNAT. At work, there will probably be some form of NAT, too.

But it would be nice if, when explicitly allowing port 5900, there'd be another layer that restricts "do you want this for the local network? Or anyone on the Internet?", etc.