Critical RCE in UniFi OS Server Grants Root Access

A critical vulnerability chain has been identified in UniFi OS Server software, placing thousands of organizations at serious risk. Researchers confirmed that an attacker can gain full root access to affected devices without any credentials, leveraging a single unauthenticated request for a complete system takeover.

UniFi OS Server is the management platform for the UniFi family of applications, including Network, Protect, and the identity and update services that ship with it.

It runs as a collection of backend services behind a single Nginx front end that terminates TLS, authenticates requests, and proxies them to the right internal services. That proxy function is the center of the security model, and it is exactly where this attack chain begins.

Security researchers at BishopFox identified and confirmed the full attack chain end-to-end, validating that a single request to a reachable UniFi OS Server turns into a reverse shell with full root privileges.

BishopFox said in a report shared with Cyber Security News (CSN) that the severity comes from what the appliance controls: it is the management plane for the network it runs.

Root access exposes every stored secret, lets an attacker forge admin sessions that survive patching, and in physical deployments can compromise door controls and security cameras.

On May 13, 2025, Ubiquiti published Security Advisory Bulletin SAB-013 covering five vulnerabilities across the UniFi OS device family that chain into unauthenticated remote code execution.

The three that matter most are an improper access control flaw and path traversal flaw in the authentication gateway, both rated CVSS 10.0 Critical, and an improper input validation flaw in the package-update service, also CVSS 10.0 Critical.

The only precondition for exploitation is access to the admin interface, which commonly listens on TCP port 443. That makes the chain reachable anywhere the web management panel is reachable.

UniFi OS Server Critical RCE Chain

The attack has three parts. Part one bypasses the authentication gateway. Nginx enforces authentication with an auth_request subrequest to the unifi-core Node service, which decides whether a request is public or must be authenticated.

The root cause is a divergence between two views of the same URI: the public-exemption check runs on the raw percent-encoded x-original-uri header, but Nginx routes the request using the normalized, decoded uri.

A crafted request whose raw form begins with the auth-exempt /api/auth/validate-sso/ prefix, while its normalized form resolves to an internal /proxy/ route, passes the gateway without any credentials.

Part two reaches the command injection sink. Behind the gateway sits a package-update route in the shared identity and update backend.

The handler builds a command string using fmt.Sprintf against a format like sudo /usr/bin/ uos runnable latest-versions % v, where % v is the caller-supplied package name interpolated verbatim.

In version 3.1.16 there is no validation of that name, and the string is passed to a helper that runs it through a sh -c shell wrapper. Shell metacharacters in the input are interpreted rather than treated as data, enabling arbitrary command injection.

Part three escalates to root. The injected command runs as the ucs-update service account, not directly as root. That account holds passwordless sudo entitlements on /usr/bin/ dpkg, /bin/ chmod, /bin/ systemctl, and /usr/bin/ uos.

BishopFox took the dpkg path on a live target, installing a .deb whose post-install script read /etc/shadow, confirming full root execution.

Patch Now and Rotate Credentials After

Ubiquiti fixed all three parts in UniFi OS Server 3.2.12. A Nginx URI-normalization guard closes the gateway bypass. The package-update backend gains a package-name allowlist and validation check to prevent injection.

The ucs-update sudoers entry drops /usr/bin/dpkg and /bin/ chmod from its passwordless list, reducing the privilege escalation surface.

Defenders should patch to UniFi OS Server 3.2.12 or later immediately, then rotate the JWT signing key, force-logout all sessions, and reset database credentials.

The chain reaches root with no credentials and no user interaction, so there is no failed-login trail in logs. Restrict external access to the web interface and limit it to a management network so unauthenticated requests from the internet cannot reach the gateway.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.