GV-Eye EUVD-2026-91148

Exploitation requires the attacker to occupy an on-path/man-in-the-middle position able to observe the victim's network traffic (e.g., shared LAN, public/unencrypted Wi-Fi, a compromised router, or any intermediate hop) while GV-Eye V3.6.0 sends the affected request. The vulnerable behavior is the application transmitting a sensitive key as a URL parameter over HTTP rather than HTTPS, so the key appears in cleartext. Limiting factors: the attacker cannot exploit this remotely without traffic visibility - there is no server-side trigger an arbitrary internet attacker can reach; the key is only exposed when the specific HTTP request carrying it is actually made, and the exposure disappears if the deployment or endpoint already enforces TLS.

This is a genuine but context-limited confidentiality issue rather than a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H) yields 7.5 (High), driven entirely by confidentiality impact (C:H) with no integrity or availability effect. However, the CVSS vector arguably overstates ease of attack: the description explicitly requires an attacker 'with the ability to monitor network traffic' - i.e., a man-in-the-middle/on-path position - which in practice is a meaningful precondition and would more honestly map to AC:H rather than AC:L. No EPSS score, 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; exploitation status cannot be elevated beyond theoretical. No SSVC decision data was supplied. Net: the technical impact (plaintext leakage of a sensitive key) is real and the fix (enforce HTTPS) is straightforward, but real-world risk is gated by the attacker needing network-path access to the victim's traffic, and by the niche deployment footprint of GeoVision GV-Eye. Treat as a standard-priority patch, not a drop-everything issue, absent evidence of exploitation.

A user of the GeoVision GV-Eye application triggers a request that includes a sensitive key as a URL parameter, but the request is sent over plaintext HTTP instead of HTTPS. An attacker positioned on the same network segment, a shared/public Wi-Fi link, or any intermediate hop passively captures the traffic and reads the key directly from the URL. No public exploit code was identified in the provided data; the attack requires only standard packet-capture tooling once the attacker is on the network path.