DEV Community: Suraj Raj Bhandari

Ten years after Mirai, can you name your riskiest camera?

Suraj Raj Bhandari — Mon, 12 Oct 2026 01:52:19 +0000

In September 2016, a botnet called Mirai took over hundreds of thousands of IP cameras and DVRs. It didn't need a zero-day. It logged in with a list of about 60 factory-default usernames and passwords, then used those devices to knock large parts of the internet offline.

That was ten years ago. So here's a question for anyone who runs a network with cameras on it:

Which of your cameras is the biggest risk right now?

Most organisations can't answer that. Usually it isn't negligence. Cameras just fall between teams. Facilities bought them, an installer set them up, IT routes their traffic, and security assumes someone else is looking after them. Nobody owns the full list.

Why cameras are still the soft target

Treat a camera as what it really is: a small Linux computer with a network port, a web server, a video streaming server and a vendor SDK port. It usually runs firmware nobody has updated since the day it went in, and it sits in a ceiling for 7–10 years.

The same problems turn up on almost every site:

Internet exposure. A port forward for "remote viewing", or UPnP opening one quietly. Search engines like Shodan index these devices continuously.
Default or weak credentials. Still the number one way in. It's exactly what Mirai used.
Plaintext RTSP. Most cameras stream video over RTSP on port 554 with no encryption. If someone can see the traffic, they can see the video, and often the credentials too.
End-of-life firmware. Vendors stop shipping patches, but the camera keeps working, so nobody replaces it. Its known CVEs stay open for good.
Hardware you may not be allowed to run any more. Section 889 of the US NDAA bans federal agencies and their contractors from using video surveillance equipment from certain vendors. The catch is that this hardware is widely OEM-rebranded, so the name on the label often isn't the company that made it.

None of this is exotic. The hard part is seeing all of it, across every camera, at once.

The discovery problem: ONVIF isn't enough

The obvious way to find cameras is ONVIF WS-Discovery: send a multicast probe and list whatever replies. It's a good start, but it misses a lot:

Multicast usually stops at the subnet or VLAN boundary, so cameras on other segments never hear the probe.
Many cameras ship with ONVIF disabled, or the installer turned it off.
Older and cheaper devices may not support ONVIF at all.

A camera that ignores ONVIF still has to expose something to be useful: RTSP (554, 8554), HTTP/HTTPS for its web UI, and often a vendor SDK port such as 8000, 37777 or 34567. Those open ports, together with what the services report when you connect, identify a camera far more reliably than waiting for it to answer a multicast probe.

What you can check yourself this afternoon

You don't need any product for a first pass. Only scan networks you own or are authorised to test.

Find what's listening on camera ports on your own subnet:

   nmap -sV -p 80,443,554,8000,8554,37777,34567 192.168.1.0/24

Every host with 554 open deserves a closer look.

Check your public IP on Shodan (or a similar service). If a camera or NVR web page shows up, you have an exposure problem.
Turn off UPnP on the router or firewall that sits in front of the camera network.
Put cameras on their own VLAN with no internet egress by default. Cameras rarely need to call out, and blocking egress also cuts off a lot of botnet traffic.
Write down the make, model and firmware version of each camera and look up its end-of-support date. The first time you do this, it's usually a surprise.

That covers the basics for a home lab or a small office. For an estate of hundreds or thousands of cameras across many sites, doing it by hand doesn't scale. You also need output an auditor will accept.

So we built OpenNVR Scout

OpenNVR Scout is a read-only security assessment for a whole camera estate. It works in four stages:

🔍 Discover

It finds cameras by their open ports and service fingerprints, not only the ones that answer ONVIF. Cameras on other segments, cameras with ONVIF switched off, and old devices all end up in the inventory.

📊 Grade

It runs 50 checks across 14 risk categories, including exposure, credentials, transport encryption, firmware age and known CVEs. Each camera gets an A–F grade, and so does the estate as a whole. A letter grade is blunt on purpose: everyone, including people outside security, understands it in a meeting.

⚖️ Comply

Each finding is mapped to the relevant US, EU, UK and India regulations. When Scout finds NDAA §889-covered hardware, including OEM-rebranded units, it produces the evidence a procurement or compliance team needs.

🛠️ Fix

It produces a prioritised migration plan, not another flat list of patches. Some cameras need a firmware update. Some need a firewall rule. Some will never be safe and should be replaced first. The plan says which is which and in what order.

The output is a posture report in HTML and PDF that you can hand straight to your security team or auditor.

Read-only by design

A security tool that can break the thing it checks is a hard sell in production, particularly on a 10-year-old camera that falls over if you look at it the wrong way. So Scout is passive and read-only by default:

It doesn't exploit anything.
It doesn't change any configuration on the cameras.
It only tests credentials when you explicitly authorise it.

That last point matters. Credential checks give the most useful results, and they're also the ones that need clear permission. Scout makes that an explicit opt-in, never a default.

See it in action

Here's a two-minute walkthrough:

👉 https://www.youtube.com/watch?v=RVPSaiNYGlg

Over to you

How does your organisation track camera security today? A spreadsheet, the VMS inventory, or nobody at all? I'd like to hear in the comments, especially from anyone who has tried to answer the §889 question for real.

If you'd like to know how your cameras would score, you can book a camera security assessment at opennvr.org or email contact@opennvr.org.

OpenNVR 0.1.6 Is Out: Search Your Camera Footage in Plain English

Suraj Raj Bhandari — Sun, 11 Oct 2026 16:32:15 +0000

What if you could search hours of CCTV footage by simply describing what you're looking for?

Instead of manually scrubbing through recordings, imagine searching for "red truck at the dock yesterday" and finding the relevant footage in seconds.

That's the idea behind OpenNVR 0.1.6.

OpenNVR is an open-source platform for AI-powered video surveillance that brings intelligent video analytics to your own hardware.

What's New in OpenNVR 0.1.6?

🔎 1. Search Video Footage Using Natural Language

Search recorded camera activity using plain-language descriptions. Captions, colours, vehicle types, and license plates become searchable, making it easier to find the footage you need.

🎯 2. More AI Applications

The application catalog has evolved into dedicated products, including:

Intrusion detection
Loitering detection
Line crossing
Abandoned object detection
Package delivery
Gate control
Smart doorbell

Guard Scan Compliance is also introduced in this release.

⚡ 3. Smarter AI Resource Allocation

Each camera runs the AI applications assigned to it. This helps avoid spending compute resources on applications that aren't needed for a particular camera.

🏠 4. Home Assistant Integration

OpenNVR now supports Home Assistant through MQTT discovery, with API-token scoping and audit logging.

🛡️ 5. Security Fixes

This release includes security fixes. Upgrading existing installations is recommended.

🧑‍💻 6. SDKs Available on PyPI

Both OpenNVR SDKs are available on PyPI, making it easier for developers to build applications with a single function or integrate their own AI models through adapters.

Developers can also distribute their applications under their preferred licences.

Built in the Open

This release includes 147 merged changes since the previous release.

Our goal is straightforward: make AI-powered video surveillance more accessible, extensible, and practical without requiring specialised hardware for every new capability.

With OpenNVR, new capabilities can arrive through software rather than requiring you to replace your camera infrastructure.

Try OpenNVR

🌐 Website: https://opennvr.org
💻 GitHub: https://github.com/open-nvr/open-nvr
📋 Release notes: https://lnkd.in/gSCEP2EQ
✨ What's new: https://lnkd.in/gmxA--bM

If you're working on computer vision, edge AI, video surveillance, or open-source infrastructure, we'd love to hear your thoughts and contributions.

What would you build on top of OpenNVR?

Okay, I've been sitting on this post for a while and I'm finally writing it. 😄

Suraj Raj Bhandari — Sat, 26 Sep 2026 10:23:17 +0000

For months now I've been working on OpenNVR, an open-source NVR (network video recorder) for IP cameras. And the part I'm most excited about: you can literally ask your cameras questions, and the AI answering you runs on your own machine. Not some vendor's cloud. Yours.

This is what it looks like:

Every time I see that work I still smile a little.

Why I care about this so much

Think about how most cameras work today. You buy one, it connects to the manufacturer's cloud, and your footage goes... somewhere. They hold the keys. They run the AI. If they get breached, you get breached.

And this isn't hypothetical. In 2016 the Mirai botnet took over hundreds of thousands of IP cameras and used them for one of the biggest DDoS attacks ever. In 2021 someone got into a camera vendor's cloud and could watch around 150,000 cameras, in hospitals, schools, prisons.

That always bothered me. A camera in your house should work for you. So OpenNVR is built the other way round: your cameras, your hardware, your AI, and nothing leaves the box unless you decide it should.

Getting it running

I really wanted this to be easy, so it's two commands:

git clone https://github.com/open-nvr/open-nvr.git && cd open-nvr
./start.sh          # Windows: .\start.ps1

You get a small setup wizard. Every question already has a default, so honestly you can just keep pressing Enter. At the end it gives you a URL and a one-time token. Open it, set a password, add a camera, and in about 30 seconds you'll see detection boxes on your live feed.

I'll be honest though: the first run takes 8 to 15 minutes because it's downloading Docker images. Go get a chai. ☕ After that it starts in seconds.

Don't have an IP camera? No problem. The camera agent can use your laptop webcam, or you can install the OpenNVR Cam app on an old Android phone and it becomes a real ONVIF camera.

You can talk to your cameras (my favourite part)

This is the thing I show everyone first. There's a camera agent: a small local LLM (Ollama, qwen2.5:1.5b by default) that can call vision tools on your live cameras. So you can ask things like:

"Is anyone in the kitchen?" and it runs YOLOv8 on the current frame
"What's at the back gate?" and it describes the scene
"Did anyone walk past in the last ten minutes?" and it checks recent events
"Did a red truck come by earlier?" and it searches the history

You can use it by voice (Whisper listens, Piper talks back) or just type with --chat. Both run on a normal CPU. No API keys, no account.

examples/camera-agent/quickstart.sh --chat
# then open http://localhost:9100/demo

How it works under the hood

Some design decisions I'm really happy with:

Recording never depends on the AI. Video gets recorded in one-minute chunks no matter what. If every model crashes, your footage is still there. This part has to be boring, and it is.

A cheap detector decides when the expensive stuff runs. A small model watches a low frame rate copy of each stream. Only when it sees something interesting does it wake up the heavy models like face recognition or plate reading. That's how the whole thing fits on a mini PC.

Models and rules are separate. Models answer "what is this?". Apps answer "should I care?" (this zone, these hours, this plate list). So you can swap a model without rewriting your rules.

One place for history. Everything worth remembering goes into one event store, so "was a red van here on Tuesday?" gives the same answer from the search page, the agent, or an app you install next month.

Plug in your own model

This is the developer part I love. If your model sits behind a REST or WebSocket endpoint, it can plug into OpenNVR. A trimmed down version looks like this:

from opennvr_adapter_sdk import AdapterApp, AdapterService, BodyShape, BODY_BYTES_KEY, InferResponse

class MyDetector(AdapterService):
    def load(self):
        ...  # load your weights

    def infer(self, payload) -> InferResponse:
        frame_bytes = payload[BODY_BYTES_KEY]
        # ... run your model ...
        return InferResponse(result={"detections": [...]})

app = AdapterApp(
    service=MyDetector(),
    name="my-detector", version="1.0.0", vendor="me", license="MIT",
    tasks_advertised=["object_detection"],
    body_shape=BodyShape.IMAGE,
).fastapi_app

Run it with uvicorn, register the URL, done. The SDK is Apache-2.0, so your adapter can use whatever license you want. Full version is in the SDK README.

An app store instead of YAML files

Once it's running there's an App Catalog with thirteen one-click apps: number plate recognition, a doorbell that recognises faces, intrusion zones, loitering, people counting, line crossing, abandoned objects, package delivery, gate control, "find the red truck" footage search, alert routing, a Home Assistant bridge, and more.

Each app has to say up front which cameras and network hosts it needs, and an admin approves that before install. No app can quietly get access it never asked for.

Want to write your own? pip install opennvr-app-sdk && opennvr-app new my-app gives you a starter where you fill in one method: your rule.

Private by default

Cloud access and AI calls to the internet are blocked (HTTP 403) until you explicitly turn them on.
Camera passwords are encrypted at rest.
Every AI decision is logged with an ID that traces the alert back to the exact model that made it.

If you like reading architecture papers, we wrote one: here it is.

What hardware do you need?

Raspberry Pi 4/5 (4 GB): recording, streaming, detection, zone and line apps
Mini PC / NUC (8 to 16 GB): all of that plus plate and face recognition and the text agent
Something with an NVIDIA GPU: everything, including scene descriptions and the voice agent

I'd love your help

We're still early, and honestly every bit of feedback helps a lot right now. If this sounds interesting:

⭐ Star the repo on GitHub. It really helps other self-hosters find it.
Try it on your own machine and open an issue for anything that breaks or confuses you. I read all of them.
Tell me in the comments: what would you ask your cameras? I'm genuinely curious.

Thanks for reading! 🙏

GitHub: https://github.com/open-nvr/open-nvr
Website: https://opennvr.org