CVE case study
CVE-2026-78869: Incorrect Access Control in Shinobi Lets a Group Admin Cross Into Another Group
Shinobi 2.0.0 and earlier fails to bind a session to its own group, so any authenticated group admin can present a valid session token together with another group's group key in the URL path and act inside that second group. No fixed version was available at disclosure; the issue was reported to the maintainer through a confidential GitLab issue and remains unpatched.
- Weakness
- CWE-639, CWE-863
- Affected
- Shinobi 2.0.0 and earlier (commit 9ddc2c3c71203a22f89fc72580270217a47c1347)
- Remediation state
- No fixed version at disclosure; reported through a confidential GitLab issue
- Advisory published
- 4 Sep 2026
Official vectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Why it matters
Shinobi is an open source video surveillance and NVR platform that organizes accounts into groups, where every account is a full admin of its own group. Authentication runs through s.auth in libs/auth.js. When a request already carries a valid session token, the warm-session branch resolves that session by the token alone and never checks that the session's group key (ke) matches the group key supplied in the request path. The identity of the caller is confirmed, but the tenant the caller is allowed to act in is never checked.
Any authenticated user, who is by design a full admin of their own group, can send their genuine session token with a different group's ke in the URL. The token check passes, and the only other gate, an IP check in onSuccess, is vacuous because createSession stores the session IP as 0.0.0.0. Downstream handlers scope their SQL by the attacker-supplied ke, so they read and act on the victim group's monitors: exposing camera RTSP and ONVIF credentials, deleting recordings, and stopping or PTZ-controlling cameras. The trust boundary crossed is the isolation between separate groups, so the flaw affects multi-group and hosted deployments; a single-group self-host has no second tenant to cross into. The submitted vector scores it 8.5 (High); it carries AC:H because the attacker must first learn the victim group's key, and where group keys are known or leaked that assumption does not hold.
The issue was reported to the maintainer through a confidential GitLab issue (Shinobi-Systems/Shinobi issue #564). The project has no covering CNA: the GitHub mirror has been stale since 2020 with private reporting disabled, and GitLab is not a CNA for the project, so the report was submitted to MITRE CNA-LR. No fixed version was released. The engineering lesson is that a session token proves who a caller is, not which tenant they may act in, so every request carrying a tenant identifier must verify that identifier against the session rather than trust the token alone.