GV-E-Map Server CVE-2026-107437

Requires local access to the GV-E-Map Server V18.2.0A host: either read access to the distributed application binary (for static analysis) or the ability to read the application's process memory at runtime. The credential is embedded by default in the shipped component, so no special product configuration is needed to make it present - the limiting factor is purely the need for a prior local foothold or operator-level filesystem/memory access, not any enabled feature or deployment mode. This is NOT remotely exploitable; there is no network-facing trigger, which substantially limits realistic risk relative to the raw score.

This is a medium-severity (CVSS 6.2) hardcoded-credential weakness (CWE-798) whose risk is sharply constrained by the attack vector: the provided CVSS vector is AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, meaning an attacker needs LOCAL access to the GV-E-Map Server host to recover the embedded plaintext database password - either by statically analyzing the distributed binary or by reading process memory at runtime. No EPSS score, CISA KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The impact profile (C:H, I:N, A:N) is confidentiality-only at the base level, but the recovered credential is a stepping-stone that could enable follow-on database compromise beyond the scored scope. Net: this is a real but lower-priority issue for internet-facing triage because it is not remotely exploitable without prior local foothold - it matters most as a post-compromise privilege/lateral-movement enabler and in multi-user or shared-host deployments. Note a signal conflict worth verifying: the input Tag 'Authentication Bypass' does not match the actual CWE-798 hardcoded-credential nature of the flaw, which is credential exposure rather than a direct auth bypass.

An attacker who already has local access to the GV-E-Map Server V18.2.0A host (e.g., a low-privileged local user or an operator with filesystem access to the installed binaries) performs static analysis on the distributed application component and extracts the embedded plaintext database password. Alternatively, they dump the running process memory to recover the same credential, then use it to authenticate directly to the backend database and read stored surveillance/configuration data. No public exploit code is required, as recovery relies on standard reverse-engineering and memory-inspection techniques.