Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain GV-Eye Android APK
-
DeliveryDecompile application package
-
ExploitExtract hardcoded API key
-
ExecutionReplay key against GeoVision API
-
ImpactUnauthorized access to backend service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Credential externalization
MITRE ATT&CK
2 techniques across 2 tactics: Persistence, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to possess the GV-Eye V3.6.0 Android application package (APK) - trivially satisfied since the app is publicly distributed - and the ability to reverse engineer it to recover the embedded API key; no authentication, user interaction, or special target configuration is needed because the credential ships in the default client build. The practical LIMIT is that impact is scoped to whatever the single hardcoded key authorizes on GeoVision's server-side API, and effective abuse depends on that backend remaining reachable and not having revoked or rotated the key; the flaw affects the specific GV-Eye V3.6.0 release. |
| Impact | This is CWE-798 (hardcoded credentials): an API key embedded in the GeoVision GV-Eye Android application package and recoverable via reverse engineering. The input CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, base 7.5) scores confidentiality-only impact at network reach, but this is internally inconsistent with the actual mechanism: key EXTRACTION requires possessing and decompiling the APK, which is a local/offline action (AV:L), even though subsequent MISUSE of the recovered key against the backend is network-borne - the NVD vector appears to score the misuse rather than the flaw itself, so AV:N likely overstates the exploitation path. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no public exploit identified at time of analysis and no evidence of active or automated exploitation. Net real-world risk is moderate, not critical: the defect is trivial to exploit once the APK is obtained (any installer has the package), but overall impact is bounded by what the single hardcoded key actually authorizes on GeoVision's API, which the advisory data does not specify. Treat as a genuine credential-exposure issue warranting the vendor's key rotation/server-side fix rather than an urgent widespread-attack scenario. |
| Exploit ScenarioDerived | An attacker downloads the publicly distributed GV-Eye V3.6.0 Android APK, decompiles it with standard reverse-engineering tools (e.g., jadx/apktool), and extracts the hardcoded API key from the package resources or code. The attacker then replays that key against GeoVision's backend API to access or abuse whatever functionality the key authorizes, impersonating the legitimate application. No POC was provided, and extraction is low-complexity but requires local access to the app package before any network misuse. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 02, 2026
A hardcoded API key ships inside the GeoVision GV-Eye Android application (V3.6.0) and can be recovered by reverse engineering the publicly distributed APK, allowing anyone who extracts it to invoke whatever GeoVision backend API operations that key authorizes. The impact is confidentiality-only (C:H, I:N, A:N) scoped to a single embedded credential, and the independent assessment scores it as a local-vector issue (AV:L) because the attacker must first obtain and analyze the client package. No public exploit code identified at time of analysis, and the CVE is not listed in CISA KEV; the practical damage ceiling depends on whether GeoVision rotates or revokes the leaked key on the server side.
RemediationAI
No fixed version is identified in the available advisory data at time of analysis; consult the GeoVision security advisory at https://www.geovision.com.tw/cyber_security.php for a corrected GV-Eye build, and upgrade clients off V3.6.0 as soon as one is published - this is the only fix that removes the credential from the package. Because a client-side secret cannot be recalled once distributed, the highest-value immediate action is server-side: rotate and revoke the embedded API key so that copies extracted from existing APKs become useless. The trade-off is that any legitimate client still hardwired to the old key will break until it is updated, so plan a staggered cutover and monitor for failures. Until a patched build exists, tighten backend controls that limit the blast radius of the leaked credential: scope the key to the minimum set of endpoints and permissions, apply per-key rate limiting and anomaly detection on the GeoVision API, and alert on requests originating from unexpected geographies, user agents, or volumes. GeoVision should also move to short-lived, per-installation tokens issued at runtime rather than shipping any static secret in the APK, and add certificate pinning or attested app integrity checks so a reimplemented client cannot trivially reuse a token; note that these measures raise backend complexity and can cause false rejections for users on rooted or modified devices.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This is CWE-798 (Use of Hard-coded Credentials) manifesting in a mobile client: rather than provisioning per-user tokens or retrieving secrets at runtime from a secure backend, the GV-Eye Android build embeds a static API key directly in the application package. Android APKs are trivially decompilable and greppable, so any string constant shipped in the bundle should be treated as public - the key offers no confidentiality against a motivated analyst. The CPE (cpe:2.3:a:geovision_inc.:gv-eye:*:*:*:*:*:*:*:*) identifies GeoVision Inc.'s GV-Eye as the affected product family, with EUVD-2026-91147 pinning the affected release to V3.6.0. The public CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5) models the API abuse as remote; the independent assessment instead applies AV:L because the extraction step requires local possession and reverse engineering of the client package, while still agreeing on the high confidentiality impact and the absence of integrity, availability, or scope effects. The accompanying 'Authentication Bypass' tag reflects that possession of the key lets a party authenticate to the vendor backend as an authorized client without going through legitimate credential issuance.
Know when Android gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Key extraction requires local possession and reverse engineering of the APK (AV:L), needs no privileges (PR:N), and yields credential disclosure (C:H) with no direct integrity or availability impact.
Primary rating from Vendor (GV).
CVSS VectorVendor: GV
DescriptionCVE.org
An API key is hardcoded and retrievable from the application package. Since Android applications can be reverse engineered, embedding sensitive API credentials directly in the client application may allow unauthorized users to extract and misuse the key.
Executive ViewAI
GeoVision's GV-Eye Android application (V3.6.0) embeds a hardcoded API credential that any party who downloads and reverse engineers the public APK can extract and reuse against GeoVision backend services. Because the exposure is limited to data confidentiality rather than code execution or service disruption, the practical risk depends on how much backend data and functionality that single key authorizes - meaning the blast radius is set by GeoVision's server-side key scoping and rotation practices, not by the app itself. Leadership should care because organizations that deployed the app derive no protection from existing mobile controls, and any data reachable by the key should be considered potentially exposed until the credential is revoked.
No vendor-released patch identified at time of analysis. Interim mitigations: request GeoVision rotate or revoke the embedded API key server-side; verify and narrow the key's permission scope and data access; remove or block GV-Eye V3.6.0 via MDM where not business-required; front backend APIs with rate limiting, IP/device allowlisting, and anomaly alerting; monitor API logs for unauthorized or abnormal use attributable to the leaked credential; require secure credential storage and secret-scanning in future mobile app releases.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows and OS X and before 11.2.202.466
Integer underflow in the MPEG4Extractor::parseChunk function in MPEG4Extractor.cpp in libstagefright in mediaserver in A
Android 3.0 through 4.1.x on Disney Mobile, eAccess, KDDI, NTT DOCOMO, SoftBank, and other devices does not properly imp
Integer overflow in the SampleTable::setSampleToChunkParams function in SampleTable.cpp in libstagefright in Android bef
Apktool versions 2.9.1 and prior contain a path traversal vulnerability when processing Android APK files. Malicious APK
An elevation of privilege vulnerability in the Android system (art). Rated high severity (CVSS 7.8), this vulnerability
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
Use-after-free vulnerability in Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows
Use-after-free vulnerability in Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows
Android 1.6 Donut through 4.2 Jelly Bean does not properly check cryptographic signatures for applications, which allows
luni/src/main/java/java/io/ObjectInputStream.java in the java.io.ObjectInputStream implementation in Android before 5.0.
The Broadcom Wi-Fi driver in the kernel in Android 4.x before 4.4.4, 5.x before 5.1.1 LMY49G, and 6.x before 2016-02-01
EUVD-2026-91147
GHSA-mwfx-8rgq-rc8f
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB