SimpleHelp Zero-Auth Bug Lets Attackers Create Rogue Admin Accounts

What Happened

SimpleHelp, a remote monitoring and management (RMM) platform used by IT teams and managed service providers worldwide, has a vulnerability that lets unauthenticated attackers create privileged technician accounts on any server running OpenID Connect (OIDC) authentication. No credentials, no prior foothold, no social engineering required — just a network path to the server. The flaw was disclosed by BleepingComputer and lives in the OIDC authentication flow of the web management interface.

Why It Matters

RMM tools are the skeleton keys of IT infrastructure. A technician account in SimpleHelp is not just access to a management console — it is a pivot point to every endpoint that server manages. From a single rogue account, an attacker can push scripts, open remote sessions, exfiltrate data, or deploy ransomware across an entire managed fleet, all through a legitimate signed-in session that bypasses most endpoint detection.

The "unauthenticated" qualifier is what makes this severe. Most exploits require some prior access — a phished credential, a foothold on the network. This one requires only that your SimpleHelp server is reachable, which is the default deployment posture: MSPs and IT teams routinely expose SimpleHelp to the internet so technicians can work remotely. If you run OIDC auth and have not patched, assume your server is reachable by anyone.

The attack surface is also concentrated in dangerous ways. Compromising a single MSP's SimpleHelp server grants access to that MSP's entire customer base — one breach, potentially hundreds of victims. This is structurally identical to the supply-chain leverage used in the Kaseya VSA ransomware attack in 2021. History does not need to repeat itself here.

What To Do

1. Identify your exposure immediately. If you run SimpleHelp with OIDC authentication enabled, treat this as critical regardless of any initial vendor severity rating. Confirm whether your server is internet-accessible.

2. Apply the patch. Review the BleepingComputer writeup for affected versions and the patched release. Update before anything else.

3. Audit technician accounts right now. Pull a full account list and compare against your known roster. Any account you do not recognize — even one created minutes ago — should be disabled and treated as an indicator of compromise.

4. Review recent session logs. Look for remote sessions from unfamiliar accounts, unusual machines accessed, or bulk scripting activity. Attackers move fast once they have a foothold in an RMM.

5. Disable OIDC as a stopgap if you cannot patch immediately. Switch to local accounts temporarily, then patch and re-enable OIDC.

6. MSPs: notify your customers. Even without confirmed compromise, customers whose endpoints were managed through a vulnerable server during the exposure window deserve to know.

There is no grace period for authentication bypass vulnerabilities in remote management infrastructure. Patch, audit, and verify — in that order, today.