Google Chrome EUVD-2026-50639

Exploitation requires two sequential conditions: first, the attacker must have already compromised the Chrome renderer process (a separate, preceding vulnerability is required); second, the victim user must interact with a crafted HTML page (UI:R), providing the entry point for the DevTools input validation flaw. DevTools must be accessible in the target Chrome installation - disabling DevTools via enterprise policy would eliminate this attack vector. Limiting factors include the renderer pre-compromise prerequisite (AC:H), required user interaction, and the necessity of a network-reachable victim. The CVSS vector PR:N indicates no authenticated session is needed from the attacker's perspective for the DevTools stage itself, but the renderer compromise prerequisite is a significant practical barrier. This is not a default-configuration remote unauthenticated exploit; it is a second-stage sandbox escape chained after a separate renderer vulnerability.

Despite a CVSS base score of 5.8 (Medium), the real-world risk is nuanced. The S:C (Scope Changed) metric confirms that successful exploitation breaches the Chrome sandbox - an impactful outcome. However, AC:H indicates high attack complexity: exploitation requires a prior renderer process compromise as a prerequisite, making this a second-stage payload rather than a standalone exploit. UI:R further constrains exploitability to scenarios where a victim visits a crafted HTML page. EPSS of 0.18% (8th percentile) confirms low observed exploitation in the wild, consistent with the chained-exploit requirement. No CISA KEV listing is present. The C:L/I:L/A:L impact triplet assigned by Google reflects a conservative view of the sandbox escape scope - notably, a full sandbox escape could plausibly achieve higher host-level impact than these metrics suggest; defenders should not assume the escape is harmless. This is a genuine medium-priority issue: critical for users in targeted threat scenarios but unlikely to see mass automated exploitation due to AC:H and the renderer pre-compromise requirement.

An attacker who has already achieved renderer process compromise - for example, via a separate memory corruption bug in Chrome's JavaScript engine - serves the victim a crafted HTML page that triggers malicious DevTools interactions. The insufficient input validation in DevTools processes the attacker-controlled renderer data without proper sanitization, allowing the attacker to break out of Chrome's sandbox and execute code at the host OS privilege level. No public exploit or proof-of-concept code has been identified at time of analysis.