Google Chrome CVE-2026-84327

Victim must be using Google Chrome on Android (not desktop). Attacker must successfully socially engineer the victim into visiting a crafted HTML page - passive drive-by exploitation without any user interaction is not possible given UI:R. Chrome Autofill must have data stored on the device for the exfiltration to yield meaningful sensitive information; a fresh Chrome install with no saved data limits impact. The attack is unauthenticated from the attacker's perspective (no credentials to the victim's device or browser required). Exploitation is limited to the Android platform only; Chrome desktop is not listed as affected.

The NVD-assigned CVSS 6.5 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) scores this as medium severity, but Google's own internal Chromium severity rating of 'Low' represents a meaningful downgrade signal. This discrepancy likely reflects that the actual data exposed may be limited in scope, or that the social engineering prerequisite substantially raises exploitation friction in practice. No EPSS score was provided, and the vulnerability does not appear in CISA KEV. No public exploit code has been identified. The SSVC technical impact is partial (confidentiality only, no integrity or availability effect), and the 'automatable' dimension is No given UI:R with social engineering required. Real-world priority is low-to-medium: Chrome on Android has enormous deployment scale, but exploitation requires per-victim social engineering, limiting mass exploitation potential. Defenders at organizations with high-value Autofill data (credentials, payment info) stored in Chrome on Android should prioritize the update.

An attacker sends a phishing message to a victim directing them to a crafted web page hosted on an attacker-controlled server. When the victim opens the page in Chrome for Android, the HTML exploits the Autofill authorization flaw to read sensitive data stored in Chrome Autofill - such as saved usernames, email addresses, or other form data - and exfiltrates it to the attacker's server. No public proof-of-concept exploit has been identified, so the precise HTML/JavaScript technique required is not publicly known.