August 28 Advisory: Ubiquiti Security Advisory Bulletin Discloses 21 Critical Vulnerabilities

Rapid Response

Vulnerability Description

On 2026-08-26, Ubiquiti published Security Advisory Bulletin 067, disclosing 22 vulnerabilities across the UniFi product line. Every affected product had a fix available at disclosure, though not every fix was new: UniFi Network 10.5.67 shipped on 23 July 2026, over a month before the bulletin named it. The bulletin spans ten products, from the UniFi OS firmware running on gateways, controllers, and recorders through the Protect, Network, Access, Talk, and Connect applications to peripheral hardware such as the Connect Display Cast Pro and the Protect AI Key. Three of the 22 carry a CVSS score of 10.0, and 21 of the 22 score 9.0 or above, with only CVE-2026-77538 (8.2) falling below that.

CVE-2026-77550 (CVSS 10.0) is an improper neutralization of CRLF sequences (CWE-93) in the web layer of devices running UniFi OS. An unauthenticated attacker who can reach the management interface over the network can inject CRLF sequences into a request to bypass authentication and reach the device as an authenticated user. Ubiquiti’s bulletin does not publish endpoint-level or root-cause detail, so the mechanism below the vulnerability class is not currently known.

CVE-2026-77549 (CVSS 9.0) is the same vulnerability class, reaching the same outcome across the same set of affected products. It differs only in requiring higher attack complexity (AC:H), but affects the same software.

The bulletin contains a set of command injection and privilege escalation bugs on the same devices that require an authenticated session, and CVE-2026-77550 hands an attacker exactly that. Where that leads depends on the product. On UniFi OS Server the authenticated flaws include command injection on the underlying host (CVE-2026-77539, CVE-2026-77540), so the end state is remote code execution, though both are PR:H and a bypass yielding an ordinary authenticated session does not automatically reach that level. On gateways, controllers and recorders, and on UniFi OS Server, the authenticated flaws are access-control failures (CVE-2026-77534, CVE-2026-77536) that take a low-privileged account to full control of the device. Either way the device ends up compromised, but the tidy bypass-then-command-injection chain belongs specifically to UniFi OS Server.

Several of the other flaws carry severity scores close to the two above, and read in isolation they look just as alarming. Based on their CVSS v3.1 vectors, each of the flaws below requires the attacker to already be authenticated to the device or application:

  • CVE-2026-77534 and CVE-2026-77536 (CVSS 9.9, PR:L): improper access control in UniFi OS. An attacker who already holds a low-privileged account on the device can escalate to full control of it.
  • CVE-2026-77539 and CVE-2026-77540 (CVSS 9.1, PR:H): improper input validation in UniFi OS Server. An attacker who already holds a high-privileged account can execute arbitrary commands on the underlying host.
  • CVE-2026-77535 and CVE-2026-77541 (CVSS 9.1, PR:H): improper input validation and improper access control in the UniFi Network Application. An attacker who already holds a high-privileged account can run commands on an adopted device or escalate privileges within the application.
  • CVE-2026-77543, CVE-2026-77546, CVE-2026-77547, and CVE-2026-77553 (all CVSS 9.9, PR:L): improper input validation and improper access control in the UniFi Access Application. An attacker who already holds a low-privileged account can run commands on, or escalate privileges on, the host device.
  • CVE-2026-77533 and CVE-2026-77548 (both CVSS 9.9, PR:L): improper input validation in the UniFi Protect Application. An attacker who already holds a low-privileged account can execute arbitrary commands on the host device.
  • CVE-2026-77542 (CVSS 9.1, PR:H): improper input validation in the UID Enterprise Agent. An attacker who already holds a high-privileged account can execute arbitrary commands on the host device.
  • CVE-2026-77545 (CVSS 9.0, PR:L): active debug code in UniFi OS. An attacker who already holds a low-privileged account can escalate privileges. This one carries two further constraints: Ubiquiti scopes it to certain conditions, and its CVSS vector requires user interaction (UI:R). Ubiquiti publishes no detail on what that interaction involves.

The bulletin also includes unauthenticated command injection in the UniFi Protect Application (CVE-2026-77537, CVSS 10.0, 828 hosts exposed) and the UniFi Talk Application (CVE-2026-77554, CVSS 10.0, 10 hosts exposed), and unauthenticated flaws in several devices that are typically LAN-side, including the UniFi Enterprise Audio/Video Bridge (CVE-2026-77552, CVSS 9.8), UniFi Protect AI Key (CVE-2026-77557, CVSS 9.8), and UniFi Connect Display Cast Pro (CVE-2026-77551, CVSS 9.0). CVE-2026-77538 (CVSS 8.2) lets an unauthenticated attacker escalate privileges within the UniFi Connect Application, and Ubiquiti notes an attacker can chain it with dependency vulnerabilities to escalate privileges on the host device.

None of these depend on the authentication bypass. CVE-2026-77537 and CVE-2026-77554 are directly exploitable by anyone who can reach those applications, and the LAN-side devices are within reach of any attacker who already has a foothold inside the network, which is exactly what a compromised gateway provides. Patch them on the same schedule as UniFi OS rather than treating them as a lower tier.

Map of Internet-facing UniFi hosts

Affected Assets

UniFi OS and device firmware:

  • UniFi OS Server 5.1.21 and earlier
  • Cloud Keys, Network Video Recorders, Enterprise Network Video Recorders, Enterprise Network Attached Storage, Dream Machines, Enterprise Firewall Core, Dream Routers, Enterprise Fortress Gateway, Cloud Gateways, Dream Wall, and UniFi Express 7: 5.1.26 and earlier
  • Network Attached Storage 5.1.26 and earlier
  • UniFi Express 4.0.16 and earlier

Applications:

  • UniFi Protect Application 7.1.87 and earlier
  • UniFi Network Application 10.4.57 and earlier
  • UniFi Access Application 4.3.3 and earlier
  • UniFi Talk Application 5.2.7 and earlier
  • UniFi Connect Application 3.24.20 and earlier
  • UID Enterprise Agent 1.61.8 and earlier

Peripheral devices:

  • UniFi Connect Display Cast Pro 1.0.108 and earlier
  • UniFi Enterprise Audio/Video Bridge 1.0.10 and earlier
  • UniFi Protect AI Key 2.1.3 and earlier

Censys-Observed Exposure

(Total hosts, not unpatched hosts) as of 27 August 2026:

  • UniFi OS management interface: 102,607 hosts (265,630 host plus web-property, not deduplicated)
  • UniFi Network Application: 52,053 hosts (148,842 combined)
  • UniFi Protect: 828 hosts
  • UniFi Talk: 10 hosts
  • UniFi Access: 0 by exact page title, 42 by body mention. Either way it is negligible.
  • Ubiquiti software detections, all products (host.services.software.vendor=”ubiquiti”): 71,161 hosts
  • Ubiquiti software detections, unifi product only: 52,067 hosts

The two software-detection figures are a separate cut and do not nest with the title-based counts above. Only 707 hosts match both html_title=”UniFi OS” and a ubiquiti software detection, because the ubiquiti:unifi annotation lands on the Network Application rather than on UniFi OS. The 71,161 also spans uisp and unifi_video, products outside this bulletin.

UniFi OS and the UniFi Network Application can run on the same appliance, so those two figures overlap and you should not sum them.

Device model mix among the hosts exposing the model manifest:

  • Dream Machine: 49,890
  • Dream Router: 6,025
  • Cloud Key: 4,838
  • Enterprise Fortress Gateway: 1,443
  • Network Video Recorder: 1,276

Top networks for the UniFi OS population:

DigitalOcean 15,638 (~15%), Comcast 6,628 (~6.5%), Charter 5,146 (~5%), AT&T 4,604 (~4.5%), Verizon Business 2,818 (~2.7%), Deutsche Telekom 2,019 (~2%), Cox 1,735 (~1.7%), Vultr 1,686 (~1.6%). Charter is split across five ASNs (CHARTER-20115, three TWC ranges, and BHN) and is aggregated here; quoting only the largest, at 2,103, would understate it roughly 2.5x and drop it below both AT&T and Verizon Business.

The population splits into self-hosted UniFi OS Server instances on cloud providers (DigitalOcean and Vultr together hold 17,324 hosts, ~17% of the exposed UniFi OS population, and are the direct surface for the UniFi OS Server CVEs 77539 and 77540) and prosumer or small-business CPE on residential ISPs. It is not predominantly enterprise infrastructure.

PoC Available?

No public proof-of-concept exists for any Bulletin 067 CVE.

While public exploit code does exist for CVE-2026-34909 and CVE-2026-34910, those belong to Ubiquiti Security Advisory Bulletin 064, published 21 May 2026, and not to this bulletin. Both bulletins concern UniFi OS, which is why some secondary coverage conflates them.

Exploitation Status:

There is currently no evidence of exploitation. None of the 22 Bulletin 067 CVEs appear in the CISA Known Exploited Vulnerabilities catalog, no one has reported exploit or threat-actor activity against any of them, and NVD has not yet completed its own analysis, so the scores it displays are Ubiquiti’s.

We should note that three recent UniFi OS vulnerabilities (CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 from Bulletin 064) entered the CISA KEV catalog on 23 June 2026, roughly a month after Ubiquiti published that bulletin, and a public detection template for one of them predated the KEV listing.

Patch Status:

Every affected product has a fix, all available as of the 26 August 2026 disclosure. Some predate it by a wide margin: UniFi Network 10.5.67 was published 23 July 2026, UniFi Connect 3.24.22 on 30 June 2026, and the Enterprise Audio/Video Bridge 1.0.11 on 22 July 2026.

UniFi OS and device firmware:

  • UniFi OS Server: 5.1.37 or later
  • Cloud Keys, Network Video Recorders, Enterprise Network Video Recorders, Enterprise Network Attached Storage, Dream Machines, Enterprise Firewall Core, Dream Routers, Enterprise Fortress Gateway, Cloud Gateways, Dream Wall, UniFi Express 7: 5.1.31 or later (the bulletin links the per-model release notes)
  • Network Attached Storage: 5.1.32 or later
  • UniFi Express: 4.0.17 or later

Applications:

  • UniFi Protect Application: 7.2.105
  • UniFi Network Application: 10.5.67
  • UniFi Access Application: 4.3.5
  • UniFi Talk Application: 5.3.2
  • UniFi Connect Application: 3.24.22
  • UID Enterprise Agent: 1.62.1

Peripheral devices:

  • UniFi Connect Display Cast Pro: 1.0.111
  • UniFi Enterprise Audio/Video Bridge: 1.0.11
  • UniFi Protect AI Key: 2.2.6

The fixed version differs by hardware family. Confirm the correct target build for each device model rather than applying one version number across a fleet.

Remediation, in priority order:

  1. Patch UniFi OS first, then the applications. Update UniFi OS Server to 5.1.37, appliances to 5.1.31 (Network Attached Storage to 5.1.32), UniFi Express 7 to 5.1.31, and UniFi Express to 4.0.17. UniFi Express and UniFi Express 7 are different products on different version lines, so check which one you have. The OS updates close the authentication bypass that makes the rest of the bulletin chainable.
  2. Enable automatic updates. Ubiquiti provides automatic updating, documented in the UniFi Updates guide. Auto-update and release channel settings live under Settings > Control Plane > Updates, where you select the console or the application. You configure adopted devices such as access points and switches within their associated application settings instead. The UniFi Site Manager gives a consolidated view across sites once signed in. A device must be online to receive an update, and these updates reboot the device, so confirm each device actually took the new build.
  3. Remove management interfaces from direct Internet exposure. This is the highest-value action beyond patching and addresses the whole class of issues rather than these 22 CVEs. Place management interfaces behind a VPN or an IP allowlist, or use Ubiquiti’s remote access service.

Censys ARC Perspective

As of 27 August 2026, Censys observes 102,607 hosts exposing a UniFi OS management interface and 52,053 hosts exposing a UniFi Network Application interface. The two can run on the same appliance, so these figures overlap and you should not sum them. Exposure for the remaining affected products is far smaller: 828 hosts for the UniFi Protect Application, 10 for UniFi Talk, and negligible or no detected exposure for UniFi Access, UniFi Connect, the UID Enterprise Agent, and the peripheral devices.

UniFi OS does not disclose its version to an unauthenticated request, so we cannot resolve any of its 102,607 hosts to a release. That figure identifies devices that are present and Internet-facing rather than devices confirmed to be unpatched.

The UniFi Network Application does expose a build identifier, however, so we can say with reasonable confidence that as of this writing, we can pin 50,841 of its 52,053 hosts (~98%) to a specific release, and so tell patched from unpatched. Of those, 45,757 are running a vulnerable build and 5,084 are running a fixed one, so roughly one in ten of the hosts we can classify has moved onto a build that carries the fix (methodology is detailed below).

From a host-based perspective, one group stands out and the remainder is a long tail. Roughly 15,640 hosts (~15%) sit in DigitalOcean and a further 1,690 (~1.6%) in Vultr, 17,324 together, about one sixth of all exposed UniFi OS hosts. That concentration is consistent with self-hosted UniFi OS Server installations, and it is the direct surface for the UniFi OS Server command injection flaws, CVE-2026-77539 and CVE-2026-77540.

Everything else is spread thin across consumer and small-business ISPs, with no single network above 6.5 percent: Comcast at roughly 6,630, Charter at 5,150 across its five ASNs, AT&T at 4,600, Verizon Business at 2,820, Deutsche Telekom at 2,020, and Cox at 1,740. Those six together are about 22 percent of the population, and beyond the twenty largest networks a further 57,000 hosts sit in no network big enough to name. The shape of that tail is the finding: this is prosumer and small-business customer premises equipment far more than it is enterprise infrastructure.

The United States holds roughly half the exposure at 50,900 hosts, followed by the United Kingdom at 6,550 (~6.4%), Germany at 6,200 (~6%), the Netherlands at 4,290 (~4.2%), Canada at 4,100 (~4%), and Australia at 3,200 (~3.1%).

The Dream Machine family leads the exposed UniFi OS population at roughly 49,890 hosts (~49%), then Dream Router at 6,030 (~5.9%), Cloud Key at 4,840 (~4.7%), Enterprise Fortress Gateway at 1,440 (~1.4%), and Network Video Recorder at 1,280 (~1.2%). This matters operationally because Ubiquiti assigns a different fixed version per hardware family, so the model determines which build a given device needs.

Reading a version out of a release without downloading it. UniFi OS carries no version signal, but the UniFi Network Application login page embeds a per-build asset path of the form angular/g<hash>, where the hash is the git short hash of the web-app build (seven hex characters on older builds, nine on newer). It identifies the release exactly, provided you know which release the hash belongs to. Building that lookup means opening the official release package for each version, and those packages are about 130 MB each.

But! We don’t actually have to download them in full! We discovered that, because a Debian package is an ar archive whose members appear in a fixed order, we can extract only the portion we need. A 60-byte header precedes each member, carrying that member’s size at bytes 48 through 57. From the first 512 bytes you can therefore compute exactly where the compressed payload begins. A tar stream is then a sequence of 512-byte headers naming paths, so listing a truncated stream still yields every entry it reached before the data ran out. Two ranged requests totalling about 80 KB replace a 130 MB download, a reduction of over 1,500x:

#!/usr/bin/env ruby
# frozen_string_literal: true

# Read the build hash out of a UniFi Network release without downloading the
# ~130 MB package. Two ranged GETs totalling about 80 KB do the same job.
#
#   ./unifi_build_hash.rb 10.5.67 10.4.57

require 'httparty'
require 'tempfile'

AR_MAGIC = "!<arch>\n"
AR_HEADER = 60
TAR_BLOCK = 512
WINDOW = 80 * 1024

# A ranged GET. A server honoring Range replies 206; a 200 means it ignored
# the header and is sending the whole file, which defeats the point entirely.
def fetch_range(url, first, last)
  res = HTTParty.get(url, headers: { 'Range' => "bytes=#{first}-#{last}" })
  abort("#{url}: server ignored Range and sent the whole file") if res.code == 200
  abort("#{url}: HTTP #{res.code}") unless res.code == 206

  res.body.dup.force_encoding(Encoding::BINARY)
end

# An ar member header is 60 bytes: name at 0, payload size at 48. Payloads are
# padded to an even offset. Returns the size and where the payload starts.
def ar_header(bytes, offset)
  header = bytes.byteslice(offset, AR_HEADER)
  abort('truncated ar header') if header.nil? || header.bytesize < AR_HEADER
  size = Integer(header.byteslice(48, 10).strip, 10)
  { name: header.byteslice(0, 16).strip.delete_suffix('/'),
    size: size,
    payload: offset + AR_HEADER,
    following: offset + AR_HEADER + size + (size % 2) }

end

# Walk 512-byte tar headers, yielding entry names. The stream is deliberately
# truncated, so stop cleanly as soon as a block comes up short.
def each_tar_name(io)
  loop do
    block = io.read(TAR_BLOCK)
    break if block.nil? || block.bytesize < TAR_BLOCK

    name = block.byteslice(0, 100).delete("\0").strip
    break if name.empty? # zero block marks end of archive

    yield name

    octal = block.byteslice(124, 12).delete("\0").strip
    size = octal.empty? ? 0 : Integer(octal, 8)
    io.read(size + (-size % TAR_BLOCK)) # skip content, padded to a whole block
  end
end

# xz has no stdlib binding, so decompress through the system binary. Feeding it
# a truncated stream makes it exit non-zero, which is expected and ignored.
# The chunk goes to a temp file rather than a pipe: we stop reading as soon as
# the path turns up, and a writer thread would then block on a full pipe.
def first_matching_path(compressed, pattern)
  Tempfile.create(['unifi-chunk', '.xz']) do |tmp|
    tmp.binmode
    tmp.write(compressed)
    tmp.flush

    IO.popen(['xz', '--decompress', '--stdout', tmp.path], 'rb', err: File::NULL) do |xz|
      begin
        each_tar_name(xz) do |name|
          return Regexp.last_match(1) if name.match(pattern)
        end
      rescue Errno::EPIPE, IOError
        nil
      ensure
        begin
          Process.kill('TERM', xz.pid)
        rescue Errno::ESRCH
          nil
        end
      end
    end
  end
  nil
end

def build_hash(version)
  url = "https://dl.ui.com/unifi/#{version}/unifi_sysvinit_all.deb"

  # The first 512 bytes cover debian-binary and control.tar, which is all we
  # need to locate data.tar. Its own header sits past that window, so fetch it
  # as the first 60 bytes of the second request rather than spending a third.
  head = fetch_range(url, 0, 511)
  abort("#{version}: not a .deb (bad ar magic)") unless head.start_with?(AR_MAGIC)

  control = ar_header(head, ar_header(head, AR_MAGIC.bytesize)[:following])
  chunk = fetch_range(url, control[:following], control[:following] + AR_HEADER + WINDOW - 1)

  data = ar_header(chunk, 0)
  abort("#{version}: expected data.tar, found #{data[:name]}") unless data[:name].start_with?('data.tar')

  first_matching_path(chunk.byteslice(AR_HEADER..), %r{(angular/g[0-9a-f]{6,})})
end

if $PROGRAM_NAME == __FILE__
  abort("usage: #{$PROGRAM_NAME} <version> [version...]") if ARGV.empty?
  ARGV.each { |version| puts "#{version} #{build_hash(version) || 'NONE'}" }
end

Run against the two builds that matter for this bulletin:

$ ./unifi_build_hash.rb 10.5.67 10.4.57
10.5.67 angular/ga6a9fe0fa
10.4.57 angular/g19f85adec

Patch adoption in the UniFi Network Application. Where we have mapped a build hash to a release, the version reading is exact rather than inferred. We have now mapped 160 distinct build hashes, covering 50,841 of the 52,053 hosts observed running the UniFi Network Application, or 97.7 percent of the population.

HostsShare of mapped
Running a vulnerable build45,75790.0%
Running a fixed build5,08410.0%
Total mapped50,84197.7% of population

The mapped set spans 5.13.29 through 10.6.101. Twelve of those releases carry the fix: 10.5.67 and the eleven 10.6.x builds. The other 148 sit below it. The tail is long and shallow, with 6.x and 7.x builds still live in the low hundreds each, which suggests a meaningful slice of this population has not updated in years and is unlikely to respond to this advisory either.

To determine the actual cut-off for vulnerable versions, we had to read between the lines a bit since Ubiquiti describes it two different ways. The bulletin text names “10.4.57 and earlier” as affected, which leaves a whole band in limbo: twelve mapped releases sit between 10.4.57 and the fix, from 10.5.28 up to 10.5.66, newer than anything the prose calls vulnerable and older than the release that carries the fix. The CSAF advisories for CVE-2026-77535 and CVE-2026-77541 settle it. Both give the affected range as vers:semver/<10.5.67, so everything below 10.5.67 is affected, 10.5.66 included.

Patching over the first 16 hours. As a small experiment, we sampled the build hashes hourly from 26 August 2026 22:58 UTC to 27 August 2026 15:04 UTC, 17 samples spanning 16.1 hours. We tracked six builds: 10.5.67, which carries the fix, and five widely-deployed vulnerable builds: 10.4.57, 9.4.19, 9.1.120, 8.6.9, and 9.3.45. Those five were the largest known when the sampling started; mapping since has surfaced others of comparable size, such as 10.0.162 at 3,376 hosts. The count on 10.5.67 rose steadily while the tracked vulnerable builds fell. Seven of the seventeen samples are shown below; the movement is monotonic across all of them:

Sample (UTC)Five vulnerable builds10.5.67
2026-08-26 22:5813,4662,674
2026-08-27 00:5912,8203,357
2026-08-27 02:5912,3873,797
2026-08-27 05:0011,9874,191
2026-08-27 08:0111,6564,530
2026-08-27 11:0311,3734,791
2026-08-27 15:0411,1924,976

Over the full window, the five vulnerable builds shed 2,274 hosts while 10.5.67 gained 2,302, a mean of roughly 142 hosts an hour. The rate was fastest immediately after disclosure and flattened steadily: about 320 to 340 hosts per hour over the first two hours, against about 30 per hour over the last two. Measured directly as deduplicated hosts, 10.5.67 went from 2,436 on the evening of disclosure to 4,984 the following morning, slightly more than doubling.

The two lines are near mirror images of each other, which is what happens when a device upgrades in place and not what happens when hosts drop out of the scan and others appear. A control tells the same story: a sixth build hash, tracked purely as a reference point and since mapped to 7.2.97, stayed between 2,894 and 2,906 across all 17 samples, a spread of twelve hosts while the tracked builds moved by thousands. The size of the population barely shifted either, drifting 128 hosts across the whole window.

One caveat on the hourly series: the counts are service-level rather than deduplicated hosts. In practice the two track each other closely, with 10.5.67 at 4,976 service-level against 4,984 hosts at the end of the window and the control hash at 2,897 against 2,903, so the series is reliable for the shape and rate of the curve. The figures quoted elsewhere in this section are the deduplicated host counts.

Limitations:

  • Coverage is 97.7 percent of the population, and 99.7 percent of the hosts that can be read at all. 50,992 of the 52,053 UniFi Network hosts expose a build identifier, and 50,841 of those resolve to a known release. Only about 150 hosts advertise a build that is not yet in the map. The other 1,061 expose no build identifier at all. The asset path was introduced in 5.13, and releases before it emit nothing to read, so no refinement of this method reaches those hosts. They are not ambiguous so much as old: an older UI generation marker appears on 99.4 percent of them, against 0.05 percent of the hosts that do carry a hash. They predate the build-hash era, which means the unclassified remainder almost certainly skews vulnerable rather than sitting evenly across the split, and the 90/10 figure is if anything conservative.
  • This says nothing about the headline vulnerability. The split applies only to the UniFi Network Application. CVE-2026-77550 and CVE-2026-77549 are UniFi OS flaws, and UniFi OS exposes no version signal anywhere in its unauthenticated surface, so the 102,607-host figure remains a product-presence superset.
  • The patched baseline predates the bulletin. 10.5.67 shipped before Ubiquiti published the advisory, so the 2,183 hosts already on it on the morning of disclosure were not responding to it. The meaningful measure is the movement since, not the absolute patched count.
  • A host’s record changes only when Censys rescans it, so the true movement may lead or lag what this shows.
  • These figures describe a single point in time and will drift as Censys rescans devices and as operators patch them.

Censys Queries

Platform:

host.services.endpoints.http.html_title={"UniFi OS", "UniFi Network", "UniFi Protect", "UniFi Talk", "UniFi Access", "UniFi Connect"}

ASM:

host.services.software:(vendor:"Ubiquiti") or web_entity.instances.software:(vendor:"Ubiquiti") or host.services.http.response.html_title: {"UniFi OS", "UniFi Network", "UniFi Protect", "UniFi Talk", "UniFi Access", "UniFi Connect"} or web_entity.instances.http.response.html_title: {"UniFi OS", "UniFi Network", "UniFi Protect", "UniFi Talk", "UniFi Access", "UniFi Connect"}

Legacy Search:

(services.software.vendor: "Ubiquiti" and services.software.product: {"UniFi OS", "UniFi Network", "UniFi Protect", "UniFi Talk"}) or services.http.response.html_title: {"UniFi OS", "UniFi Network", "UniFi Protect", "UniFi Talk", "UniFi Access", "UniFi Connect"}

References

https://dl.ui.com/unifi/10.4.57/unifi_sysvinit_all.deb (UniFi Network 10.4.57 package, source for the vulnerable-build hash)

https://community.ui.com/releases/Security-Advisory-Bulletin-067/fc4a3488-7c43-4628-8bab-f715e96dbfc9 (Ubiquiti Security Advisory Bulletin 067)

https://euvd.enisa.europa.eu/enisa/EUVD-2026-66399 (ENISA EUVD entry)

https://www.cve.org/CVERecord?id=CVE-2026-77550 (CVE Record)

https://nvd.nist.gov/vuln/detail/CVE-2026-77550 (NVD, analysis pending)

https://vulnerabilities.ncsc.nl/csaf/v2/2026/cve-2026-77535.json (CSAF advisory, UniFi Network affected range)

https://vulnerabilities.ncsc.nl/csaf/v2/2026/cve-2026-77541.json (CSAF advisory, UniFi Network affected range)

https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-3028 (CERT-Bund advisory)

https://www.bleepingcomputer.com/news/security/ubiquiti-patches-three-max-severity-security-vulnerabilities/ (BleepingComputer coverage)

https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CISA KEV, none of these CVEs listed)

https://help.ui.com/hc/en-us/articles/7605005245975-UniFi-Updates (UniFi Updates, auto-update and release channels)

https://unifi.ui.com (UniFi Site Manager sign-in; the consolidated update view sits behind it)

https://nvd.nist.gov/vuln/detail/CVE-2026-77549 (NVD, second auth bypass)

https://nvd.nist.gov/vuln/detail/CVE-2026-77537 (NVD, unauthenticated command injection in UniFi Protect)

https://nvd.nist.gov/vuln/detail/CVE-2026-77554 (NVD, unauthenticated command injection in UniFi Talk)

https://www.cve.org/CVERecord?id=CVE-2026-77549 (CVE Record, second auth bypass)

https://cwe.mitre.org/data/definitions/93.html (CWE-93, improper neutralization of CRLF sequences)

https://www.first.org/cvss/v3-1/specification-document (CVSS v3.1 specification, for the PR / AC / UI vector claims)

https://dl.ui.com/unifi/10.5.67/unifi_sysvinit_all.deb (UniFi Network 10.5.67 package, source for the fixed-build hash)

Share
Back to resource hub

US: +1-888-985-5547

Intl: +1-877-438-9159

connect@censys.com

Subscribe to our newsletter

Subscribe to our newsletter

Copyright © 2026 Censys  |  Data Retention Policy  |  Terms & Conditions  |  Privacy Policy  |  Brand