GeoVision GV-LPC CVE-2026-57879

Exploitation requires network reach to the ssvr RTSP service (default RTSP TCP/554) on a GV-LPC2011 or GV-LPC2211 running V1.12 or earlier; the trigger is a crafted RTSP request containing oversized RTSP custom authentication data. Per the CVSS vector (PR:N/UI:N), no credentials and no user interaction are needed - the parsing flaw is hit before authentication completes. Limiting factors: the target must be a vulnerable firmware version, the attacker must be able to route to the RTSP port (so network segmentation, firewalling, or VPN-only access substantially reduces exposure), and reliable arbitrary code execution (as opposed to denial of service) further depends on the device's memory-protection posture, which is not documented here.

The signals are largely aligned toward high priority: CVSS 9.8 with AV:N/AC:L/PR:N/UI:N means network-reachable, low-complexity, unauthenticated exploitation, and the buffer-overflow class supports both reliable DoS and plausible RCE. However, real-world risk is moderated by deployment footprint - these are niche LPR camera appliances, not ubiquitous software - and by the absence of corroborating exploitation data: no CISA KEV listing, no public POC, and no EPSS or SSVC values were provided in the input, so exploitation probability cannot be quantified here. RCE is described as 'potentially' achievable; reliable code execution on embedded targets depends on memory protections (ASLR/DEP/stack canaries) that are not documented in the available data, so DoS should be treated as the confirmed impact and RCE as a credible but unverified upside for an attacker. Net: a genuine high-priority issue for any organization exposing these cameras to untrusted networks, but exploitation in the wild is currently unproven rather than confirmed.

An attacker who can reach the camera's RTSP port crafts an RTSP request with an overlong custom authentication field and sends it to ssvr, overflowing a stack buffer and corrupting memory. The immediate result is a camera crash (loss of surveillance coverage); with sufficient effort and favorable embedded-platform conditions, the same overflow could be developed into arbitrary code execution on the device. No public exploit code is identified at this time, so this remains a realistic but not yet demonstrated attack.