🛡️ SecOps

UniFi OS Bulletin 064 Post-Disclosure Forensics: Detecting Compromise on Ubiquiti Controllers

Two days after Ubiquiti published Security Bulletin 064 with three CVSS 10.0 vulnerabilities, security teams should be confirming that patches have applied and hunting for indicators of pre-patch compromise. This guide covers the specific log sources, indicators, and commands available on UniFi OS devices for detecting exploitation activity.

4 min read
#ubiquiti#unifi#forensics#threat-hunting#incident-response#network-equipment#bulletin-064

Ubiquiti’s Security Bulletin 064, published 22 May with three CVSS 10.0 vulnerabilities in UniFi OS, requires two parallel responses: applying the patch and investigating whether exploitation occurred before the patch was applied. This guide covers the forensic investigation work that should accompany patching.

Determining the Exposure Window

The exposure window for each organisation depends on:

  • The UniFi OS version running before the bulletin was published
  • Whether the management interface was accessible from untrusted networks (internet or semi-trusted segments)
  • When the patch was applied

If the management interface (TCP 443) was accessible from the internet without authentication, the exposure window begins with the disclosure of similar vulnerability classes that threat actors may have researched beforehand, and runs until the patch was applied. For controllers that were reachable from the internet while on a vulnerable version, a forensic review is warranted.

Available Log Sources on UniFi OS

UniFi OS provides limited but useful log access through the management interface:

System Log (System → System Log in the controller UI): Contains service start/stop events, authentication events for the management interface, and system-level events. Useful for identifying unexpected service restarts (which may indicate exploitation attempts) and unusual administrative login events.

Network Events (Settings → System → Application Logs): Application-level events including API calls, configuration changes, and access attempts.

SSH Access Logs: If SSH access is enabled on the controller, SSH authentication logs are accessible. UniFi OS uses a Linux-based OS underneath the management interface, and SSH logs are available via shell access: /var/log/auth.log.

For direct shell access (requires SSH enabled on the controller):

# Review recent auth events
tail -500 /var/log/auth.log | grep -E '(Failed|Accepted|Invalid)'

# Check for unexpected processes
ps aux | grep -vE '(ubnt|root)' | grep -v grep

# Review recent file modifications in sensitive directories
find /etc /usr/share/unifi -newer /var/log/unifi/server.log -type f 2>/dev/null

# Check for cron jobs or persistence mechanisms
crontab -l 2>/dev/null
ls /etc/cron.d/ 2>/dev/null
ls /var/spool/cron/ 2>/dev/null

Specific Exploitation Indicators

For CVE-2026-34908 (Access Control Bypass): Exploitation produces API calls to administrative endpoints without corresponding valid session tokens. In HTTP access logs (if accessible via shell at /var/log/nginx/access.log or equivalent), look for requests to /api/ paths returning 200 success responses from external IP addresses at unusual times, particularly outside business hours.

For CVE-2026-34909 (Path Traversal): File read exploitation leaves access patterns for system files not normally accessed by the management API. Look for requests to paths containing ../ sequences in access logs. File write exploitation may have created new files — check for recently modified files in web-accessible directories.

For CVE-2026-34910 (Command Injection): Successful command injection results in processes spawned with elevated privileges from the web server context. Unusual processes in ps aux output, unexpected outbound network connections (check ss -tnp for unexpected established connections), and new files created in /tmp or home directories are indicators.

Post-Exploitation Persistence Checks

Attackers who successfully compromised a UniFi controller may have:

Added new administrator accounts: In the UniFi UI under Settings → Admins, review all administrator accounts. Any account not recognised should be removed and treated as evidence of compromise.

Added new Wi-Fi networks or SSIDs: Review the Networks and Wi-Fi configuration for any SSIDs not configured by known administrators. Rogue SSIDs with names similar to the legitimate corporate SSID are a common persistence and credential theft mechanism.

Modified VLAN or routing configuration: Review network topology configuration for unexpected VLAN additions, routing changes, or new network segments that could redirect traffic.

Installed persistent backdoor via SSH authorised keys: If SSH access is enabled on the controller, review /root/.ssh/authorized_keys for unexpected public keys.

If Compromise Is Confirmed

If forensic indicators confirm that the controller was compromised:

  1. Isolate the controller from the network
  2. Preserve logs before factory resetting (download system logs via the UI)
  3. Factory reset the controller and reconfigure from a known-good configuration backup (if the backup was created before the suspected compromise window) or from scratch
  4. Review all connected devices for configuration changes made during the compromise window
  5. Treat all credentials stored in the controller (RADIUS shared secrets, network passwords, VPN credentials) as compromised and rotate them

Share this article