Camera vulnerability management

Which stages of a normal vulnerability management process survive contact with an embedded video estate, and which do not.

The standard pipeline is sound. It just assumes four things a video estate does not supply: a credentialed login that enumerates installed software, a version string that matches a CPE, a vendor who files CVEs, and a patch that exists when you look. Strip those out and what remains is an inventory with a severity column attached.

A scanner needs an asset list before it can return anything, and on a video estate that list has to be built before the scan is worth running — the VMS knows the devices it records and nothing about the ones an integrator put on a different subnet in 2019, which is a programme problem the Video Attack Surface Management framework treats on its own terms. Port counts overstate populations; the 20x gap is in camera firmware and the patching problem.

The credentialed scan you cannot run#

A credentialed scan signs in to a host, enumerates installed packages and compares each one against a vulnerability database. A camera answers with a single string. That firmware build identifier is the entire software inventory the device will give you, and it is scoped to a silicon platform rather than to anything you can look up: Bosch states that "A Common Product Platform is defined mainly by the used system-on-chip (SoC)", and Hanwha builds camera firmware "based on the common platform" shared "across all camera product development", encoding versions as <PlatformMajor>.<PlatformMinor><ProductMajor>.<ProductMinor>. Those fields describe the platform and the product. They say nothing about the components compiled into the image, which is what a vulnerability database is indexed on.

Most of what is underneath belongs to someone else. Avigilon's Alta Video advisory index shows the shape of it, with the caveat that Alta Video is a cloud line and its advisories describe a service, not camera firmware. The 2026 entries there are almost entirely upstream dependency work: Go's crypto/x509 and crypto/tls, a gosaml2 forged LogoutRequest, a BusyBox ash stack overflow, redis/go-redis, a golang.org/x/crypto SSH agent panic.

The substitute for package enumeration is a bill of materials. Axis is the only vendor here shipping one with every release — "The SBOM is supplied with every device software release published on axis.com" — which is what lets a defender answer whether a given camera carries a particular upstream OpenSSL or BusyBox flaw. Hanwha publishes a standalone SBOM document, V1.0, filename-dated September 2024, on its cybersecurity page. Both are worth asking for by name at tender, because the alternative is waiting for the vendor's advisory team to decide the question for you.

Matching a finding to a device#

Hikvision's advisory of 22 July 2026 covers CVE-2026-57599, CVE-2026-57600, CVE-2026-61390, CVE-2026-61391 and CVE-2026-61392. It identifies affected products at the CVE-record level as the DS-2CD, DS-2DE, DS-2DP and DS-2TD series, and the fix is a link to a firmware download page. Nothing in a series prefix resolves to a build. A matching engine cannot use it, and neither can an engineer holding a camera, without opening the device's own interface and reading the version off it.

Then there is the case where the vendor's own paperwork disagrees with the vendor's own advisories. Dahua registered CNA-2017-0014 with the scope "Dahua consumer Internet of Things (IoT) products, excludes End-of-Life products". Its advisory DHCC-SA-202606-001 of 10 June 2026 covers NVR and XVR devices, which are its professional recorder line, as does the 18 March 2026 advisory for CVE-2025-31703. On the face of the registered scope, the CVE authority does not reach the products the advisories are about. Anyone building a matching rule that treats a CNA scope as the boundary of a vendor's CVE coverage gets Dahua's recorders wrong in whichever direction they guess.

Identifiers do not agree well enough to deduplicate across feeds either, sometimes within a single vendor's index; that survey sits in which video vendors publish security advisories.

Whether a CVE exists at all#

Nine of the twelve video vendors examined on 5 September 2026 hold CNA registrations — Axis, Hikvision, Dahua, Robert Bosch GmbH, Hanwha Vision, Genetec, Milestone, Uniview and IQSIGHT. The other three are Motorola Solutions/Avigilon, VIVOTEK and i-PRO. Verkada, checked as a thirteenth name, is not on the roster.

Registration decides eligibility, and the registered scopes contradict each other on the point that matters most to an ageing estate. A vulnerability in a discontinued Dahua product, or in an unsupported Milestone release, cannot get a CVE ID from its own vendor CNA; Axis and Hanwha register the opposite position and include end-of-life products explicitly. The four scope statements are set out side by side in which video vendors publish security advisories, and their consequence for old hardware runs through end-of-life cameras.

Absence from the roster is not the same as absence from the record. i-PRO's CVEs are assigned by JPCERT/CC and carry the jpcert assigner rather than a vendor name, so a feed reconciled by vendor attribution will file them somewhere else or drop them.

What prioritisation can carry#

CISA's KEV catalog reports observed exploitation, which no severity score does. 22 of the 1,695 entries in catalog version 2026.09.04 resolve to a video product, and for several of them the required action is to stop using the product; that population is worked through in end-of-life cameras.

Below KEV there is very little to sort a video backlog by. The nearest thing to a measured patch rate for a camera fleet is a CYFIRMA figure reported in August 2022: over 80,000 unpatched Hikvision devices out of 285,000 internet-accessible ones, about eleven months after fixes for CVE-2021-36260 shipped — roughly 28% still unpatched. Three caveats travel with that number and should travel with it every time it is quoted. The underlying whitepaper was not retrieved, so it sits one step from its primary source. The denominator counts internet-exposed devices only, an unrepresentative slice of installed cameras. And it is four years old. It remains the only quantity anyone can put next to the phrase "camera patch latency", which is useful to know before accepting a percentage from a vendor deck.

Remediation, and the gates that never reach the SLA#

Hanwha's Firmware Long-term Support Policy carries an eligibility floor that the headline five years does not mention. The policy applies to network cameras at "Firmware version 1.30 or more" and to recorders at "Firmware version 3.00 or more", and it excludes devices whose version structure is 0.00.YYMMDD outright. A device below the floor sits outside the commitment regardless of when it was discontinued. That is checkable in an afternoon against an inventory you already hold, and it will move some devices out of the remediable column before anyone plans work against them.

Bosch — IQSIGHT for video products since the February 2026 rebrand — documents a different gate. Crossing an architecture boundary means sequential flashes, because "Intermediate firmware versions introduce architectural changes and take care for compatibility when crossing over, thus are mandatory steps for upgrades and downgrades." The same document supplies the mitigation: combined firmware files can be applied repeatedly until the target version is reached, with the camera "automatically choos[ing] the next appropriate firmware version". So nobody has to work out the upgrade path by hand. Each hop is still a write and a reboot, on a device that may be six metres up a mast, and a change window sized for one reboot has been sized against the wrong operation.

None of these gates appears in the SLA table a maintenance contract is negotiated from. They appear in a support-policy PDF, an info brief and a CNA scope field, and they decide which of your findings can be closed at all. Per-model history — whether the version you are running has ever had a fix published against it — is tracked device by device at camerarisk.com.