From UniFi OS RCE to Reverse SSH: 59 Callback-Confirmed Hosts and Seven-Architecture Payload Staging

Overview

Recovered attacker tooling shows the operationalization of CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 into a bulk UniFi OS exploitation workflow spanning reconnaissance, command-execution validation, and payload deployment attempts.

The workflow processed 107 host entries, produced authentication-bypass-positive results for 100, and received system-information callbacks from 59. Those callbacks provide evidence of remote command execution and outbound connectivity on 54 hosts geolocated to the United States and 5 to Taiwan. The same staging environment contained seven architecture-specific Go binaries derived from reverse_ssh and configured to connect to v9g6[.]my:3232.

Evidence boundary: The 59 callbacks confirm command execution and outbound callback capability. The recovered logs do not establish successful malware delivery, execution, persistence, or C2 check-in.

Key Findings

• 100 of 107 hosts produced results consistent with authentication-gateway bypass.
• 59 of those 100 hosts (59%) returned system-information callbacks, confirming remote command execution and outbound connectivity.
• The 59 callback-confirmed hosts comprised 54 systems geolocated to the United States and 5 to Taiwan.
• The attacker tooling automated a three-stage workflow: scan, probe, and deploy.
• Seven Linux payloads covered ARM, ARM64, MIPS32, MIPS64, x86-32, and x86-64 architectures.
• All seven payloads were derived from NHAS/reverse_ssh v2.2.3 and configured with v9g6[.]my:3232.
• Deployment was attempted against the 59 callback-confirmed hosts, but the available artifacts do not establish whether the payloads executed.

Why This Matters

The callback records show exploitation activity by 10 July 2026—50 days after Ubiquiti published Security Advisory Bulletin 064 and 17 days after CISA added the three vulnerabilities to its Known Exploited Vulnerabilities catalog. Within that period, the vulnerability chain had been incorporated into tooling that could process target lists, validate command execution through callbacks, classify system architecture, and launch deployment attempts at scale.

UniFi OS occupies a high-value position in the network-management control plane. As Bishop Fox noted in its analysis of the chain, root access to the management platform can expose administrative control, secrets, and the network or physical-security systems managed through the console. The seven-architecture payload set further demonstrates preparation for persistent remote access across a heterogeneous Linux device population, even though successful payload execution was not recorded.

This report's primary contribution is first-party evidence connecting the 2026 UniFi OS RCE chain to a bulk exploitation workflow, 59 callback-confirmed command executions, and a seven-architecture reverse_ssh payload set configured for port 3232.

Evidence Funnel

---

Infrastructure Analysis

The recovered tooling, target lists, results, and payloads were stored on a server accessible at the following address:

• IP Address: 204.194.51[.]30
• Geolocation at time of analysis: United States
• Origin Prefix: 204.194.51.0/24
• Origin ASN: AS140869 (TGL-AS-AP)
• ASN Registrant: Turing Group Limited
• Covering Allocation: 204.194.48.0/21 (DFI-NET2, Decision Focus Incorporated)

The available artifacts support classifying this system as a staging and artifact server. They do not independently establish that it handled malware command-and-control traffic; the analyzed binaries instead contained the separate C2 destination v9g6[.]my:3232.

At the time of the lookup on 24 August 2026, RIPEstat routing data identified 204.194.51.0/24 as announced by AS140869. APNIC's ASN record identifies the autonomous system as TGL-AS-AP, registered to Turing Group Limited, while ARIN's address record places the IP within the broader 204.194.48.0/21 allocation registered as DFI-NET2 to Decision Focus Incorporated.

These routing and registration records identify network relationships, not the physical server location, customer identity, infrastructure ownership, or responsibility for the activity.

Numerous files containing IP addresses believed to be attack targets were identified on the staging server.

The targets.txt file contained 107 IP addresses.

---

UniFi OS Vulnerability Exploitation

The recovered tooling targeted three vulnerabilities in the UniFi OS Server RCE chain:

• CVE-2026-34908 — improper access control used as an authentication-gateway bypass
• CVE-2026-34909 — path traversal
• CVE-2026-34910 — improper input validation leading to command injection

Ubiquiti Security Advisory Bulletin 064 was published on 21 May 2026. UniFi OS Server 5.0.6 and earlier are affected, and version 5.0.8 contains the relevant fixes. The vendor advisory also lists affected UniFi hardware products with model-specific fixed versions; this report focuses on the UniFi OS Server software chain represented in the recovered tooling. CISA added all three vulnerabilities to its Known Exploited Vulnerabilities catalog on 23 June 2026.

These vulnerabilities allow an attacker to bypass the UniFi OS frontend authentication gateway and execute remote commands through internal API endpoints without valid credentials.

Bishop Fox publicly documented the unauthenticated RCE chain associated with these CVEs and released a non-destructive detection tool, while explicitly declining to provide a turnkey exploitation recipe.

The weaponized batch_exploit.py identified in this investigation appears to be separate attacker-developed tooling. No evidence established code lineage or derivation from Bishop Fox's published research or detection tool.

Exploit code targeting these vulnerabilities was identified in batch_exploit.py on the staging server. The script supported three main stages:

• Scan
• Probe
• Deploy

UniFi OS vulnerability chain

Exploitation Flow

Recovered tooling progressed from bulk screening to callback-confirmed command execution and unverified deployment attempts.

107

scan input

100

bypass-positive

59

RCE callbacks

59

deploy attempts

7

payload builds

Phase 1

Scan

1. 01Target ingestionobserved107 host entries were loaded from targets.txt and organized by geography.
2. 02Gateway-Bypass scanning and screeningobserved100 hosts were classified as authentication-bypass-positive; seven returned PATCHED or ERROR.

Phase 2

Probe

1. 03Command-injection probeobservedCVE-2026-34910 executed a system-information command against the 100 positive hosts.
2. 04Callback confirmationconfirmed59 systems returned host, architecture, timestamp, and system-information data.

Phase 3

Deploy

1. 05Architecture and privilege selectionobservedCallback data guided the reverse-shell or payload-deployment path.
2. 06Payload deployment attemptsunconfirmedSeven reverse_ssh builds covered ARM, MIPS, and x86 targets across 59 hosts.

Evidence boundaryThe 59 callbacks confirm command execution and outbound connectivity. Payload delivery, execution, persistence, and C2 check-in remain unconfirmed.

---

Scan Stage

The attacker used targets.txt to scan for vulnerabilities CVE-2026-34908 and CVE-2026-34909.

The scan covered 107 target IP addresses. Of these, 100 produced authentication-bypass-positive results. The other seven produced outcomes such as PATCHED or ERROR; ERROR results are inconclusive and should not be interpreted as confirmation that a host was not vulnerable. The results were saved in results.json.

---

Probe Stage

Following the scan, the attacker proceeded to the probe phase using CVE-2026-34910 to test whether commands could be executed through the affected endpoints.

The file results_vulnerable.json contained the 100 authentication-bypass-positive hosts and served as input to the probe stage. Probe commands were attempted against all 100 hosts. A separate callback record, confirmed.json, contained system information returned by 59 hosts, providing evidence of remote command execution and outbound callback capability on those systems.

---

Deploy Stage

During the deploy stage, the attacker targeted the 59 hosts that had returned system-information callbacks during the probe stage.

The tooling supported different deployment attempts—including reverse shells and persistent root-level payloads—based on the apparent privilege level and system architecture of each host. The available artifacts do not establish successful malware delivery, installation, persistence, or C2 check-in on these hosts.

The deployment function used blind command execution: it discarded command output (>/dev/null 2>&1) and recorded only whether an HTTP response was received. An HTTP response establishes that the request reached an endpoint; it does not establish that the injected command executed successfully. Deployment outcomes were printed to the console but were not written to a results file, and no deployment-time callback was collected. Accordingly, payload delivery, execution, and persistence remain unconfirmed.

When the 59 callback-confirmed hosts selected for deployment attempts were classified by country, 54 were geolocated to the United States and 5 to Taiwan.

• United States: 54
• Taiwan: 5

---

Malware Analysis

Seven payloads staged for deployment were identified on the artifact server. Static analysis determined that all seven were Linux reverse SSH backdoors written in Go.

Payload Family Overview

The seven staged samples (linux_arm, linux_arm64, linux_mips64le1, linux_mipsle, linux_x32, linux_mips64, linux_x64) are assessed as a single family cross-compiled for multiple architectures (ARM / ARM64 / MIPS32 / MIPS64 / x86-32 / x86-64) and derived from the open-source NHAS/reverse_ssh v2.2.3 client.

All samples are configured to attempt an outbound SSH connection to v9g6[.]my:3232, and the binaries contain a hard-coded process name used during background re-execution. No executable packing such as UPX was detected in the analyzed files. The recovered deployment tooling references on-disk execution; memory-only execution was not observed in the available artifacts.

Sample Behavior and Supported Capabilities

Static analysis identified background re-execution, a configured C2 destination, and functionality inherited from reverse_ssh. The following sections distinguish sample configuration from framework capabilities; the presence of a capability does not establish that it was exercised during this activity.

Deployment and Process Masquerading

• The process uses a SHA-256-like name (e.g., b37051c6...fb1d85). This is consistent with process-name masquerading, although intent cannot be established from the name alone.
• Background re-execution is performed through a child process that launches /proc/self/exe, with a fallback to the executable path derived from argv[0].
• setuid(0) and setgid(0) attempt to set the process’s user ID (UID) and group ID (GID) to 0 (root), respectively; these calls do not themselves escalate privileges and succeed only if the process already has the required privileges. setsid() creates a new session and detaches the process from its controlling terminal, provided the calling process is not already a process group leader.
• During background re-execution, the F environment variable carries the client's original command-line arguments while a different argv can be presented as the process name. The child retrieves the original arguments and removes F from its environment before continuing. This behavior supports process masquerading; F is not the remote-command channel.

C2 Connection

• An outbound SSH connection is attempted to the configured C2 address v9g6[.]my:3232.
• If the connection is lost, an infinite reconnection loop with a 10-second interval continuously attempts to restore C2 connectivity.
• The hard-coded destination does not contain a transport prefix, so the analyzed configuration uses SSH directly over TCP. The upstream framework also supports TLS, secure WebSockets, and HTTPS transports. In those TLS-based modes, certificate verification is disabled with InsecureSkipVerify=true; plain ws:// does not add transport encryption. These alternate modes are supported capabilities and were not observed in the analyzed configuration.

Supported Remote-Control Capabilities

The embedded reverse_ssh code supports the following SSH channels. Their presence in the samples does not establish observed use in this campaign.

• The session functionality also supports SCP transfer, URL download (rssh-download), and PTY shells.

Auxiliary Functions

• Loads an embedded SSH private key for C2 authentication and can generate a key if an embedded key is unavailable.
• Supports file transfer through SCP, SFTP, and rssh-download (URL to disk).
• Advertises the client identification string SSH-v2.2.3-linux_<arch>.

Multi-Architecture Deployment Analysis and Differences

The seven samples have different file hashes and were compiled for different target architectures. Static comparison indicates that they share the same reverse_ssh-derived code base and configuration, with no material code-level behavioral differences identified among them.

---

Related Reporting and Infrastructure Correlation

An external report published on 22 July 2026, wp2shell — Cross-Platform RAT Deployment via Zero-Credential WordPress Exploit, described a separate Go payload named Agent-TCP and associated it with v9g6[.]my:443. Oasis Security did not obtain or independently analyze those Agent-TCP samples, so their implementation and capabilities remain third-party claims.

The external report also contains material CVE-to-product labeling errors: it attributes CVE-2021-36260 to Ubiquiti even though NVD identifies it as a Hikvision command-injection vulnerability, and it labels CVE-2026-34908 as a D-Link issue. Accordingly, this investigation treats the report as an external infrastructure lead rather than an authoritative source for the UniFi exploit chain.

The directly analyzed samples were configured with v9g6[.]my:3232, while the external report identified the same domain on port 443. This shared domain is a useful infrastructure correlation, but it does not establish shared code, simultaneous operation, common control, or attribution. Certificate Transparency records and the historical 202.61.136[.]40 association provide additional temporal context; the detailed certificate chronology is preserved in Appendix A.

---

Target Distribution

Separate host files labeled for the United States and Taiwan were identified in the recovered artifacts. The filenames and host distribution demonstrate geographic organization of the data, but they do not by themselves establish a geopolitical objective or attribution.

The identified files were:

• vul_US_unifi.txt — 99 IP entries (pre-deduplication)
• vuln_unifi_tw.txt — 9 IP entries (pre-deduplication)

To validate data consistency, the IP addresses in vul_US_unifi.txt and vuln_unifi_tw.txt were deduplicated and cross-referenced with the authentication-bypass-positive hosts recorded in results.json and results_vulnerable.json.

After deduplication, the resulting dataset contained 100 unique authentication-bypass-positive IP addresses (93 in the United States and 7 in Taiwan), matching the hosts recorded in both results.json and results_vulnerable.json. Of these, 59 hosts returned system-information callbacks consistent with command execution during the probe phase.

---

Evidence Basis and Confidence

The findings in this report are based on recovered server-side artifacts, attacker-tool output, callback records, and static analysis of seven staged Linux binaries. Host status in this report is based on the recovered tooling rather than an independent rescan of the listed systems.

An authentication-bypass-positive result is distinct from a callback-confirmed command execution, and neither result establishes successful malware deployment. Geolocation reflects the data available at the time of analysis. Malware behavior is described as observed only when supported by sample configuration or recovered logs; functionality inherited from the upstream framework is identified as a supported capability.

---

Conclusion

Recovered artifacts show exploitation activity against hosts geolocated to the United States and Taiwan using CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910. Of 107 host entries supplied to the scan stage, 100 produced authentication-bypass-positive results. Probe attempts against those hosts produced system-information callbacks from 59 unique systems: 54 geolocated to the United States and 5 to Taiwan.

The callback records provide evidence of remote command execution and outbound connectivity on those 59 systems. The 59 hosts were then selected for reverse-shell or malware deployment attempts, but the deployment mechanism recorded no command output or deployment-time callback. The available artifacts therefore do not establish successful payload delivery, execution, persistence, or C2 check-in.

Seven staged Linux payloads were identified as Go-based reverse SSH backdoors derived from NHAS/reverse_ssh v2.2.3 and compiled for ARM, MIPS, and x86 architectures. All seven were configured with v9g6[.]my:3232, demonstrating preparation for deployment across multiple architectures rather than confirmed remote-control sessions on victim systems.

Together, these artifacts document the rapid conversion of a newly disclosed UniFi OS vulnerability chain into repeatable bulk-exploitation tooling and multi-architecture post-exploitation staging. The report's measured impact is therefore the confirmed execution footprint and demonstrated operational readiness—not an unsupported claim that all 59 systems received the backdoor.

---

Appendix A: Certificate Transparency and Historical Infrastructure

Six Certificate Transparency records were observed for v9g6[.]my: four associated with Let's Encrypt certificates and two associated with Cloudflare-issued certificates or precertificates. All records cover both the wildcard (*.v9g6.my) and the root domain (v9g6.my).

Note: Status is based on the certificate validity period as of 2026-08-24 and does not confirm that a certificate was actively deployed or used. Certificate Transparency data was cross-checked against the Cert Spotter issuance API.

Abbreviations: LE = Let's Encrypt; CT = Certificate Transparency; cert = certificate; precert = precertificate.

The historical association between v9g6[.]my and 202.61.136[.]40 was first observed in the investigation dataset on 2026-07-11, 11 days before the external report was published on 2026-07-22. Both dates fall within the validity period of Certificate No. 3 (2026-06-15 to 2026-09-13). The earliest certificate record in the analyzed dataset begins on 2026-04-17.

At the time of a routing lookup on 24 August 2026, RIPEstat identified 202.61.136.0/24 as announced by AS152194. APNIC's ASN record identifies the autonomous system as CTGSERVERLIMITED-AS-AP, registered to CTG Server Limited, and APNIC's address record places the address within the 202.61.136.0/21 allocation registered as CTG136-JP to CTG Server Ltd. Because the domain-to-IP observation dates to 11 July and the routing lookup was performed later, the available data does not establish that AS152194 originated the address at the exact time of the historical association.

Certificates were issued through 13 August 2026, with the latest observed validity period ending on 11 November 2026. At the time of analysis, the domain used Cloudflare nameservers but did not return an IPv4 address. The historical IP was geolocated to Japan by the data source used at the time. These passive observations do not establish active service, current resolution, hosting location, continued operator maintenance, ownership, control, or future reuse.