About VideoSOC

VideoSOC tracks vulnerabilities and confirmed exploitation in cameras, recorders and video-management platforms using NVD, CISA KEV and FIRST EPSS, and records where that public record runs out.

Three kinds of page live here. The CVE tracker and the weekly brief are generated: a pipeline pulls vulnerability records from public databases, filters them to video products, and publishes what it finds along with a count of what it threw away. Advisories are written by hand, one vulnerability or cluster at a time. The vendor PSIRT directory is neither — it is a record of what thirteen vendors' own disclosure pages said on the day we read them.

This is a young site. Four advisories exist, covering eight CVEs, against 1,279 in the tracker. The written coverage is not a survey of the field and is not trying to be; it goes where the generated data alone would mislead you.

Where the data comes from#

Three upstream feeds and one hand-compiled directory, each dated on every page that uses it.

NVD, through the CVE API 2.0. The CVE records themselves: description, CVSS vectors, weakness classification, references, and the CPE configuration stating which products a vulnerability applies to. The current build queried 82 CPE vendor namespaces and holds 1,279 published vulnerabilities across 3,293 products from 69 of the 74 vendors we track.

CISA's Known Exploited Vulnerabilities catalogue, version 2026.09.04, released 2026-09-04 at 16:47 UTC with 1,695 entries. Twenty-two of them match a CVE in our dataset. Two of those twenty-two are catalogued by CISA against something other than a video product — CVE-2021-3156 against sudo, CVE-2023-38950 against ZKTeco BioTime — and reach our set through the CPE record of a device that ships the component. That is the mapping working, not a filtering error, and we write about it. CISA requires three things for inclusion: an assigned CVE ID, reliable evidence that malicious code was executed on a system without the owner's permission — not a proof of concept, not a researcher's demo — and a clear remediation action. That third criterion matters here. A flaw in a device nobody will ever patch can meet the exploitation bar and still not qualify.

FIRST EPSS, scores calculated 2026-09-04, covering 1,279 of the 1,279 CVEs we hold. EPSS estimates the probability that a vulnerability will see exploitation activity in the next 30 days. It is a model output, it moves daily, and it is labelled as a forecast everywhere it appears here. A high score says something about the shape of the vulnerability, not about your estate.

The CVE Program's CNA roster and the vendors' own pages. CNAsList.json, fetched 2026-09-05, listing 544 organisations up to CNA-2026-0062, read alongside thirteen vendors' published advisory indexes and disclosure policies on the same date. That combination is the PSIRT directory. Nothing in it is inferred; each field records what was visible on 2026-09-05, and several of the observations are that the page could not be read.

What an advisory here adds#

Vendor advisories are written to be defensible, and they are usually accurate about the fix. What they omit varies, and the omission is rarely the fix. Axis is at the disclosing end of the range: on 2026-09-05 its security registry listed CVE-2026-13312 at CVSS 9.9 for AXIS Camera Station with the released version shown as "TBA" and an external disclosure date of 10 November 2026. A score and a product, published deliberately ahead of both the patch and the technical detail. It still does not tell you whether reaching the affected interface needs a credential, a network position, or nothing at all — and that is the vendor being unusually forthcoming.

NVD has the opposite problem. A CPE list tells you which product strings were named in a CVE record. It does not tell you that the same firmware ships under four OEM brand names, that the vulnerable service is off by default in one product family and on by default in another, or that the device was discontinued and will never receive a patch.

An advisory here tries to close that gap on four questions: what an attacker actually needs, what the realistic damage is when they get it, what the evidence for exploitation genuinely is, and what to do if patching is not available to you this quarter. Where a claim is fact, it is sourced. Where it is inference, the sentence carries a literal Inference, not fact marker — including on this page, below.

Revisions#

An advisory keeps its URL for its life. Substantive changes add a dated entry to the revision history printed at the foot of the page, and where a correction is made, the entry says what was wrong. That is the policy rather than a record: all four advisories currently carry a single entry reading "First published", all dated 2026-09-05.

Two fields in the facts panel at the top of each advisory — the CVSS severity and the EPSS score — are regenerated from the dataset at build time rather than typed into the prose. Exploitation status is regenerated when a CVE is in KEV; where it is not, the field shows what an editor last wrote, and that is a weakness we have not fixed. Patch state is written by hand. Check the revision date at the foot of the page before trusting either.

Scope#

Video infrastructure: IP cameras, NVRs, DVRs and hybrid recorders, video-management platforms, encoders and decoders, and the access-control equipment that shares the same VLAN as all of it. That last inclusion is an editorial judgement about what a reader with a camera estate also owns. It is not a finding — we hold no incident data and nothing here measures how often a compromised camera reaches a door controller.

The generated tracker's product filter is video-shaped, and for vendors that sell video alongside other things it matches on explicit patterns rather than taking the whole namespace. The current build excluded 6,089 products across 19 vendors as out of scope: 1,760 at Schneider Electric, 1,104 at NETGEAR, 1,030 at TP-Link, 847 at D-Link. The dataset stores a truncated sample of each exclusion list rather than the whole of it, and in those samples the excluded names are predominantly routers, access points, NAS enclosures and building controllers — a characterisation of the samples, not a classification of all 6,089. Bosch's access_easy_controller is among the excluded. So access control appears in written advisories where it matters and does not reliably appear in the automated tracker. The filter will have false negatives we have not enumerated.

Limits#

Start with what the record does establish. Where a vendor holds CNA status and the product sits inside its registered scope, an empty CVE record carries real information: eight of the nine CNAs in our directory — Axis, Hikvision, Dahua, Hanwha Vision, Bosch, Genetec, Milestone and Uniview — carry CVE identifiers on their published advisories, IQSIGHT being the exception, and for supported products in those lines the public record is a reasonable proxy for what is known.

The problem is how narrow that condition is. Of the thirteen entries in our PSIRT directory — twelve video vendors plus Robert Bosch GmbH, listed because the video business was divested to IQSIGHT — nine hold CNA status and four do not. The registered scopes then disagree on the question that matters most for a long-lived estate. Dahua's covers "consumer Internet of Things (IoT) products" and excludes end-of-life, wording that on its face does not reach the professional NVR and XVR line its own advisories address; Axis registers all products including end-of-life, and its vulnerability-management policy then puts anything in the "Discontinued product. Online support only" phase back out of it. The other scopes are quoted verbatim, with their caveats, on the directory page.

Among the four that are not CNAs, Avigilon publishes 216 advisories inside its Alta Video product documentation, none carrying a CVE identifier; for the on-premise Unity and Control Center line we found no public advisory listing at all. Verkada is the largest cloud-native vendor in the set and has no discoverable advisory page. Its Vulnerability Disclosure Program page exists but serves a client-side Bugcrowd embed, so its scope, timelines and safe-harbour wording could not be read.

Inference, not fact. A ten-year-old recorder with a clean CVE record is more likely to be a recorder nobody was obliged to file against than a recorder nobody found a bug in. Nothing in our sources establishes that. It follows from the scope wording above, and it should carry the weight of reasoning rather than evidence.

KEV has the same shape of gap for a different reason. It records what reached CISA and cleared an evidence bar that is high on purpose. Of the 1,695 entries in the 2026.09.04 catalogue, 22 match a CVE in our dataset. Treat that as a floor — a count of what has been documented to a federal standard, which is a much smaller quantity than what has happened.

Version lists on these pages come from what CVE records named. A firmware version absent from a product page has not been tested by anyone we can cite, in either direction.

Five of the 74 vendors we track returned no in-scope vulnerability at all in the current build: eufy/Anker, Western Digital, Ubiquiti, Xiaomi and DoorBird. That is a statement about the public record for the products our filter matched.

We do not scan the internet, run sensors, or hold incident data, so we have no independent visibility into whether anything is being exploited in your estate. We publish no exploit code, no victim names, and no incident narrative we cannot source to a named primary document. Pages here carry no personal bylines.

Corrections are made in place, with a revision entry saying what changed: desk@videosoc.com.

Who publishes this#

VideoSOC is published by the same small editorial project as three related sites: VideoCybersecurity for reference guides, CameraRisk for per-product vulnerability history, and VideoASM for the attack-surface framework.

Common ownership between linked sites should be disclosed rather than inferred, so it is stated here. The four share a sourcing standard and the build system underneath them. They do not share content, and no site-wide link block runs between them — cross-links appear only where following one is the next thing a reader would want.

Sources

  1. NVD CVE API 2.0 — developer documentation. NIST National Vulnerability Database, retrieved 2026-09-05
  2. Known Exploited Vulnerabilities Catalog — inclusion criteria. CISA, retrieved 2026-09-05
  3. EPSS — Exploit Prediction Scoring System. FIRST, retrieved 2026-09-05
  4. CVE Program CNA partner roster (CNAsList.json). CVE Program, observed 2026-09-05