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

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

Which versions of GeoVision GV-AS1620 are affected by CVE-2026-18754?

GeoVision GV-AS1620 access-control appliances ship with a hard-coded RSA private key in firmware, enabling attackers to decrypt and forge HTTPS management traffic without needing device credentials.

How to fix or mitigate CVE-2026-18754?

Within 24 hours: identify and inventory all GeoVision GV-AS1620 devices and their network locations. Within 7 days: restrict management interface access to a dedicated VPN or jump host, enable detailed logging of administrative connections, and configure network monitoring for suspicious access patterns. Within 30 days: monitor for vendor security advisories and patches; if no patch is released within 90 days, initiate a replacement assessment given the critical nature of access-control systems.

GeoVision GV-AS1620 CVE-2026-18754

EUVD-2026-52638 CRITICAL

Use of Hard-coded Cryptographic Key (CWE-321)

2026-08-04 GV

GHSA-qfjw-8qqh-5c6x

Information Disclosure Gv As1620 Gv Cloud Geovision Inc

9.1

CVSS 3.1 · Vendor: GV

Severity by source

Vendor (GV) PRIMARY

9.1 CRITICAL

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

vuln.today AI

7.4 HIGH

Network-facing TLS interface but active decryption/spoofing needs both key extraction and a MITM position, so AC:H; no auth (PR:N); high C and I, no availability impact.

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

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/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

None

Lifecycle Timeline

Analysis Generated

Aug 04, 2026 - 08:00 vuln.today

CVE Published

Aug 04, 2026 - 07:09 cve.org

CRITICAL 9.1

DescriptionCVE.org

The product firmware contains an embedded, static RSA private key utilized by the Lighttpd web server for TLS termination. Exposure of this private key allows malicious actors to breach the confidentiality and integrity of HTTPS communications, enabling traffic decryption and server spoofing.

AnalysisAI

Hard-coded RSA private key exposure in GeoVision GV-AS1620 (GV-Cloud) access-control appliances lets remote attackers decrypt and forge the device's HTTPS traffic. The firmware ships an embedded, static RSA private key used by the built-in Lighttpd web server for TLS termination, so anyone who extracts it from one device can passively decrypt or actively impersonate the management interface of every device sharing that key. No public exploit identified at time of analysis, but the shared-secret nature makes the flaw broadly reusable once the key is recovered.

Technical ContextAI

The affected component is the Lighttpd web server bundled in the GV-AS1620 firmware, which handles TLS termination for the device's HTTPS management/cloud interface. Rather than generating a unique per-device key pair at provisioning or first boot, the firmware embeds a single static RSA private key that is identical across all units, and that key material is recoverable by anyone with access to a firmware image or the flash of a physical device. This is a textbook CWE-321 (Use of Hard-coded Cryptographic Key): TLS confidentiality and server authenticity depend on the private key remaining secret, but a hard-coded key shared by the entire product line is effectively public once one copy is extracted, defeating both encryption and certificate-based server identity.

RemediationAI

No vendor-released patch version is identified in the available data; consult the GeoVision advisory at https://www.geovision.com.tw/cyber_security.php for updated firmware and apply any release that provisions a unique per-device RSA key pair rather than the shared static key. Until fixed firmware that regenerates device-unique keys is confirmed, apply compensating controls: do not expose the device's HTTPS/management interface to the internet, place it on an isolated management VLAN and restrict access with firewall rules so no untrusted party can occupy a MITM position (trade-off: remote cloud management may break); where the platform allows, replace the built-in certificate/key with an operator-generated unique key pair and CA-signed certificate (trade-off: manual per-device effort and possible cloud-service incompatibility); and monitor for TLS certificate anomalies or unexpected MITM indicators on the segment carrying device traffic. Rotating the key only helps if the firmware supports installing a unique, non-hard-coded key.