Qihoo 360 D621-2, CVE-2026-121606: a new CVE scored 10

The bottom line

Anyone running a Qihoo 360 D621-2, D603-2, D600-2, D619, D606-6, or D706 camera on firmware 6.0.24 to 6.4.9 must act now: no fix exists and the exploit is public. Isolate the camera from untrusted networks immediately.

Free analysis report · 9 pagesQihoo 360 D621-2, CVE-2026-121606: a new CVE scored 10The same note as a document you can keep or forward: what the sources say, who is affected, and what to do first.Download the analysis report →

At a glance

Does this apply to you?

What it is

The firmware update handler on these cameras accepts an empty signature field as valid. An attacker who can reach the camera over the network can push unsigned firmware onto it. The record says this enables persistent code execution on the device.

Exposure by situation

These priorities are our judgement from what the sources say about who can use the flaw and how. They are not vendor ratings.

Things people will get wrong

• Updating to firmware 6.4.9 removes this risk. The researcher's disclosure states 6.4.9 is itself an affected version and that no fixed firmware exists.
• Physical access to the camera is required to exploit this. The record states the attack can be launched remotely over a network, with no authentication and no user interaction required.
• Only the D621-2 model is affected. The researcher's disclosure names six models: D621-2, D603-2, D600-2, D619, D606-6, and D706.

How we would triage it

This is our judgement.

Step 1: Identify which 360 camera models you run

• Check labels on the physical units or the mobile app's device list for model numbers D621-2, D603-2, D600-2, D619, D606-6, and D706.
• Record each model and its current firmware version, shown in the camera's admin or settings page.

Step 2: Check network exposure

• Confirm whether the camera's IP address is reachable from outside your trusted network segment — from the internet or from guest and untrusted VLANs.
• Check whether the OTA update flow can be triggered from outside the local network.

Step 3: Isolate the camera if the version is in range

• Move the camera behind a firewall rule that blocks all untrusted inbound traffic until a fixed firmware is available.
• The researcher's disclosure says no fixed version exists; updating to 6.4.9 does not resolve the flaw.

Step 4: Monitor for a vendor firmware update

• The researcher's disclosure states the vendor was notified on 6 October 2026 and did not respond. Check the Qihoo 360 support channel for any new firmware release that addresses CVE-2026-121606.
• When a patched firmware is released, apply it and confirm the version number is higher than 6.4.9.

To close it, read the version from the product itself, not from an old inventory, and save the output with the date. If you cannot update today, write down who owns it, the new date, and what limits exposure until then.

Send this to your IT provider

Copy it, change the names and dates, and send it. It is a draft for you to check, not a template tested with any provider.

We operate Qihoo 360 Smart Cameras (models D621-2, D603-2, D600-2, D619, D606-6, or D706) and have become aware of CVE-2026-121606. This flaw allows unsigned firmware to be pushed to the camera over the network, with no authentication required. No fixed firmware exists; the researcher's disclosure states all versions up to and including 6.4.9 are affected. Please confirm which of these models we run, the firmware version on each, and whether any are reachable from untrusted networks. Please also isolate any affected camera from untrusted access and advise us when a patched firmware becomes available. We would like written confirmation of the firmware versions and exposure status by [date].

The weakness behind it

The record classes this as CWE-347 and CWE-345.

• CWE-345 →What this kind of mistake is, and which exploited vulnerabilities share it.

The sources, in their words

The CVE record:

A vulnerability has been found in Qihoo 360 D621-2, D603-2, D600-2, D619, D606-6 and D706 up to 6.4.9. Affected by this issue is the function verify_sign of the file fs2/bin/iscm of the component Firmware Signature Verification. Such manipulation of the argument sign leads to improper verification of cryptographic signature. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Versions of Qihoo 360 D621-2 the record lists as affected:

• 6.4.0
• 6.4.1
• 6.4.2
• 6.4.3

Check your own project

If you build software, you can compare what a project declares with this CVE from a terminal. The tool reads requirements files, package.json, Maven, Gradle, Cargo, CMake and Dockerfile files, runs nothing, and only the CVE id leaves your machine. Naming the CVEs needs no key.

lattice-scan project . --cve CVE-2026-121606

Each row says in-range, outside-range, undetermined or lead, with the file and line. That is evidence about what a manifest declares, not about what runs, and a person decides. The verdicts, the CSV columns and a pipeline recipe are in the guide.

Check the servers you run

The same id can be checked against a host. Run this on the machine itself, not on the laptop that deploys to it: it reads installed packages (dpkg, rpm or apk), snaps, the names of running container images and the kernel version, compares them on the spot, and only the CVE ids leave the machine; the inventory stays on it, in ~/.lattice-scan. Naming the CVEs needs no key. Do it on each server after a deployment, and again when a new entry lands.

lattice-scan --cve CVE-2026-121606

A match is a candidate for a person to confirm, not a finding. A distribution can fix a CVE under an unchanged version number, so a match is a candidate; on Debian-family hosts the report also shows whether the package's own changelog names the CVE. It reads the names of the running images, not what is inside them; for what an image declares, use the project check on its Dockerfile.

Guide: namiq.io/lattice/guides/choose-your-channel. MCP server (io.namiq/lattice in the MCP registry): namiq.io/lattice. Package: pypi.org/project/lattice-scan, or namiq.io/apt.

• Which way into Lattice fits your job →The command line, the Claude skill or the MCP server: what each needs, what works without a key and how to read the result.
• Lattice, the MCP server →The public graph the command reads, for AI agents over MCP.
• Install and connect →The signed apt repository, the fingerprint, and the connection commands for each client.

What we do not know yet

• Whether Qihoo 360 has acknowledged the flaw or committed to a patch timeline after the researcher's disclosure.
• Whether the camera's OTA update channel can be disabled as a mitigation while no patch exists.
• Whether the firmware update interface performs any authentication before the signature check runs.
• Whether any exploitation of this flaw has been observed outside the researcher's controlled test environment.
• Exploitation is not recorded. That is not the same as none.
• This is a new record: scores, versions and wording can change in the first days, and they are as at 4 November 2026. We read the vendor pages listed under Sources; nothing here has been tested.
• The sections headed "The bottom line", "Does this apply to you?", "What it is", "Exposure by situation", "Things people will get wrong", "How we would triage it" and "Send this to your IT provider" are our interpretation of the sources, not a statement by CISA or the vendor.

• The day's CVE highlight →The three new records we picked that day, and how we chose them.
• Today's mission →Every exploited vulnerability from the last seven days, in the order their deadlines fall.