Six CVEs on the Box That Watches: Ubiquiti Patches the UniFi Protect AI Key

Ubiquiti published Security Advisory Bulletin 070 on 14 October 2026, version 1.0. It contains six CVEs, all against one product: the UniFi Protect AI Key, the plug-in module that runs on-premise inference for a UniFi Protect camera deployment — object and person detection, licence-plate reading, PPE detection, and the natural-language “AI Spotlight” search that lets an operator type a description and get matching footage. All six records reached NVD between 05:16 and 06:17 UTC on 14 October with status Received. All six are affected at version 2.2.6 and earlier and fixed in 2.2.8. All six are credited to one researcher: Andy Gill of ZephrSec Ltd.

The six

  • CVE-2026-110459 — 8.6, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H, CWE-284. Improper access control: obtain information, make unauthorized changes, and execute a denial of service on the device.
  • CVE-2026-110455 — 8.1, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-20. Improper input validation leading to command injection on the device.
  • CVE-2026-110454 — 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, CWE-284. Improper access control: access internal resources through the device.
  • CVE-2026-110456 — 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, CWE-284. Improper access control: access internal resources through the device, under certain conditions.
  • CVE-2026-110457 — 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N, CWE-22. Path traversal: obtain information about files on the device.
  • CVE-2026-110458 — 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N, CWE-22. Path traversal: create or truncate files on the device.

The vendor text is the sum total of the technical disclosure. There is no advisory detail beyond those one-line summaries, no affected endpoint, no proof of concept, and no researcher write-up published at the time of writing — a Brave Search query across the researcher’s name, the vendor and each CVE identifier returned CVE mirrors, automated scoring sites and one news aggregation, nothing first-hand. What follows is therefore an analysis of the metadata Ubiquiti chose to publish, which is more informative than it first appears.

Every record says PR:N

The single most consequential field in the bulletin is repeated six times without comment: PR:N, no privileges required, on every CVE including the command injection. Combined with AV:N and UI:N, Ubiquiti is stating that an attacker who can send packets to the AI Key needs no credential to reach any of these defects. The only brake on five of six is AC:H or the vendor’s own hedge, “under certain conditions,” which appears on four of the six summaries and is never defined.

The device is not meant to be internet-facing, so “network” here should be read as the LAN or VLAN the camera infrastructure sits on. That is a real boundary, and it is also the boundary that physical-security deployments most often get wrong: camera and NVR gear is routinely parked on a flat management network shared with badge readers, building automation and whatever else was convenient at install time. On that network the AI Key is unauthenticated.

The note the vendor added five times

Five of the six summaries carry a line Ubiquiti does not usually include: “Note: This CVE can be chained with other vulnerabilities.” It is absent only from CVE-2026-110459, the highest-scored record.

That annotation is doing the work the individual scores cannot. Read the set as a toolkit rather than six separate findings: two ways to reach internal resources through the device (110454, 110456), a path traversal that reads file metadata (110457), a path traversal that creates or truncates files (110458), and a command injection reachable “under certain conditions” (110455). A primitive that tells an attacker what exists on the filesystem and a primitive that writes to it are the usual prerequisites for turning an AC:H injection into an AC:L one. The 3.7 Low records are the interesting ones precisely because they are not interesting alone.

CVSS has no vocabulary for this and never has: each vector is scored as if the attacker arrived with nothing else. The vendor noticed the gap and patched it with English. Six scores of 8.6, 8.1, 5.3, 5.3, 3.7 and 3.7 describe a set whose realistic worst case is a single unauthenticated chain, and the only indication of that in the machine-readable record is a sentence that no scanner will parse.

What is actually on the device

Two properties of the AI Key make the command-injection record worth more than its 8.1 suggests.

First, it is a trusted component of the surveillance system rather than a peripheral. It receives video from the Protect application and returns detections and search results. Code execution on it is not just code execution on an appliance — it is a position inside the pipeline that decides what the cameras are deemed to have seen. The integrity question for a video-analytics accelerator is not only “can an attacker watch the footage” but “can an attacker influence the detections an operator acts on.” Neither the bulletin nor the CVE records make any claim about that, and we are not making one either; we are noting that the component’s function is what gives I:H on 110455 its meaning.

Second, the AI Key accepts natural-language input by design. “AI Spotlight” exists so that an operator can type a free-text description and have the device search footage against it. Any appliance that takes an arbitrary string from a user interface and routes it into an inference pipeline has a large, intentionally unconstrained input surface — and exactly one of these six CVEs is CWE-20, improper input validation leading to command injection. The bulletin does not say which input reaches the injection, and we will not guess. But the design pattern is the one this publication keeps writing up from the other direction: a string that was only ever supposed to be read as a description, reaching something that parses it as an instruction. It is the same ordering failure as the eighteen filename command-injection CVEs we covered on Tuesday, applied to a sealed consumer appliance instead of a Node module.

The firmware was already out

The fix is firmware 2.2.8, and its release thread on the Ubiquiti community site shows it was promoted to Stable/Official by the vendor’s own team well before the bulletin appeared, with community replies on the release dating to roughly a month prior. The release notes for 2.2.8 now list, under Bugfixes, a single line: “Fixed the security issues mentioned in Security Advisory Bulletin 070.” The thread is marked as edited.

So the sequence is the familiar one: ship the fix quietly in a release described as “Improved device stability,” then publish the advisory and retroactively annotate the notes. Operators on auto-update were protected weeks ago and never knew; operators who defer firmware on camera infrastructure — which is common, because an NVR reboot has physical consequences — had no severity signal to weigh that deferral against. We made the same observation about Komodo’s Periphery agent this week, where the fix predated its advisory by 76 days under a Misc. changelog bullet.

One minor oddity worth recording: the affected range stops at 2.2.6 and the fix is 2.2.8. The bulletin never accounts for 2.2.7, and we found no basis to state whether that version was unreleased, skipped, or an interim build; we are flagging the gap rather than filling it.

Remediation

Update every UniFi Protect AI Key to 2.2.8 or later. Note the dependency stated in the release notes: 2.2.8 requires UniFi Protect 7.2 or newer, so for some deployments this is a two-step upgrade of the application before the module, not a single firmware bump.

Because every record is PR:N and network-reachable, the compensating control is segmentation rather than credentials. Put Protect infrastructure on its own VLAN, allow only the Protect application to reach the AI Key, and verify that the management interface is not exposed to general user networks or to guest wireless. None of that removes the vulnerabilities; it narrows the set of hosts holding the one prerequisite the vendor’s vectors say an attacker needs, which is reachability.

If you operate a fleet, the useful action beyond patching is inventory: AI Keys are an add-on module, often installed after the NVR and tracked separately from it — or not tracked at all. A firmware version that nobody owns is the realistic reason a patched bug stays unpatched.

Reporting note: all six CVE identifiers, publication timestamps, CVSS vectors, CWE assignments, vulnStatus values and reference links were read first-hand from the NVD 2.0 API. The bulletin text, affected and fixed versions, researcher credit and chaining notes were read first-hand from Ubiquiti Security Advisory Bulletin 070. The 2.2.8 release notes, the UniFi Protect 7.2 dependency and the vendor’s promotion-to-stable post were read first-hand from the linked release thread; relative timestamps on that page are reported as approximate and are not stated as exact dates. Brave Search returned no first-hand researcher write-up. No device was acquired, no firmware was downloaded or unpacked, no AI Key was contacted, and no exploitation of any kind was attempted.

Sources: