What jumped out at me isn’t just that an extension was compromised. It’s how completely ordinary the attack path is once you accept one uncomfortable fact: IDE extensions are executable software with real reach. If a marketplace bundle can ship an injected extension.js, you don’t need some exotic exploit chain. You get local file access, key material, persistence hooks, and whatever the user’s environment conveniently exposes. That part feels grimly predictable.
What’s more interesting is the accidental fragility of the payload. The write-up points out a macOS logic bug where the malware asks systemsetup -getremotelogin without elevation, gets an “administrator access” error, and then mistakes that for “SSH is already on.” That is both funny and not funny at all. Funny because the operator apparently shipped a backdoor with a self-sabotaging permission check. Not funny because the rest of the implant still does the important parts: plant an authorized key, stage a reverse tunnel key, and leave persistence behind. Even if the inbound SSH path fails on some Macs, the machine may still be left in a compromised state that becomes immediately useful later if Remote Login gets enabled.
I think the most useful detail here is the author’s distinction between the two keys. That’s the part I’d actually look for first in an investigation: the planted public key in authorized_keys, and the embedded private key used to bring the tunnel home. A lot of incident reports blur those together, but they serve different purposes and leave different traces. One is about inbound access to the victim. The other is about keeping a control channel alive. If you’re hunting across endpoints, that separation matters.
There’s also something slightly suspicious about the operational sloppiness. The post says the Windows path has its own bug because it routes a PowerShell service command through a helper that hardcodes /bin/sh. If that’s accurate, then the implant doesn’t read like a polished long-term platform. It reads like something assembled fast enough that platform-specific assumptions leaked everywhere. Maybe that’s just malware being malware. Or maybe it suggests the same basic pattern could have been copy-pasted across platforms without much testing. I’d be cautious about assuming the operator had a robust playbook.
The larger takeaway for people shipping with Claude Code or any other IDE-integrated tooling is simpler and uglier: “official” doesn’t mean “safe,” and marketplace distribution is a trust boundary whether we like it or not. The second an extension loads, it’s already inside the developer workflow, and that workflow usually has more secrets than the endpoint team thinks it does. If I were running this in a real environment, I’d want immediate checks for suspicious authorized_keys additions, LaunchAgents or startup artifacts with bland names, and any unexpected SSH listener/tunnel activity tied to editor processes. I’d also want to know who installed the extension and where else the same package may have been mirrored.
The annoying part is that this kind of compromise doesn’t need to be perfect to be useful. It only needs to work on enough machines, often enough, before someone notices. That’s the real lesson here, not the macOS bug.
Reference: Official Claude Code Extension Compromise: Security Advisory | Phorion
