The UniFi Root Chain — Three CVEs, One Unauthenticated Root RCE on 100,000 Exposed Appliances

The Identity Problem

Ubiquiti built a brand on an appealing proposition: enterprise-grade networking at prosumer prices. A small business owner, a home lab enthusiast, a school IT department, or a medium-sized enterprise could buy a Dream Machine Pro, click through a setup wizard, and have a managed network stack — firewall, switching, wireless, VPN, cameras, access control — running in an afternoon, without a Cisco-certified engineer.

That proposition worked. Ubiquiti's UniFi platform has been deployed at extraordinary scale. The devices that run UniFi OS — Dream Machines, Cloud Gateways, Network Video Recorders, UNAS appliances — are found in tens of thousands of businesses, schools, government offices, and residential networks worldwide.

The identity problem is this: those devices are frequently configured for the same remote access that makes them convenient to manage, which means the UniFi OS management interface is often reachable from the internet. In June 2026, Censys identified approximately 100,000 internet-exposed UniFi OS endpoints, roughly half of them in the United States.

When CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 chained together into a single unauthenticated root RCE, every one of those 100,000 appliances was reachable by that exploit.

Three Researchers, Three Bugs

Ubiquiti's Security Advisory Bulletin 064, published May 21–22, 2026, credits three different researchers:

• Duc Anh Nguyen (@heckintosh_) — CVE-2026-34908 (improper access control)
• Abdulaziz Almadhi, Catchify Security — CVE-2026-34909 (path traversal)
• John Carroll — CVE-2026-34910 (improper input validation / command injection)

All three reported through Ubiquiti's HackerOne bug bounty program. All three received patches in the same advisory. None appears to have known what the others had found.

Bishop Fox's June 8, 2026 analysis showed what happens when you put those three reports next to each other: a complete, unauthenticated exploit chain that takes an attacker from no credentials to root on the appliance without requiring any prior access, any user interaction, or any unusual network conditions.

Three bugs. Three researchers. One chain that none of them built alone.

How the Chain Works

The exploit has three steps, each feeding directly into the next.

Step 1 — CVE-2026-34908: The Authentication Bypass

UniFi OS routes all incoming requests through an authentication gateway before passing them to backend services via Nginx. The gateway checks whether the request URI falls within a list of public (unauthenticated) paths. Nginx then routes the request to the appropriate backend using the URI after normalization — decoding percent-encoded sequences and resolving path segments.

The vulnerability: the authentication gateway evaluates the raw, percent-encoded URI, while Nginx routes using the normalized URI. These two representations of the same request can resolve to different paths.

An attacker constructs a request whose raw URI begins with a public path prefix — passing the gateway's allowlist check — while embedding percent-encoded path separators (%2f) and traversal sequences (%2e%2e) that, after normalization, resolve to a protected internal service route under /proxy/<service>/. The gateway sees a public path and waves it through. Nginx sees an internal route and delivers it.

The result: any internal UniFi OS service endpoint — normally accessible only after authentication — is now reachable without credentials.

Step 2 — CVE-2026-34909: The Key Theft

With the authentication bypass in place, the attacker uses path traversal sequences to navigate to the internal file service routes. The same URI normalization mismatch that defeated authentication can be used to reach endpoints that expose the appliance's underlying filesystem.

From those routes, the attacker reads:

• The signing key used to authenticate admin sessions
• TLS private keys for the management interface
• Cloud access tokens linking the appliance to Ubiquiti's cloud infrastructure
• The credential database containing admin password hashes
• Configuration data for RADIUS, VPN, WiFi, NFC, and physical access control systems

The signing key is the most consequential item on that list — and understanding why requires understanding what happens after the appliance is patched.

Step 3 — CVE-2026-34910: Root

The ucs-update service exposes a package-update endpoint that accepts a package name parameter. The handler passes that parameter directly into a shell command without sanitization:

sudo /usr/bin/uos runnable latest-versions <package-name>

With authentication bypassed via CVE-2026-34908, an attacker reaches this endpoint and injects shell metacharacters into the package name, executing arbitrary OS commands as the ucs-update service account.

That account holds passwordless sudo privileges over /usr/bin/dpkg. An attacker escalates to full root by crafting a malicious .deb package with a postinst script that runs as root under dpkg. The escalation path: command injection → build a malicious .deb → install via dpkg → root.

End-to-end, an unauthenticated request achieves root code execution on an appliance that may control the network routing, cameras, door locks, and authentication infrastructure for an entire building or campus.

The Persistence Problem

The patch in UniFi OS Server 5.0.8 closes all three vulnerabilities:

• URI normalization guard eliminates the raw/decoded mismatch
• Package-name allowlist and argument-array execution eliminate the command injection
• Passwordless dpkg and chmod sudo grants are removed

What the patch cannot do is undo what an attacker already accomplished on an instance that was exposed while running a vulnerable version.

The signing key stolen via CVE-2026-34909 is the critical issue. Firmware updates do not automatically rotate the appliance's signing key. An attacker who exfiltrated that key before patching can continue to forge valid admin sessions after patching — sessions that the appliance accepts as legitimate because they are cryptographically valid, signed with the real key.

Bishop Fox noted this explicitly: "The fix closes the way in, but it does not reach back and undo what an attacker already did with root on an instance that was exposed beforehand."

Patching is necessary but not sufficient. For any appliance that was internet-accessible on a vulnerable version, the correct assumption is that the signing key, credentials, and certificates may have been exfiltrated — and that assumption drives a response that patching alone does not complete.

What Root on UniFi OS Means

Root-level access to a UniFi OS appliance is not equivalent to root on an isolated server. UniFi OS is the hub of everything the device manages:

• Network routing — the appliance is the gateway; an attacker can inspect, modify, or redirect all traffic passing through it, install persistent packet capture, or alter firewall rules to open new inbound paths
• VPN — credentials, configuration, and the private keys for VPN tunnels are all accessible
• RADIUS — if the appliance is serving RADIUS for 802.1X WiFi or wired authentication, the attacker controls which devices are allowed on the network and can read authentication traffic
• Video surveillance — NVR appliances hold camera credentials and footage
• Physical access control — on access-control-equipped hardware, door lock credentials, NFC key material, and facial recognition profiles are all stored locally
• Cloud bridge — cloud access tokens allow an attacker to interact with Ubiquiti's cloud management platform as the appliance owner

A compromised UniFi OS appliance is not just a compromised box. It is a compromised trust anchor for everything the network, the cameras, and the doors depend on.

What Defenders Must Do

For all UniFi OS deployments:

1. Patch immediately. Update to the patched firmware for your hardware (see the individual CVE pages for version tables). Apply via the UniFi console update mechanism.

2. If your instance was internet-accessible before patching, treat it as compromised. Do not simply patch and move on. Assume the signing key, admin credentials, TLS certificates, and cloud tokens may have been exfiltrated.

3. Use the Bishop Fox detection tool (github.com/BishopFox/CVE-2026-34908-check) to verify whether your instance was or is vulnerable.

4. Rotate everything. Admin passwords, TLS certificates, cloud access tokens, VPN credentials, RADIUS secrets. Contact Ubiquiti support for signing key rotation procedures specific to your appliance model — this is not something the standard update process handles.

5. Revoke and reissue all admin sessions. Forged sessions signed with a stolen key look legitimate to the appliance. Revoking active sessions forces re-authentication and limits the window of forged access.

6. Audit for persistence. Check recently installed packages (dpkg -l), systemd units, cron jobs, and sudoers modifications for anything an attacker may have planted after achieving root. The appliance's startup chain should match what Ubiquiti shipped.

7. Move management off the internet. This is the single most effective long-term control. UniFi OS management should not be directly reachable from the public internet — ever. Route remote administration through a VPN with MFA. If your business case requires internet-accessible management, the risk calculus needs to include the blast radius described above.

8. Audit downstream trust. If the appliance is the authentication gateway for your network, review what has changed: firewall rules, VPN configurations, RADIUS policy, access control lists. An attacker with root had time to make changes designed to survive patching.

The URI Normalization Class

CVE-2026-34908 belongs to a recurring vulnerability class: authentication bypass via divergence between how a security control evaluates a request and how a downstream component routes it.

The same class appears in different forms across web infrastructure: Apache Tomcat servlet path handling, Nginx location matching, Spring Security URL pattern evaluation, and proxy authentication layers. In each case, the security boundary sees one representation of the request while the application sees another, and a carefully constructed URI crosses the boundary by satisfying both checks simultaneously — the check that should block it and the routing that should route it.

The UniFi OS variant is particularly clean: percent-encoding in the raw URI defeats the allowlist check, while normalization before Nginx routing resolves the encoded sequences to the real path. The fix — verify that raw and normalized forms agree before making the access control decision — is conceptually straightforward. Deploying that check consistently across a complex application with multiple authentication-aware layers is the hard part.

Timeline

The six-week gap between Ubiquiti's patch (May 21) and CISA's KEV addition (June 23) is consistent with a pattern seen throughout the KEV catalog: patches that arrive before exploitation, followed by exploitation once Bishop Fox or similar researchers publish a working proof of concept or detection guidance — in this case, June 8, fifteen days before KEV addition. Whether exploitation preceded or followed the Bishop Fox publication, CISA's confirmation is clear: the chain is being used in the wild.