UniFi OS Server — Unauthenticated Root RCE Chain (CVE-2026-34908 / 34909 / 34910)

Ubiquiti advisory SAB-064 (~2026-05-21) discloses three chained, maximum-severity (CVSS 3.1 = 10.0) vulnerabilities in UniFi OS Server, the self-hosted UniFi management application that runs on Linux. CVE-2026-34908 is an improper access-control flaw in the authentication gateway; CVE-2026-34909 is a path-traversal flaw in the same gateway that exposes underlying OS files; and CVE-2026-34910 is a command-injection flaw in the package-update service. Chained, they yield unauthenticated root command execution from a single crafted HTTP request with no user interaction.

The auth-bypass works by exploiting a divergence between the raw and normalized interpretation of a request URI: a request can be crafted so its raw form begins with the auth-exempt /api/auth/validate-sso/ prefix while the normalized form resolves to an authenticated route, defeating the gateway. The command injection then lands in the package-update route, which passes unsanitized package names to shell execution. Execution occurs under the ucs-update service account, which holds passwordless sudo to /usr/bin/dpkg — trivially escalated to root. Affected: UniFi OS Server <= 5.0.6 (unifi-core 5.0.126); fixed in 5.0.8 (unifi-core 5.0.153). Bishop Fox demonstrated the full end-to-end root shell on 5.0.6 and published a detection-analysis writeup; BleepingComputer reported active exploitation in June 2026.

The highest-fidelity defensive angle is behavioral: the UniFi OS process tree (unifi-core / node / the package updater, running as ucs-update) is not supposed to spawn an interactive shell, an interpreter, or a download tool. That single telemetry event — UniFi service process to sh/bash/python/perl — is the spine of this hunt and survives the payload/IP rotation that automated exploitation churns through.

Defender priority: Patch UniFi OS Server to >= 5.0.8 immediately and pull the management plane off the internet. Critically, patching does NOT evict an attacker — a recovered JWT signing key yields forged owner/admin tokens that work against patched consoles too. Treat any pre-patch internet-exposed instance as root-compromised: rotate the signing key (reboot), rotate all secrets, and rebuild from a known-good image where exploitation is confirmed.

Web-hunter note: Atomic IOCs (specific payload hashes, C2 IPs) are not durably published — exploitation is automated and infrastructure rotates. The pack therefore leads with behavioral detection on the UniFi process tree and treats any published file/IP indicators as perishable hunt/enrich values. The most consequential intel is that forged sessions survive patching — coverage must extend past patch verification to credential/session invalidation.

Hypotheses (ordered by fidelity)

1. H1 (high): A UniFi OS / package-update process (parent unifi-core, node, ulp-go, or the updater, running as ucs-update) spawned a shell or interpreter (sh/bash/dash/python/perl) → command-injection exploitation of CVE-2026-34910. Lowest FP, highest fidelity.
2. H2 (high): The UniFi service account (ucs-update) invoked privilege-escalation primitives — sudo dpkg, chmod, systemctl, or a passwd/SSH change — indicating root escalation after injection.
3. H3 (medium): A UniFi/web-gateway process spawned a download tool (curl/wget) → ingress tool transfer / second-stage pull (T1105).
4. H4 (medium): The UniFi process tree made outbound connections to new/rare external IPs (reverse shell / C2), i.e. server-initiated egress atypical for an appliance.
5. H5 (medium): Web/access logs show requests combining the /api/auth/validate-sso/ prefix with encoded traversal (..%2f, ..%2e) or shell metacharacters against .../ucs/update/latest_package — the exploit request itself.
6. H6 (low): A process executed from a writable/temp/package-staging path under the UniFi tree (second-stage tooling staged via the injection).
7. H7 (medium, persistence): Forged-session / auth anomalies — owner/admin tokens used without a preceding interactive login, or new SSH/root-password changes — indicating forged-token access that persists after patch (T1556/T1078).

Attack chain

Exploitation is automated and infrastructure rotates; few durable atomic IOCs are published. The values below are behavioral and contextual. Replace REPLACE_WITH_* placeholders with indicators confirmed in your own telemetry before promoting to a block.

Scope note: Falcon for Linux only covers self-hosted UniFi OS Server instances on managed Linux hosts. Embedded hardware appliances (UDM/UCG/NVR) carry the same chain but have no EDR telemetry — cover them via patch inventory (SAB-064), the Bishop Fox checker, and network/egress controls.

Checks that do not require Falcon process telemetry — run these directly on the host or against shipped logs:

• Version inventory: confirm UniFi OS Server is >= 5.0.8 (unifi-core 5.0.153). Any host <= 5.0.6 (unifi-core 5.0.126) is presumed exposed. For hardware, verify the model-specific fixed UniFi OS build per SAB-064.
• Safe exposure check: run the Bishop Fox CVE-2026-34908-check tool against every reachable UniFi OS Server (default listener TCP 11443) to confirm vulnerable status without exploiting.
• Access-log review: grep gateway/reverse-proxy logs for requests whose path contains /api/auth/validate-sso/ together with traversal sequences (..%2f, ..%2e) or for hits on .../ucs/update/latest_package carrying shell metacharacters.
• Service-account behavior: review process/audit history for the ucs-update account spawning shells or running sudo dpkg / chmod / systemctl — these are not normal interactive operations.
• Persistence check: exploitation is unauthenticated, so a forged admin token leaves no preceding login. Look for admin/owner actions, SSH enablement, or root-password changes with no corresponding interactive auth event — and confirm the JWT signing key has been rotated post-patch.

Promotion candidates from the hunt queries above (Linux platform, Process Create rule type):

Q4 (rare-IP egress) and Q5 (access-log exploit request) are best deployed as scheduled-search detections rather than Process-Create IOAs, since they key on network and log telemetry, not process creation. Q7 (forged-session persistence) should be a scheduled search correlated against identity/auth events.

One-click copy blocks for ingestion. Atomic indicators are perishable for this automated campaign — use placeholders until you confirm values in your own telemetry.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_SECONDSTAGE_SHA256,detect,critical,2026-12-22,UniFi OS RCE chain second-stage payload,campaign:UniFiOSRCE
ipv4,REPLACE_WITH_SCANNER_OR_C2_IP,detect,high,2026-09-22,UniFi OS exploit source or C2,campaign:UniFiOSRCE
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2026-09-22,UniFi OS second-stage C2,campaign:UniFiOSRCE

parent_proc IN (unifi-core, node, ulp-go, package-update)
  AND child_proc IN (sh, bash, dash, python, perl)        # cmd injection exec
user = ucs-update AND proc IN (sudo, dpkg, chmod, systemctl, passwd)  # root escalation
proc_exec FROM (/tmp/, /var/tmp/, /dev/shm/, staging/)    # staged tooling
http_req: /api/auth/validate-sso/ + (..%2f | ..%2e)       # auth-gateway bypass
http_req: /ucs/update/latest_package + shell metachars    # command injection

UniFi OS Server Unauth RCE Chain (Ubiquiti SAB-064, ~2026-05-21)
CVE-2026-34908 improper access control (auth gateway)
CVE-2026-34909 path traversal (auth gateway, OS file exposure)
CVE-2026-34910 command injection (package-update service)
Affected: UniFi OS Server <= 5.0.6 (unifi-core 5.0.126)
Fixed:    5.0.8 (unifi-core 5.0.153)
Bypass:   raw-vs-normalized URI via /api/auth/validate-sso/ prefix
Exec acct: ucs-update -> passwordless sudo /usr/bin/dpkg -> root
Listener: TCP 11443 | Persistence: forged JWT tokens survive patch

# Confirm UniFi OS Server / unifi-core version (>= 5.0.8 / 5.0.153)
dpkg -l | grep -i unifi-core 2>/dev/null
cat /usr/lib/unifi-core/package.json 2>/dev/null | grep -i version
# Safe vuln check (Bishop Fox, non-exploitative) against listener
#   git clone https://github.com/BishopFox/CVE-2026-34908-check
#   run per its README against host:11443
# Confirm mgmt listener is NOT internet-exposed
ss -tlnp | grep ':11443'

A · Restrict the management listener (host firewall)

Allow TCP 11443 only from the management subnet; drop everything else:

# nftables: only allow UniFi OS Server console from mgmt subnet 10.10.0.0/24
nft add rule inet filter input tcp dport 11443 ip saddr 10.10.0.0/24 accept
nft add rule inet filter input tcp dport 11443 drop
# (iptables equivalent)
iptables -A INPUT -p tcp --dport 11443 -s 10.10.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 11443 -j DROP

B · WAF / reverse-proxy virtual patch (nginx)

# reject auth-gateway bypass + command-injection request shapes
location ~* ^/api/auth/validate-sso/ {
    if ($request_uri ~* "(\.\.%2f|\.\.%2e|\.\./)") { return 403; }
    proxy_pass https://127.0.0.1:11443;
}
location ~* ^/ucs/update/latest_package {
    if ($args ~* "[;|&`$]|%3b|%7c|%60") { return 403; }
    proxy_pass https://127.0.0.1:11443;
}

C · Rotate signing key + invalidate sessions (post-patch persistence eviction)

# 1) patch first, then rotate the JWT signing key (requires a reboot to take effect)
#    follow Ubiquiti SAB-064 / console docs for the key-rotation procedure
# 2) force re-auth of all admins and revoke existing sessions from the console
# 3) rotate downstream secrets reachable pre-patch
#    - device adoption / inform keys, TLS keys, cloud tokens, shared creds
# 4) confirm SSH was not enabled and no root password was set by the attacker
grep -E 'sshd|PermitRootLogin' /etc/ssh/sshd_config
chage -l root ; cat /root/.ssh/authorized_keys 2>/dev/null

D · Patch & exposure verification

# confirm unifi-core is a fixed build (>= 5.0.153 / UniFi OS Server >= 5.0.8)
dpkg -l | grep -i unifi-core
# confirm the console listener is not internet-reachable
ss -tlnp | grep ':11443'

Validation: Coverage of the exploitation spine (Q1 shell-spawn, Q2 root escalation) is strong and low-FP on self-hosted Linux instances. The exploit request (Q5) and forged-session persistence (Q7) are only covered where gateway/auth logs reach NGSIEM — confirm log shipping or accept the partial gap. Embedded hardware consoles have no EDR telemetry and are covered only by patch inventory, the Bishop Fox checker, and network/egress controls. Validate Q4 exclusion lists (Ubiquiti cloud ranges) and Q5 HTTP field names against your tenant before deploying.