Report 125 · Luxury Home Security
I have written before about cameras with a critical flaw and no patch coming. This is a different problem, and in some ways a worse one. Read three 2026 CISA advisories side by side and the defining failure is not a coding mistake at all. It is that the camera was never asking who you were. There is no exploit to write. You request the image and the camera sends it.
There is a category error buried in how we talk about camera security, and it costs people real money. The word "vulnerability" implies a mistake: someone wrote a buffer overflow, someone forgot to sanitize an input, and a sufficiently clever attacker with a sufficiently clever payload can pry it open. That framing makes the threat feel distant. It requires an adversary with skill.
Some of what CISA published about surveillance cameras this year is not that. In three separate 2026 advisories, the finding is that a network endpoint on the camera does not check credentials, or that the credentials it checks are the same on every unit and printed in the firmware. Those are not mistakes in the ordinary sense. They are design decisions that shipped.
I want to walk through the three, because the pattern they form is more useful than any one of them, and because the practical response is different from the response to a normal patch cycle.
On 11 June 2026, CISA published an advisory covering Brickcom Cube, Dome, Bullet and Box cameras at firmware 3.2.3.5.6. Two CVEs. The first, CVE-2026-50245, is described this way:
The affected product allows unauthenticated access to live snapshot images via the /ONVIF endpoint and no authentication is required to retrieve still images from the camera feed.
Read that twice. The camera exposes a URL. Requesting the URL returns a current still image from the camera. There is no authentication step to defeat, because there is no authentication step. The second CVE, CVE-2026-50005, is the companion problem: the product "ships with default credentials that allows any unauthenticated remote attacker to silently access camera feeds."
CISA scored the pair 8.3 on CVSS v4.0 and 7.7 on v3.1, both HIGH. Their risk statement is that successful exploitation "could allow a remote unauthenticated attacker to gain unauthorized access to live video feeds, retrieve sensitive visual information from affected premises, and obtain administrative control of the device."
The mitigation line is the part that should decide your purchasing policy. CISA writes that "Brickcom did not respond to CISAs request for coordination. Users are encouraged to reach out to Brickcom for support." That is the federal government telling you it tried to reach the manufacturer of a camera watching your house, and got nothing back.
On 19 May 2026, CISA published ICSA-26-139-04 covering ZKTeco CCTV cameras, specifically the SSC335-GC2063-Face-0b77 solution prior to firmware V5.0.1.2.20260421. One CVE, CVE-2026-8598, scored 9.1 CRITICAL on CVSS v3.1, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. The description:
An undocumented configuration export port is accessible on some models of ZKTeco CCTV cameras. This port does not require authentication and exposes critical information about the camera such as open services and camera account credentials.
Three words carry the weight there: undocumented, does not require authentication, and account credentials. An open port that the manufacturer never told anyone about hands over the account credentials for the camera. That is not a flaw in the lock. It is a second door that was not on the floor plan.
To ZKTeco's credit, and the contrast with Brickcom is stark, they shipped a fix and published their own advisory. The remediation is a firmware upgrade to V5.0.1.2.20260421 or later.
On 23 April 2026, CISA published ICSA-26-113-03 on Milesight cameras, carrying five CVEs. Three of them are authentication failures of the same family. CVE-2026-27785, scored 8.8 HIGH, is hard-coded credentials in the AIOT camera firmware. CVE-2026-32644, scored 9.8 CRITICAL, involves default SSL certificate private keys. CVE-2026-28747, scored 7.1, is weak key generation permitting a bypass of authorization controls. The advisory also carries CVE-2026-20766 at 8.8 and CVE-2026-32649 at 6.8.
Hard-coded credentials and shared default private keys have a specific property that ordinary bugs lack: they do not require you to be targeted. Once the value is extracted from one unit, it is valid on every unit of that model everywhere. The work of attacking your camera was already done, on somebody else's camera, possibly years ago.
My Army background is Counter-IED and Electronic Warfare, and the habit that job builds is asking what a system assumes rather than what it does. A jammer does not defeat a radio's encryption. It exploits the radio's assumption that the channel is quiet. The strongest cipher in the world is untouched, and irrelevant, because the attack went around it.
These camera advisories are the same shape. Nobody broke the video encryption. There is an endpoint that responds without asking, a port that was never documented, a key that is identical across the product line. The security work that was done, and some of it was real, sits beside the hole rather than in front of it.
This is why I keep arguing that "military-grade encryption" on a spec sheet tells you almost nothing about whether a device is safe. Encryption is a control on confidentiality in transit. It is not access control, and a system can have an excellent version of the first and none of the second. I made this argument at more length in Report 035, where a smart deadbolt's cryptography was sound and its revocation was not.
The response to this class of finding is different from the response to a patchable bug, because you cannot patch a design decision on a device whose vendor does not answer CISA.
Start with the assumption that any camera reachable from the internet will eventually be reached. CISA's own recommended mitigations in all three advisories are variations on one instruction: isolate the devices behind a firewall, minimize direct internet exposure, and use a VPN for remote access rather than exposing the camera itself. That advice is unglamorous and it is correct. A camera on an isolated VLAN with no inbound path from the internet is substantially protected against every finding above, including the ones with no patch.
Second, treat vendor responsiveness as a security specification rather than a customer-service detail. "Did not respond to CISA's request for coordination" is a disclosed property of the Brickcom product line, and it is more predictive of your next five years than any feature on the box. ZKTeco patched. Brickcom did not answer the phone. That difference belongs in the purchase decision.
Third, and this is the one estates get wrong: know what your cameras are. Large properties accumulate hardware across installers and years. The advisories above name specific models and firmware strings. If nobody can hand you a current inventory with model and firmware version per device, you cannot act on an advisory even when it is published, and the advisory becomes noise.
Disclosure, because I build in this category rather than only writing about it: I help design the AI security systems for a veteran-owned (SDVOSB) home-security company run by a fellow combat veteran and his father, who has three decades in the trade. I do not own that company and earn nothing from this link. Full policy here.
I have not tested any of these cameras. Everything above is what CISA published. I did not attempt to reproduce any finding, did not scan for exposed devices, and have no independent knowledge of how many units are deployed or how many are reachable from the internet. The CVE descriptions and scores are CISA's, quoted from the advisories.
I did not obtain a v4.0 CVSS score for the ZKTeco or Milesight advisories, and I have reported only the scores I read. For Milesight I read the CVE list and severity ratings; I did not review the vendor's own advisory or confirm the remediation status of each of the five CVEs independently.
CISA advisories are vulnerability disclosures, not measurements of real-world harm. None of them assert that any of these cameras has actually been exploited at a private residence. CISA noted no known public exploitation specifically targeting the ZKTeco vulnerability. Three advisories are also a small and non-random sample: I selected them because they share an authentication-absence pattern, which means this report describes a pattern I went looking for rather than a statistical property of the camera market.
None of this rests on my own research. My published work is in microwave spectroscopy. My background here is operational: I spent my Army career as a Counter-IED and Electronic Warfare Officer, which is a useful lens on system assumptions and is not a software security credential. The technical findings belong to CISA and the researchers credited in each advisory.
The useful distinction is between a device that failed and a device that never tried. A patchable bug is a maintenance problem, and maintenance problems get solved by process: inventory, monitoring, an update window. Absent authentication is an architecture problem, and it does not get solved by updating anything, because the vendor built what they meant to build.
When you evaluate a camera, the question worth asking is not whether it has had vulnerabilities. Everything has had vulnerabilities. Ask what happens when someone sends an unauthenticated request to it, and ask whether the manufacturer picks up the phone when the federal government calls. Those two answers will tell you more than the entire spec sheet.
Scope note: this report summarizes three published CISA ICS advisories about specific camera models and firmware versions. It is not an independent security assessment, not a test of any product, and not a claim that any device has been exploited at any residence. Model and firmware coverage is as stated in each advisory; check the advisory itself against your own inventory. Disclosure: the author helps design AI security systems for a veteran-owned home-security company, as stated in the body of this report, and does not own that company.
U.S. Army combat veteran (Counter-IED / Electronic Warfare), peer-reviewed researcher in microwave spectroscopy, and founder & CEO of Shroombiosis. Consults on laboratory operations, AI, and supplement formulation.