“John Sim” — the rogue UniFi super-admin and Security Advisory Bulletin 064

Bulletin 064 was published on 21 May 2026 and discloses five vulnerabilities in UniFi OS, the firmware layer that runs on every UniFi Cloud Gateway, Dream Machine, Network Video Recorder, Cloud Key, UNAS, and the self-hosted UniFi OS Server. The vulnerabilities were reported through Ubiquiti's HackerOne bug-bounty programme.²³

Three of the five carry the maximum possible CVSS v3.1 score. The published vector for those three is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — which decodes to: reachable over a network (AV:N), low attack complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), with scope change (S:C — the compromise extends beyond the vulnerable component into the underlying system), and full impact on confidentiality, integrity, and availability (C:H / I:H / A:H).² That is the most severe shape a CVSS vector can take. For a router, it means an attacker who can reach the management interface can take it over — full stop, no credentials needed.

The chain matters as much as the individual CVEs. The path-traversal flaw (34909) lets an attacker read credential material off the device; the access-control flaw (34908) lets an attacker make system changes without authentication; the command-injection flaw (34910) lets an attacker run arbitrary commands. Stitched together, the trio is enough to create a persistent administrator and walk out with a configuration backup — which is exactly what the John Sim accounts appearing on residential consoles in the days after the advisory look like.⁴

Ubiquiti's advisory says “a malicious actor with access to the network.”The wording is deliberately ambiguous, which is reasonable during an active disclosure window — but it has confused a lot of people in the public threads about how worried to be. The right read, supported by the CVSS AV:Nvector and by community analysis of the underlying components, is that the attack surface is the UniFi web GUI on TCP 443 and TCP 80.⁵ Anything that can reach those ports can reach the vulnerability. Practically there are two populations that satisfy that condition:

The exposed-console population — the primary risk pool

UniFi consoles whose web interface is reachable from the public internet. Three configurations land a console in this group: an explicit port-forward mapping WAN traffic to the controller, a “Direct Remote Connection” toggle, or a firewall rule that was meant to allow remote ping or monitoring and accidentally exposed the web UI. The last one is the trap that caught one of the John Sim victims quoted above.¹

The size of this pool is published. Censys, the internet-scanning service, tracks “nearly 100,000 Internet-exposed UniFi OS endpoints,” with approximately 50,000 of those in the United States.⁴Not every one of those is unpatched, and not every one of those is residential — but the order of magnitude is the relevant fact. The scanner that's creating the John Sim accounts does not have to guess where to point. It has a list.

The flat-LAN population — the underestimated secondary pool

UniFi consoles whose web interface is only reachable from the LAN, but whose LAN contains a device that an attacker can compromise first — a self-hosted media server with a port-forward of its own, an IoT camera with a known CVE, a smart-home hub running an outdated container, a guest device, a laptop that picked up something at a coffee shop. We have written separately about how often the actual way into a residential UniFi network is through one of those exposed services, with the gateway taken over afterwards by lateral movement. See The case against port-forwarding Plex, Jellyfin, and Home Assistant for the citation chain on that pattern.

What the “access to the network” phrasing does notmean is that any random byte crossing the WAN can trigger the bug. Routed packets alone are not enough — the attacker has to be able to speak HTTP to the management interface. But it does not require the attacker to already have credentials, or to be sitting next to the console with an Ethernet cable. A port-forward and a scanner's IP range are sufficient.

Bulletin 064 affects every shipping UniFi OS device family. Different product lines were patched at different version numbers — the version you are updating todepends on the model you have. The table below reproduces the cutoffs published in Ubiquiti's advisory.²

If you can't recall which model you own, the UniFi mobile app shows it under Console → Settings → System; the web UI shows it under Settings → Control Plane → Console. The current installed version sits two lines below the model on either surface.

The check is short and there is no benefit to putting it off. Open the UniFi mobile app or the web console and run all three of these:

1. The Admins screen. Web: Settings → Control Plane → Admins. Mobile: Console → Admins. The list should contain exactly the people you put there — the owner, any site admin you explicitly added, and any integrator or consultant you previously granted access. Any account you don't recognise — most visibly John Sim, but the attacker may also use other names — is the smoking gun. Note the email address and the “Created” date before you remove the account; both go into the incident record.
2. The activity log. Web: Settings → Control Plane → Activity (sometimes System Logon older firmware). Filter by user. Look at the rogue admin's entries: in the public Reddit reports so far, the account is created and then never logs in — the log shows the creation entry and nothing else.¹ If you see follow-on login entries, configuration changes, file downloads, or backup-restore events from that account, the incident is no longer theoretical and section 7 of this article applies.
3. The Backups page. Web: Settings → Control Plane → Backups. UniFi's backup mechanism is one of the documented post-compromise actions an attacker uses on consoles owned this way — backups contain credential material and configuration export.⁴ If a backup download or backup-restore event appears in the log around the time the rogue admin was created, treat the configuration as untrusted: every SSID password, every site-to-site VPN key, every API token in the backup should be rotated.

Five minutes, three screens. If all three come back clean — no extra admin, no unusual activity, no recent backup events — you are almost certainly fine even if the underlying CVE was reachable from your WAN. The botnet appears to be opportunistic and time-boxed, not targeted; consoles that were patched before the scanner arrived are not in the dataset of victim posts at all.

If you would rather not run this check yourself on a regular cadence — and most households should be running it more than once a year — the same review is part of the read-only network audit we offer as a service. The audit covers the Admins list, the activity log, MFA posture on the owner account, and what's reachable from the WAN, written up in plain English alongside the rest of the residential-UniFi review.

If the check in section 5 found a rogue admin, work through this list start-to-finish — the order matters, because patching last is what allows the attacker to come back even after you've removed the account they created.

1. Patch first. Web: Settings → Control Plane → Updates. Update the UniFi OS console to the fixed version for your model (section 4 table). If the console is sitting behind an out-of-date controller you have been deliberately holding back, the calculus has changed — this advisory is the named-CVE exception to the wait-and-watch firmware cadence. See When to update UniFi firmware, and when to wait for the framework. Apply now, watch after.
2. Evict the rogue admin. Settings → Control Plane → Admins → click the unknown account → Remove. UniFi will ask for confirmation; confirm. The session belonging to that account, if any is active, will be terminated.
3. Rotate the owner-account password. At account.ui.com → Security → Password. The rogue admin was created without your password — that is the whole point of the advisory — but if any other configuration on your console was touched, the safe assumption is that your existing owner password is no longer privileged.
4. Force-logout every active session. account.ui.com → Security → Active sessions → Sign out everywhere. This terminates any mobile app, browser, or API session that was authenticated at the time of the breach window, forcing every device to re-authenticate against the rotated password.
5. Close the WAN exposure. Three specific places to look. (a) Settings → Routing → Port Forwarding— delete any rule pointing at the gateway's LAN IP on TCP/443 or TCP/80. (b) Settings → System → Advanced → Remote Access (or Direct Remote Connection on older firmware) — if enabled, ask whether the convenience is worth the exposure. (c) Settings → Security → Firewall Rules— review any custom WAN-in or WAN-local rule that might allow inbound HTTP/HTTPS to the gateway. One of the John Sim victims discovered their exposure was a firewall rule that was meant to permit external ping but inadvertently allowed the console web interface as well.¹
6. Enable MFA on the Ubiquiti SSO account. account.ui.com → Security → Multi-factor authentication. Authenticator app is the right default; SMS is the fallback. The CVEs in Bulletin 064 do not directly bypass MFA on existing accounts — what they bypass is the requirement to have credentials at all. MFA on your existing owner account, combined with a patched console, is the configuration that stops the next round of this.

The whole sequence is roughly ten minutes if your console is in front of you and you have your Ubiquiti account credentials handy. The most common place households get stuck is step 3 — in homes where an AV integrator was named as the Ubiquiti SSO Owner of the gateway, the homeowner doesn't have the credentials to rotate the password. The fix in that case is to take the Owner role back; see Should your AV integrator be the Owner of your network? for the procedure and the trade-offs.

In every Reddit report we've been able to verify, the John Sim account was created and never logged in.¹ That is consistent with an automated scanner running ahead of human followup. The footprint changes if any of the following appear in the activity log after the account-creation entry and before you removed the account:

• A successful login from the rogue account, from an IP not on your usual list.
• Any configuration change — a new firewall rule, a new VLAN, a new SSID, a changed DNS server, a new port-forward, a change to an existing user's role.
• A backup download or backup restore. Backup downloads from the console contain credential material; restoring an attacker-prepared backup would replace your configuration wholesale.⁴
• A new SSH key on the console, or any change to Settings → Control Plane → Console → SSH.
• Outbound network connections from the gateway to destinations you don't recognise — visible in the gateway's connection log if Threat Management or Insights are enabled.

If any of those are present, the right posture is to treat the gateway as compromised at the system level, not just at the application level. The conservative procedure is to back up the current configuration (for forensic preservation, not for restoration), factory-reset the device, set up a fresh console with the rotated credentials and MFA from section 6, and restore from a known-good backup taken before the rogue admin was created. Every credential present in that backup — SSIDs, VPNs, API tokens — should still be rotated, because the attacker may have read them before you reset.

This is the kind of incident response a residential network owner can run unaided, but the time pressure and the “am I done yet” question are where a second pair of experienced eyes earns its fee. If you would rather have someone walk through it with you, that's the kind of work we do — a short engagement, written up, with the full remediation log handed back to you. The contact form is the fastest way to start that conversation.

A real reservation, voiced clearly in the announcement thread on r/Ubiquiti and worth reproducing rather than hand-waving past: updating UniFi OS from 5.1.11 to 5.1.12 introduces a policy where the console will automatically update its installed applications — UniFi Network, UniFi Protect, and so on — to their current versions, on some hardware, whether you want those app versions or not.⁶ A UNVR will forcibly update Protect; a UCKG2+ acting as a dedicated NVR will not. The behaviour is device-specific, but the headline matters: on Protect-bearing consoles in particular, OS 5.1.12 may pull you onto a Protect version with its own known issues.⁶

The case for patching anyway, when the alternative is leaving an unauthenticated CVSS 10.0 RCE exposed, is straightforward: an automated scanner with a published advisory and three CVEs to chain will reach you faster than a broken ONVIF camera driver will. But the cost is real, and a household with a critical Protect deployment should plan for the upgrade rather than letting it land at 3 AM unattended. That means: take a Protect backup before the OS update, schedule the update during a window where someone can verify the cameras still work afterwards, and have the Protect rollback procedure ready in case the new version misbehaves.

This is precisely the judgment-call that distinguishes a network being run on a deliberate cadence from one that's either chronically out-of-date or chronically auto-updated into bugs. We've written about the general framework — when to update fast, when to wait — in When to update UniFi firmware, and when to wait. Named CVE with a high CVSS is the exception that overrides the wait. This one is the textbook example.

Take a step back from John Sim specifically. Bulletin 064 is the third Ubiquiti security advisory inside roughly twelve months that includes an unauthenticated maximum-severity vulnerability in a network-reachable surface of UniFi. The previous two were CVE-2026-22557(path traversal in UniFi Network application, CVSS 10.0, disclosed March 2026 as Bulletin 062) and the entry that FirstPassLab references one earlier in the year.⁷

Two patterns are visible across all three. First, the vulnerability classes are the textbook ones — path traversal, improper input validation, improper access control. These are not exotic findings; they are the first three chapters of OWASP and the things a code review should catch. One of the community comments in the announcement thread put it bluntly: “Input validation, access control, path traversal — these are all obvious attack vectors, that should be rigorously designed against and checked for. Vulnerabilities here shouldn't be hitting the wild, they shouldn't even hit betas.”⁶Whatever else is true about Ubiquiti's software engineering, the “and earlier” suffix on the affected-version list — UDM ≤ 5.0.16, UCG-Ultra ≤ 5.0.16, UNAS ≤ 5.1.8 — suggests these are long-standing bugs only recently discovered, not regressions introduced in the last release.

Second, the disclosure pipeline is working. All five Bulletin 064 CVEs came through HackerOne's bug-bounty programme, were credited to named external researchers, and were fixed and patched on the same day the advisory dropped.² The submitter of one of the CVEs, posting in the announcement thread, was unequivocal: “Ubi are doing everything right, they're getting blasted by researchers with more effective research pipelines … they were fast, balanced, and it was via HackerOne, they want this.”⁶ The structural problem is not Ubiquiti hiding things; it is that the bug-discovery pipeline has gotten more productive at the same time that internet-exposed residential consoles have proliferated.

The implication for a homeowner is not that UniFi is unusually risky — Cisco, Palo Alto, Fortinet each had perfect-10 advisories in the same window and the comment thread compares them directly.⁶The implication is that “set up the network once and never look at it again” is no longer a viable posture on a residence with an internet-exposed admin interface or a flat LAN with a self-hosted service. Either the homeowner is running a deliberate update cadence and has a way to audit the admin list on a known schedule — or somebody else is doing it for them. The third option, in which neither is true, is the one the John Sim accounts fell into.

• The attacker's endgame is not yet known.In the cases reviewed at the time of writing, the rogue admin was created and not used. Whether that's because the human operator hasn't started followup yet, because the foothold is being sold as access, or because the scanner is reconnaissance for a larger campaign, the public data does not yet say. The posture “evict now, assume compromise of any credential the backup could have contained” is conservative and right.
• Ubiquiti has not officially acknowledged the John Sim incident.The Bulletin 064 publication's “no active exploitation confirmed” line predates the Reddit reports by five days and has not been updated as of publication of this article. Mainstream security press — Bleeping Computer, SC Media, cybersecuritynews.com, gbhackers — covered the advisory itself but had not picked up the John Sim mass-incident at the times the articles were published. The primary source on the incident pattern is the Reddit thread cited throughout.¹
• “Access to the network” is ambiguous in the advisory. The reading in section 3 — that the attack surface is the web management interface on TCP/443 and TCP/80 — is the consensus reading among the top-voted analyses in the announcement thread and is consistent with the CVSS AV:N vector.⁵ Ubiquiti has not published a more specific description, and the conservative reading would still include any reachable port on the device until they do.
• The username may rotate. “John Sim” is the username in every public report so far, but there is no reason to assume the scanner is locked to that string. If you find an admin you don't recognise with a different name, treat it identically. The signal is “admin you did not create,” not the specific spelling.
• This article is a second-source writeup. Every CVE detail and version cutoff is from the primary Ubiquiti advisory, but the incident pattern itself is built from community posts corroborating each other. If new information from Ubiquiti or from security press contradicts anything here, the bulletin is the source of truth — this page will be updated.

The five-minute check in section 5 is the load-bearing recommendation in this article. If you do nothing else after reading it, open your UniFi Admins screen right now. If you would like an outside read of your console — admin list, activity log, MFA posture, WAN exposure, and the rest of the residential-UniFi review — that's the work we do, and the contact form is the fastest way to start it.