CVE case study
CVE-2026-78879: Authenticated SSRF in Shinobi FFprobe Endpoint
An authenticated server-side request forgery in Shinobi's FFprobe endpoint lets any user holding a non-restricted API key session make the server fetch attacker-chosen URLs, exposing internal hosts and cloud metadata. The vendor confirmed the issue and fixed it in commit 8b9c372f.
- Weakness
- CWE-918, CWE-88
- Affected
- Shinobi through v2.0.0 (source commit 9ddc2c3c), including the official shinobisystems/shinobi:latest Docker image
- Remediation state
- Fixed in commit 8b9c372f on the vendor's Fix-#562 branch
- Advisory published
- 4 Sep 2026
Official vectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Why it matters
Shinobi is an open source video management and CCTV recording platform. Its FFprobe endpoint, GET /:auth/probe/:ke in libs/scanners.js, is meant to inspect a media stream so an operator can confirm a camera feed. To do that it takes a url parameter and passes it straight to the ffprobe command line (ffprobe -i "${url}" in libs/ffmpeg/utils.js) without validating where the URL points. Because the value is never checked against an allowlist or restricted to expected camera hosts, the server can be told to reach any address the operator's own machine can reach.
Any authenticated user with a non-restricted API key session can point the probe at an internal address or the cloud metadata service and have the server make that outbound request on their behalf, returning results that reveal internal hosts, open ports, and cloud instance metadata that sit behind the application's trust boundary. Because the URL also closes the quoted -i "..." argument, a crafted value can inject extra ffprobe arguments, a secondary CWE-88 argument injection. The submitted vector, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, scores it 4.3 (Medium): network reachable, low complexity, and requiring only a low-privilege authenticated session, with the impact limited to information disclosure.
The issue was reported to the vendor through a confidential GitLab issue (#564), where it was the SSRF item held back from an earlier batch pending confirmation. The vendor confirmed it and shipped a fix in commit 8b9c372f on the Fix-#562 branch, and disclosure was coordinated. The engineering lesson is that any user-supplied value that becomes the target of an outbound request must be validated against an allowlist and stripped of shell or argument metacharacters before it reaches a command line, rather than trusted because the caller is authenticated.