Google Chrome CVE-2026-79091

Exploitation requires the victim to be running Google Chrome on macOS at a version below 152.0.7977.65 and to be socially engineered into opening an attacker-controlled crafted HTML page (CVSS UI:R confirms required user interaction). No authentication is needed (PR:N) and the attack is over the network (AV:N) with low complexity (AC:L), but the mandatory user interaction and the macOS-only, pre-152.0.7977.65 scope are the key limiting factors - there is no drive-by or unattended-server exposure, and default configurations are only at risk once a user actively loads the malicious content through Chrome's Bluetooth-exposing surface.

The signals conflict and should be weighed carefully. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 9.6 Critical) is driven largely by the scope change from a sandbox escape and full CIA impact, yet Chromium's own security team rated this Medium, and CISA's SSVC records Exploitation: none and Automatable: no (Technical Impact: total). EPSS was not provided. There is no KEV listing and no POC referenced, so this is not confirmed exploited. The AC:L but UI:R combination means exploitation is technically simple once a victim is engaged but always requires social engineering to open a malicious page - it is not automatable or wormable. Net: a genuinely serious memory-corruption sandbox escape worth prompt patching, but current real-world exploitation risk is lower than the 9.6 headline suggests, closer to Chromium's Medium framing given no automatability and required user interaction.

An attacker crafts a malicious HTML page that abuses Chrome's Bluetooth handling and, using phishing or a lure link, convinces a macOS user to open it in a vulnerable Chrome build. Loading the page triggers the use-after-free, and the attacker reuses the freed memory to execute arbitrary code that breaks out of the renderer sandbox into the browser process. No public POC is referenced, so this remains a described attack path rather than a demonstrated exploit.