Your Mac Can Apparently Say "Wrong Password. Come On In."
Here's your Saturday morning cybersecurity PSA:
Update your Mac.
Not eventually. Not the next time macOS annoys you with a notification while you're doing something important. If you're running macOS Tahoe, Sequoia or Sonoma and haven't installed the latest security update, I'd go ahead and knock that out.
Because this particular bug is both serious and almost offensively stupid.
Apple recently patched a vulnerability in macOS Screen Sharing called CVE-2026-65400. Apple describes it rather politely as an authentication problem fixed with "improved state management." The practical version is considerably more entertaining:
Under the right conditions, somebody could try to connect to your Mac without valid credentials and the authentication system could essentially respond:
Yep. Looks good to me. Come on in.
Apple released fixes on August 6 for macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9.
And this isn't theoretical anymore.
The Dutch National Cyber Security Centre updated its advisory on August 12 after receiving reports of the vulnerability being actively exploited on systems where Screen Sharing port 5900 was exposed to the internet. In every case they were told about, the attacker had obtained root access and installed a Monero cryptocurrency miner.
Which is almost disappointingly mundane.
You discover a vulnerability capable of handing you root access to somebody else's Mac and your grand criminal master plan is apparently:
"Sweet. Let's make this thing mine $4 worth of Monero."
But the cryptocurrency part isn't actually what caught my attention.
This Wasn't a Buffer Overflow
This bug is interesting because it wasn't one of the traditional memory-corruption vulnerabilities we've spent decades trying to eliminate.
No buffer overflow.
No use-after-free.
No wild pointer wandering off into memory where it doesn't belong.
It was a logic problem.
According to the technical analysis of the vulnerability, one of the failure paths involved processing an oversized authentication frame. The software correctly recognized that the frame exceeded the permitted size.
So far, so good.
Then things went sideways.
A network-read function returned a status value indicating that the read itself succeeded. That value was zero.
Elsewhere in the authentication logic, zero also meant success.
The wrong value got returned.
And suddenly the software was effectively telling the rest of the system:
Authentication successful.
The source walkthrough describes the result as a complete authentication bypass that could then provide privileged file access.
That's spectacular.
Not because it required some impossibly clever exploitation technique.
Because it didn't.
The machine did exactly what the software told it to do.
The software was simply wrong.
Rust Doesn't Save You From Being Wrong
This is also why I think this story matters well beyond Apple.
There's been a huge and very worthwhile push toward memory-safe programming languages like Rust.
That's good.
Memory safety eliminates entire families of vulnerabilities that have tortured software developers for decades.
But memory safety cannot protect you from bad logic.
You can have beautiful types.
Safe memory.
Perfectly valid variables.
Elegant enums representing every state in your application.
And then transition from STATE_NOT_AUTHENTICATED to STATE_AUTHENTICATED at the wrong moment.
Congratulations.
You now have extremely memory-safe compromised software.
The transcript I was reviewing makes this point particularly well with a second Screen Sharing issue involving state-machine synchronization: you can implement the state machine in Rust with every modern language feature available and still create the same vulnerability if the transitions themselves are wrong.
That's the bigger story here.
AI Is About To Make This Problem More Interesting
And this is where my brain immediately went.
We're entering a world where an enormous percentage of software is going to be written, modified, reviewed or assembled with AI.
Most of the conversation around AI-generated code security still sounds like:
Will the AI write insecure code?
Of course it will.
Humans have been doing that professionally since approximately five minutes after we invented software.
The more interesting question is what kinds of mistakes become dominant when software production accelerates dramatically.
I think bugs like this deserve a lot more attention.
Because an AI coding agent can produce code that compiles perfectly, passes type checking, contains no memory vulnerabilities, calls the correct APIs, satisfies every individual interface contract, and still implements the wrong system behavior.
The failure can exist in the relationship between components rather than inside any individual component.
That's a very different security problem.
And it starts looking eerily similar to the problems we're already discovering with autonomous agents.
The Attack Surface Is Moving Up The Stack
Traditional security spends enormous energy protecting mechanisms.
Memory.
Processes.
Credentials.
Network boundaries.
Permissions.
All still important.
But increasingly, the most interesting failures are happening higher in the abstraction stack.
State.
Authority.
Intent.
Sequence.
Context.
The computer isn't necessarily being tricked into executing an illegal instruction.
It's being tricked into reaching a perfectly legal conclusion that happens to be completely wrong.
That distinction becomes enormously important once AI systems start orchestrating software, infrastructure and business processes.
Imagine the authentication bug translated into an agentic system.
The agent correctly reads the email.
Correctly identifies the customer.
Correctly calls the payment API.
Correctly receives a success response.
Correctly updates the CRM.
Every tool invocation works exactly as designed.
The problem is that somewhere in the workflow, one successful operation was interpreted as authorization for another.
Nothing crashed.
Nothing violated memory safety.
Nothing necessarily generated an obvious error.
The system simply reached the wrong conclusion.
And then executed it beautifully.
That's a class of security problem we're going to become very familiar with.
Now For The Actual PSA
There is one important qualifier here.
This isn't somebody magically reaching through the internet and owning every MacBook on Earth.
Apple describes the attacker as needing network access to Screen Sharing, and the known exploitation reported by the Dutch NCSC involved systems where TCP port 5900 was reachable from the public internet.
Still: Update your Mac.
And unless you have an actual reason for exposing Screen Sharing directly to the internet, don't.
Go to: System Settings, then General, then Software Update.
And install the latest available macOS update.
If you use Screen Sharing intentionally, particularly on remotely accessible Macs or servers, make sure you're not casually exposing VNC or port 5900 directly to the internet.
Because attackers are already using this.
Today they're mining Monero.
Tomorrow somebody considerably more ambitious may notice that arbitrary root access to computers is useful for considerably more than making pocket change in cryptocurrency.
And perhaps the most important lesson isn't even about Macs.
For decades we've been learning how to stop computers from executing things they shouldn't be allowed to execute.
The next security problem may increasingly be:
The computer executed everything perfectly.
It just understood the situation completely wrong.
Sources
Apple — macOS Tahoe 26.6.1 Security Content Official Apple advisory for CVE-2026-65400. Apple says an attacker on the network may be able to authenticate to Screen Sharing without valid credentials and that the flaw was fixed with improved state management. Released August 6, 2026. support.apple.com/en-us/148170
Dutch National Cyber Security Centre — NCSC-2026-0280 Government security advisory covering the Screen Sharing authentication vulnerability in macOS Tahoe, Sequoia and Sonoma. The August 12 revision notes that public proof-of-concept code was available and active exploitation was known. advisories.ncsc.nl/2026/ncsc-2026-0280.html
Rich Washburn is a technologist, strategist, and Founder & Chief AI Architect of ARIA AI Labs, working at the intersection of AI, infrastructure, communications, and capital. He also serves as Managing Partner and Chief AI Officer at Eliakim Capital.
Comments