C6 Ear Camera EUVD-2026-75053

Attacker must be on the same adjacent wireless network segment as the victim (AV:A - same WiFi network or directly adjacent wireless range). The victim must actively initiate or use the EarVision app session (UI:A - passive background conditions alone are insufficient). No authentication credentials, special privileges, or non-default device configuration are required on the attacker's side. Both the EarVision Android app (v1.3.1) and C6 Ear Camera (v1.3.1_Code 132) must be in the environment. Limiting factors: proximity requirement (adjacent network) rules out remote internet-based attacks; user interaction requirement reduces fully passive exploitation; the attack is opportunistic only in shared-network contexts such as home networks, clinical WiFi, or public hotspots.

The CVSS 4.0 score of 8.4 (AV:A/AC:L/AT:N/PR:N/UI:A) reflects a meaningful but proximity-limited risk. The adjacent-vector (AV:A) constraint is the primary limiting factor: exploitation requires the attacker to share the same wireless network segment as the victim, significantly reducing the attack surface compared to internet-facing vulnerabilities. Active user interaction (UI:A) further constrains opportunistic mass exploitation. However, the dual High confidentiality and integrity impacts on the vulnerable system (VC:H/VI:H) are serious - ear camera imagery is potentially sensitive patient or personal medical data, and integrity compromise via firmware manipulation could affect device behavior long after the initial attack. No POC is publicly available and the vulnerability is not in CISA KEV, suggesting no observed mass exploitation. The primary real-world risk scenario is a targeted attack in a shared-WiFi context (clinic waiting room, home network shared with malicious actor). The firmware-update trigger is the highest-risk element, as it could enable persistent device-level compromise.

An attacker connected to the same WiFi network as a user operating their C6 ear camera sets up a rogue wireless access point or device that advertises the same camera identity, exploiting the lack of device authentication in the EarVision protocol. The EarVision Android app connects to the rogue device, and the attacker intercepts ear imagery requests, replays or fabricates device status responses, and - in the most severe case - serves a crafted firmware image to the camera via the triggered firmware-update path. No public proof-of-concept code was identified at time of analysis, but the attack requires only adjacent network positioning and standard network tooling.