What is the CVSS score of CVE-2026-57879?

CVE-2026-57879 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.5%.

Which versions of GeoVision GV-LPC are affected by CVE-2026-57879?

GeoVision license-plate-recognition cameras (GV-LPC2011/GV-LPC2211, versions 1.12 and earlier) contain a critical remote code execution vulnerability enabling unauthenticated network attackers to…

How to fix or mitigate CVE-2026-57879?

Within 24 hours: Conduct inventory of all GeoVision GV-LPC2011 and GV-LPC2211 devices in your environment and determine network exposure. Within 7 days: Implement network segmentation to isolate affected cameras from untrusted networks; disable RTSP protocol access where operationally feasible. Within 30 days: Monitor GeoVision security advisories for patch releases; develop and execute replacement or decommissioning strategy if no patch becomes available.

GeoVision GV-LPC CVE-2026-57879

EUVD-2026-39635 CRITICAL

Stack-based Buffer Overflow (CWE-121)

2026-06-26 GV

GHSA-mm39-vhxr-6hjg

RCE Buffer Overflow Denial Of Service Stack Overflow Gv Lpclpc2011 2211 Geovision Inc

9.8

CVSS 3.1 · Vendor: GV

Severity by source

Vendor (GV) PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

9.8 CRITICAL

Pre-auth RTSP parsing reachable over the network with low complexity and no interaction (AV:N/AC:L/PR:N/UI:N); memory corruption enabling potential RCE justifies C:H/I:H/A:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GV).

CVSS VectorVendor: GV

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 26, 2026 - 08:19 vuln.today

DescriptionCVE.org

An unauthenticated stack-based buffer overflow vulnerability exists in ssvr in GeoVision GV-LPC2011 and GV-LPC2211 V1.12 and earlier. The vulnerability is caused by insufficient bounds checking when processing RTSP custom authentication data. A remote attacker may exploit this vulnerability by sending a crafted RTSP request, resulting in memory corruption, denial of service, or potentially arbitrary code execution.

AnalysisAI

Remote code execution and denial of service in GeoVision GV-LPC2011 and GV-LPC2211 license-plate-recognition cameras (V1.12 and earlier) arise from a stack-based buffer overflow in the ssvr component's RTSP custom authentication handling. The CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates an unauthenticated remote attacker can trigger memory corruption with a single crafted RTSP request, yielding crash-level DoS and potential arbitrary code execution. No public exploit identified at time of analysis and the issue is not listed in CISA KEV.

Technical ContextAI

GeoVision GV-LPC2011/GV-LPC2211 are network-connected license plate recognition (LPR) camera appliances that expose a streaming service (ssvr) speaking RTSP (Real Time Streaming Protocol), typically over TCP/554. The flaw is a CWE-121 stack-based buffer overflow: a fixed-size stack buffer receives attacker-controlled RTSP custom authentication data without sufficient bounds checking, so an oversized field overwrites adjacent stack memory including saved return addresses. The single CPE provided, cpe:2.3:a:geovision_inc.:gv-lpclpc2011/2211:*:*:*:*:*:*:*:*, covers the combined GV-LPC2011/2211 firmware line. Because the parsing occurs before authentication completes, the overflow is reachable pre-auth, which is the worst-case position for this CWE class.

RemediationAI

Upgrade the GV-LPC2011/GV-LPC2211 firmware to a release newer than V1.12 once GeoVision publishes a fixed build; check the vendor security page at https://www.geovision.com.tw/cyber_security.php for the patched version, as no exact fix version is confirmed in the available data. Until a patch is confirmed and applied, restrict reachability of the RTSP service (TCP/554) by placing the cameras on an isolated VLAN or management network and blocking inbound RTSP from untrusted segments at the firewall - trade-off: remote/cloud viewing clients must be routed through that controlled network or a VPN. Apply source-IP allowlisting so only known NVR/VMS hosts can reach ssvr (trade-off: breaks ad-hoc direct viewing), and monitor for camera reboots or stream crashes as indicators of attempted exploitation. Avoid exposing these devices directly to the internet.