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

CVE-2026-18753 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-18753?

The GeoVision GV-AS1620 access-control platform contains a shared hard-coded encryption key affecting all deployed devices, creating a critical vulnerability in the administrative management…

How to fix or mitigate CVE-2026-18753?

Within 24 hours: conduct inventory of all GeoVision GV-AS1620 devices in production, isolate management interfaces to a restricted administrative network segment, and contact GeoVision support for emergency guidance. Within 7 days: implement dedicated VLAN segmentation for all AS Manager devices with detailed access logging, deploy monitoring to detect unauthorized administrative access attempts, and evaluate firmware integrity verification capabilities. Within 30 days: develop device replacement plan with models featuring unique per-device cryptographic materials, or implement proxy-based management access with multi-factor authentication as an interim control layer.

GeoVision GV-AS1620 CVE-2026-18753

EUVD-2026-52637 CRITICAL

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

2026-08-04 GV

GHSA-7p93-2qwj-4g34

Information Disclosure Gv As1620 As Manager 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

Static key is network-exploitable but practical decryption/spoofing needs firmware extraction plus a MITM position, so AC:H; high confidentiality and integrity impact, no availability effect.

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:08 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 the GeoVision GV-AS1620 (AS Manager) access-control device lets attackers who extract the firmware-embedded key decrypt and forge the Lighttpd TLS session used for the device's HTTPS management interface. Because the key is static and shared across all units of the same firmware, a single extraction compromises every deployed device, enabling passive traffic decryption and active server impersonation. No public exploit is identified at time of analysis, and the issue is not listed in CISA KEV.

Technical ContextAI

The GV-AS1620 is a networked access-control controller ('AS Manager') whose embedded web management stack uses the Lighttpd web server to terminate TLS for its HTTPS interface. The root cause is CWE-321 (Use of a Hard-coded Cryptographic Key): the RSA private key that backs the server's TLS certificate is baked into the firmware image rather than generated per-device at provisioning. Any party who obtains a firmware copy (via download, physical flash dump, or one compromised unit) recovers the same private key present on every other device running that firmware, defeating the asymmetry that TLS relies on. With the private key, an attacker can decrypt captured TLS sessions that use RSA key exchange and can present a valid-appearing certificate to impersonate the device.

RemediationAI

Apply the firmware update published by GeoVision on its security advisory page (https://www.geovision.com.tw/cyber_security.php) - no exact fixed version is provided in the available data, so verify the patched build number directly with the vendor; a proper fix must replace the shared key with a unique per-device certificate/key generated at first boot or provisioning. Because a static hard-coded key cannot be neutralized by configuration alone, until a fixed firmware is installed the practical compensating controls are to remove the device's HTTPS management interface from any untrusted or shared network segment and restrict it to an isolated management VLAN reachable only by trusted administrators (trade-off: administrators must connect through the management network), and to front the device with a reverse proxy or VPN that performs its own TLS termination with a device-unique certificate so the embedded key is never exposed to attacker-reachable paths (trade-off: added infrastructure and possible feature/management limitations). Monitoring for ARP spoofing / rogue-gateway activity on segments carrying device traffic reduces the window for MITM interception.