CVE-2026-77550 (CVSS 10.0): Ubiquiti Patches 21 Critical UniFi Flaws — Three Authentication-Free Exploits Expose Cameras, VoIP, and Network OS to Unauthenticated Takeover

If your organisation runs Ubiquiti UniFi hardware — and with over 100 million devices shipped worldwide, the odds are very good that it does — you need to act on this immediately. On 26 August 2026, Ubiquiti released a security bulletin disclosing 22 vulnerabilities across its UniFi ecosystem, 21 of which are rated Critical (CVSS 9.0 or above). Three of them carry the maximum possible score of CVSS 10.0, meaning an unauthenticated attacker anywhere on your network can seize full control of your surveillance cameras, your VoIP phone system, and the operating system that runs nearly every UniFi device — without a single valid credential.

Ubiquiti’s reach is vast. The UniFi platform is the backbone of network infrastructure in SMBs, enterprise campus networks, hospitality chains, hospitals, and government offices across India and the world. These are not obscure edge-case flaws — they are remote code execution and authentication-bypass vulnerabilities targeting the very equipment that controls who sees what, who speaks to whom, and who gets on your network.

Why Ubiquiti Is a Prime Target in 2026

Sources and further reading: CyberScoop · SecurityWeek · NVD CVE-2026-77550 · NVD CVE-2026-77537 · NVD CVE-2026-77554 · CISA KEV Catalog

Ubiquiti built its market position on one proposition: enterprise-grade features at SMB-friendly prices. That pricing model drove massive adoption across India’s fast-growing mid-market — from Bangalore tech parks to Delhi NCR corporate campuses, from Mumbai co-working hubs to Tier-2 city manufacturing floors. The result is a sprawling install base of UniFi switches, access points, gateways, security cameras (UniFi Protect), and VoIP systems (UniFi Talk) — often managed by lean IT teams with limited patching cycles.

That combination — ubiquity, network-edge positioning, and deferred patching — makes UniFi infrastructure an attacker’s dream. When CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 (all CVSS 10.0) were disclosed in May 2026, threat actors were observed creating rogue administrator accounts (notably under the username “John Sim”) within days of a proof-of-concept being published. CISA added all three to the Known Exploited Vulnerabilities catalog on 23 June, requiring federal agencies to patch within 72 hours. The same pattern is likely to unfold again.

Technical Breakdown: The Three CVSS 10.0 Vulnerabilities

Understanding how these flaws work is critical to assessing your exposure and prioritising the response.

CVE ID	CVSS	Component	Vulnerability Type	Impact	Fixed In
CVE-2026-77537	10.0	UniFi Protect	Improper Input Validation → RCE	Unauthenticated arbitrary code execution on camera management platform	Protect 7.2.105
CVE-2026-77550	10.0	UniFi OS	CRLF Injection → Auth Bypass	Attacker bypasses authentication on any UniFi OS device or instance	UniFi OS 5.x
CVE-2026-77554	10.0	UniFi Talk	Improper Input Validation → Command Injection	Unauthenticated OS-level command execution via VoIP system	Talk 5.3.2

CVE-2026-77537 — UniFi Protect: Your Cameras as an Entry Point

UniFi Protect is Ubiquiti’s video surveillance management platform, running on UniFi OS Consoles (Dream Machine, CloudKey Gen 2+, UNVR). CVE-2026-77537 is an improper input validation vulnerability: a crafted request to the Protect API can pass unsanitised data into a backend process, allowing the attacker to inject and execute arbitrary code at the application layer — all without authentication. In a typical enterprise deployment, the Protect console has credentials to every camera, motion zone, and access event on the property. A fully compromised Protect instance means an attacker can disable cameras, exfiltrate footage, or pivot deeper into the management network.

CVE-2026-77550 — UniFi OS: CRLF Injection Breaks the Front Door

This is arguably the most dangerous of the three because it targets UniFi OS itself — the foundational operating layer shared across Dream Machine Pro, Cloud Gateway Ultra, and most modern UniFi consoles. A CRLF (Carriage Return Line Feed) injection vulnerability in the authentication flow means that a carefully crafted HTTP request can smuggle extra headers or response lines past the NGINX authentication gateway. The effect: the attacker reaches internal, authenticated API routes without ever providing a valid username or password. This mirrors the authentication bypass pattern seen with CVE-2026-34908 in May 2026, which BishopFox confirmed was trivially exploitable against version 5.0.6.

CVE-2026-77554 — UniFi Talk: VoIP as a Backdoor

The UniFi Talk VoIP system is often overlooked in security audits — it’s “just phones.” CVE-2026-77554 exploits improper input validation in the Talk Application to inject OS-level commands, again without credentials. An attacker who compromises the Talk server gains a foothold on the UniFi OS Console, with access to routing configuration, firewall rules, and the management plane of the entire network segment. In environments where VoIP and network management share infrastructure — which is precisely Ubiquiti’s design model — this is a full network compromise from an unexpected angle.

The 18 Additional Critical Flaws: Not Small Print

Beyond the three CVSS 10.0 vulnerabilities, Ubiquiti disclosed 18 further Critical-rated flaws (CVSS 9.0–9.9) covering authentication bypass, privilege escalation, and additional command-injection vectors across the broader UniFi product line. Ubiquiti released its security bulletin without detailed technical commentary, a practice that limits attacker insight in the short term but also limits defenders’ ability to prioritise beyond the headline CVEs. The prudent assumption is that every one of the 21 Critical issues can be weaponised once researchers begin publishing analyses.

What You Should Do Right Now — Sanjay Seth’s Expert View

In my 30 years in cybersecurity — including building and auditing networks for enterprises across India — I have watched the same pattern play out with network-edge devices: disclosure, researcher interest, PoC release, mass exploitation, then panicked remediation under fire. You have a window right now. Do not waste it.

1. Inventory every UniFi device immediately. Log into your UniFi Network Application and enumerate all managed consoles, access points, switches, cameras, and Talk phones. Identify any running UniFi OS below 5.x, UniFi Protect below 7.2.105, or UniFi Talk below 5.3.2.
2. Apply patches before any other task today. The UniFi controller will offer updates through Settings → System → Updates. For air-gapped or manually managed environments, download the packages directly from ui.com.
3. Isolate management interfaces from production networks. If your UniFi console is reachable from the same flat network as your workstations or guest Wi-Fi, that is a zero-trust failure. Place management interfaces on a dedicated VLAN with strict ACLs. Access should require jump-host authentication or VPN — never direct exposure.
4. Review and rotate credentials on all UniFi accounts. If you have not patched promptly in the past, assume that prior exploitation (especially the May 2026 wave) may have created rogue administrator accounts. Audit the admin user list and remove unfamiliar entries.
5. Enable multi-factor authentication on the UniFi identity portal. This is a minimum bar that far too many organisations skip, assuming network-edge positioning is sufficient protection. It is not.
6. Monitor for post-exploitation indicators. Look for unexpected admin account creations, configuration changes to firewall or VLAN rules, new port forwarding entries, unusual outbound connections from management consoles, and camera accessibility changes.
7. Check third-party integrations. Many organisations integrate UniFi with building management, access control, and SIEM platforms. Validate that these integrations cannot serve as pivot points after a console compromise.

For organisations running hybrid environments — FortiGate at the perimeter, Ubiquiti in the campus interior — the risk is compounded. A compromised UniFi management console can provide an attacker with the network topology, VLAN segmentation, and firewall rule maps that make subsequent perimeter exploitation far easier. We covered a similar north-south pivot scenario in our analysis of the Gunra RaaS FortiGate campaign, and again when examining The Gentlemen ransomware’s targeting of Indian FortiGate deployments. The message is consistent: your management plane is your most valuable target, and it is often your least-defended one.

The Zero-Trust Angle: Why These Flaws Are a Symptom, Not Just a Bug

The core reason CVE-2026-77537, CVE-2026-77550, and CVE-2026-77554 carry a maximum severity rating is not just their technical severity — it is the trust architecture they operate within. In organisations that have not implemented zero-trust principles, a single compromised UniFi console grants an attacker implicit access to network management, camera feeds, VoIP infrastructure, and potentially the firewall management plane.

Zero-trust mandates that no implicit trust is granted based on network location. Every access request — even from a management console — must be authenticated, authorised, and continuously validated. That means:

• Management plane access gated by MFA and device posture checks
• Micro-segmentation separating camera networks from management VLANs from production networks
• Continuous monitoring of management API calls, with anomaly detection for bulk configuration changes
• Least-privilege service accounts for integrations — never domain admin credentials running on a UniFi console

These are not aspirational controls. They are the baseline that prevents a network-edge device vulnerability from becoming an enterprise-wide ransomware incident.

Frequently Asked Questions

Are these vulnerabilities being exploited in the wild right now?

As of the publication of this post (27 August 2026), Ubiquiti has not confirmed active in-the-wild exploitation of CVE-2026-77537, CVE-2026-77550, or CVE-2026-77554. However, the company released no technical details that would help defenders detect exploitation attempts, and security researchers will begin reverse-engineering the patches immediately. Given that Ubiquiti’s May 2026 CVSS 10.0 vulnerabilities were exploited within days of a PoC being published, the window before exploitation begins is likely measured in days, not weeks.

Which UniFi devices are affected?

CVE-2026-77550 affects UniFi OS devices and instances running software below version 5.x — this includes Dream Machine Pro, Cloud Gateway Ultra, Dream Router, and CloudKey Gen 2+ among others. CVE-2026-77537 affects all UniFi Protect Application deployments below version 7.2.105. CVE-2026-77554 affects UniFi Talk Application below version 5.3.2. Legacy UniFi products running non-UniFi-OS firmware (older USG, EdgeOS devices) may not be in scope for these specific CVEs, but should still be reviewed against the full advisory.

We don’t expose our UniFi management to the internet — are we still at risk?

Yes. All three CVSS 10.0 vulnerabilities require only network access — not internet access. Any device on the same LAN or VLAN as the vulnerable service can exploit these flaws without credentials. This means a compromised endpoint, a rogue device on guest Wi-Fi (if improperly segmented), or an insider threat can launch a successful attack. The “not internet-exposed” assumption is a common false comfort that does not hold against these vulnerability classes.

Can we use Ubiquiti’s cloud management to apply patches remotely?

Yes. If your devices are managed through UniFi Site Manager or the UniFi cloud portal, you can push firmware updates remotely. Navigate to your console device, select the device in the portal, and check for available updates. For self-hosted UniFi Network Application deployments, update the application software first (to a version that serves the patched firmware), then upgrade device firmware through the application’s update mechanism. Validate that the update completes and the correct version string is shown before marking the device as remediated.

---