tl;dr
RemoteMouse for macOS (≤ 3.510) still ships with the same broken authentication CuckooEXE (Axel Persinger) discovered in 2021's MouseTrap disclosure.
Found a new bug: the
web opncommand checks whether a string containshttp://instead of checking the URL's actual scheme, so afile://URL with a decoyhttp://fragment sails straight through to NSWorkspace.openURL.End result: one crafted TCP packet to port 1978 silently launches an arbitrary local app with zero authentication if no Connection Password is set, which is the app's default state.
Tracked as CVE-2026-66419. Vendor notified, patch in progress.
Why RemoteMouse?
I've been planning to give AI-assisted vulnerability research a serious try, and ghidra-mcp gave me a good excuse. All I needed was a target binary.
RemoteMouse felt like the obvious pick. A few years back, while building Mice (a deliberately vulnerable lab) inspired by CuckooEXE’s MouseTrap research I spent some time poking at it and ended up finding a couple of issues myself: EDB-ID 50047 / CVE-2021-35448 and EDB-ID 50258.
Five years later, it was still familiar territory, but distant enough that I could approach it with fresh eyes and a new workflow. That made it a great target for seeing where AI can actually help in reverse engineering and vulnerability research, versus where it’s just confidently hallucinating about a decompiler listing.
Is the Mouse still Trapped?
Before digging into anything new, I wanted to see whether the current RemoteMouse release had finally escaped the original MouseTrap findings.
MouseTrap is a suite of vulnerabilities documented by CuckooEXE, most notably CVE-2021-27572 and CVE-2021-27573. The latter is especially interesting: it is the bug the original RemoteMouse exploit was built around (EDB-ID 46697).
So I started with the boring-but-important check: does the latest version still fall over in the same way?
It does! The MouseTrap issues appear to still be present.
That made RemoteMouse an even better target. It is a familiar protocol with a known history of security problems, publicly documented exploitation paths, and apparently a few old traps that never got cleaned up.
New finding: web opn
After a bit of poking at the protocol and a few well-aimed prompts we found a new issue that has nothing to do with the original MouseTrap bugs.
The web open handler tries to restrict targets to HTTP URLs, but its validation is only a substring search. Instead of checking the URL’s actual scheme, it effectively asks: “Does this string contain http:// anywhere?”
That distinction matters.
A payload such as file:///path/to/thing#http:// passes the check because http:// appears in the fragment. But the URL is still a file:// URL. The application then hands the original string directly to NSURL, followed by NSWorkspace.openURL, which opens it exactly as supplied.
So a check intended to allow only web links can be bypassed with a non-web URL simply by hiding http:// somewhere harmless-looking at the end.
It’s a small validation mistake with a very classic result: the guard checks for a string; the platform parses a URL.
PoC || GTFO
To reproduce the issue, find a Mac on the local network running RemoteMouse. The service listens on TCP port 1978 and identifies itself immediately after a connection:
The two nop fields indicate that no connection password is configured the default unless the user has explicitly set one.
Then send a single packet:
Calculator opens on the target Mac.
No login prompt. No keystroke injection. No need to race for focus or hope the right window is active, as the original exploit did. The payload reaches NSWorkspace.openURL directly the same macOS API Finder uses when you double-click an app or file.
A web-link command becomes an arbitrary URL opener because the validation checks whether http:// appears somewhere in the string, rather than verifying that the URL is actually an HTTP(S) URL.
A fully automated PoC will be available on GitHub. It also incorporates the MouseTrap findings to handle targets configured with a connection password.
Timeline
May 6, 2021: CuckooEXE publishes MouseTrap, documenting six RemoteMouse command-protocol vulnerabilities (CVE-2021-27569 through CVE-2021-27574), including unauthenticated control primitives, replayable authentication, and unauthenticated UDP RCE.
2021: RemoteMouse 4.0 is released without addressing the MouseTrap findings, according to CuckooEXE’s follow-up.
July 30, 2026: We discovered a new issue and reported it via VulnCheck.
July 31, 2026: CVE-2026-66419 was provisionally assigned.
August 8, 2026: The vendor acknowledged the report and, according to VulnCheck, is working on a fix.