Shinobi NVR: Hardcoded Child-Node Key Enables Unauthenticated Database Compromise (CVE-2026-82448)

Executive Summary

CVE-2026-82448 affects Shinobi, an open-source video surveillance / NVR platform, prior to commit 5a76c74f. The flaw carries a maximum-severity CVSS score of 9.8 and allows unauthenticated attackers to execute arbitrary database queries against a Shinobi deployment.

CVSS Score: 9.8 (Critical)

Shinobi's child-node service — used to distribute camera processing across multiple nodes — accepts a hardcoded connection key during its WebSocket handshake instead of a per-installation secret. Because the key is baked into Shinobi's source and identical on every install, any attacker who can reach a child-node port can present that key, then dispatch arbitrary SQL queries through the onWebSocketDataFromChildNode handler to read and modify user records and camera configuration. A fix is available in commit 5a76c74f3977661ff3f9fd55a260db352c0b19c0, merged via merge request !554.

Vulnerability Overview

Affected Versions

Technical Details

Shinobi's architecture supports offloading camera stream processing to child nodes, which communicate with the main Shinobi instance over WebSocket. To authorize that link, the child-node service expects a connection key presented during the WebSocket handshake.

The problem: that key is hardcoded in Shinobi's source rather than generated per-installation. It never changes between deployments, so an attacker only needs to obtain a copy of Shinobi (trivial, since it is open source) to recover the key once and reuse it against any Shinobi instance reachable on the network.

Once the handshake is accepted with the recovered key, the onWebSocketDataFromChildNode handler dispatches attacker-supplied data as SQL queries against the application database — with no further authentication or input validation. This gives an attacker direct read/write access to user records and camera configuration.

Attack Vector

1. Attacker obtains the hardcoded child-node connection key from Shinobi's source
2. Attacker opens a WebSocket connection to a reachable Shinobi child-node port
3. Attacker presents the hardcoded key during the handshake — accepted unconditionally
4. Attacker sends crafted data to onWebSocketDataFromChildNode
5. Handler dispatches the payload as a raw SQL query
6. Attacker reads/modifies user accounts and camera configuration in the database

Impact of Successful Exploitation

Immediate Remediation

Step 1: Identify Your Shinobi Version

cd /path/to/shinobi
git log -1 --format="%H %ci"

If your checkout predates commit 5a76c74f, you are affected.

Step 2: Update Shinobi

git fetch origin
git checkout 5a76c74f3977661ff3f9fd55a260db352c0b19c0
# or pull the latest release/main branch that includes merge request !554
npm install

Restart Shinobi and all child-node services after updating.

Step 3: Restrict Network Exposure

Regardless of patch status, child-node ports should never be reachable from untrusted networks:

1. Confirm child-node WebSocket ports are not exposed to the public internet.
2. Firewall child-node ports to only the specific main-node IP addresses that need to reach them.
3. If Shinobi child nodes are deployed on the same host, bind their ports to localhost only.

Step 4: Audit for Prior Exploitation

# Review Shinobi and reverse-proxy logs for unexpected WebSocket connections
# to the child-node port from unfamiliar source IPs
grep -i "childnode\|child-node" /var/log/shinobi/*.log

Detection Indicators

Post-Remediation Steps

1. Confirm the Shinobi install includes commit 5a76c74f or later.
2. Rotate all Shinobi user account credentials as a precaution.
3. Review camera configuration for unauthorized changes.
4. Firewall child-node ports even after patching, as defense in depth.
5. Monitor the Shinobi GitLab repository for further advisories.

References

• NIST NVD — CVE-2026-82448

Related Reading

• CVE-2026-16259: Uix UserCenter WordPress Plugin Hardcoded Signing Key
• CVE-2026-20316: Cisco FMC Hardcoded Password