Description

Shinobi before commit 5a76c74f contains a hardcoded connection key in the child node service that allows unauthenticated attackers to execute arbitrary database queries. Attackers reaching the child node port can present the hardcoded key during WebSocket handshake, then dispatch SQL queries through the onWebSocketDataFromChildNode handler to read and modify user records and camera configuration.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-29T13:16:38.877Z",
  "pubdate": "2026-08-29T13:16:38.877Z",
  "executiveSummary": "Shinobi, prior to commit 5a76c74f, is susceptible to an authentication bypass vulnerability stemming from the use of a hardcoded connection key within the child node service.\nThis flaw allows unauthenticated remote attackers to gain unauthorized access to the system's backend database.\nBy presenting the static, embedded key during the WebSocket handshake, an attacker can effectively impersonate a legitimate child node.\nOnce the connection is established, the attacker gains the ability to execute arbitrary SQL queries, leading to full control over user records and camera configuration settings.\nThe vulnerability represents a critical security risk as it bypasses standard access control mechanisms, facilitating data exfiltration, account takeover, and system reconfiguration without requiring valid user credentials.\nExploitation requires network reachability to the exposed child node service port, making this a significant threat to internet-facing deployments.",
  "technicalDetails": "The vulnerability resides in the child node service implementation of the Shinobi platform, specifically affecting versions prior to commit 5a76c74f.\nThe root cause is the hardcoding of a static connection key used to authenticate internal communications between the master controller and child node services.\nThe attack flow initiates with the attacker establishing a WebSocket connection to the child node service port. During the initial WebSocket handshake, the attacker transmits the hardcoded secret key, which is treated as a valid credential by the application.\nUpon successful handshake completion, the application grants the attacker session context equivalent to a legitimate child node component.\nThe internal function 'onWebSocketDataFromChildNode' is subsequently leveraged to process incoming messages. This handler does not perform sufficient validation or sanitization on the input, allowing the attacker to inject arbitrary SQL statements into the database interface.\nBecause the application trust model assumes that any entity possessing the hardcoded key is authorized to interface with the database, the attacker can perform unauthorized CRUD (Create, Read, Update, Delete) operations.\nThe impact of this exploitation includes the exfiltration of sensitive user information, modification of authentication credentials, and the manipulation of system-wide camera configurations. Effectively, an attacker can pivot from an unauthenticated network connection to full administrative control over the data layer.\nThis vulnerability is particularly dangerous as the authentication mechanism relies solely on 'security by obscurity' through the hardcoded key rather than cryptographically secure, unique, or dynamic authentication tokens.\nExposure of the child node service to an untrusted network allows for remote exploitation, and the lack of secondary authorization checks within the WebSocket handler exacerbates the risk of direct database interaction."
}