Google Chrome CVE-2026-79055

Exploitation requires two concrete prerequisites: (1) a malicious application must already be installed on the victim's Android device and registered as a Chrome share recipient - this requires the attacker to have previously achieved app installation through social engineering, sideloading, or a compromised distribution channel; and (2) the victim must be induced (via additional social engineering) to actively use Chrome's Sharing feature in a context where sensitive information is passed. The vulnerability is strictly limited to Android; Chrome on desktop platforms is not affected. The high attack complexity (AC:H in the provided CVSS) directly encodes both prerequisites. Exploitation is further bounded by requiring the attacker to have physical-proximity-equivalent access (a co-installed app), ruling out remote-only threat actors without a prior foothold. No special victim authentication state is required - the attack targets the inter-app communication channel regardless of whether the user is signed into Chrome.

Real-world risk is low despite the CVSS C:H rating. The EPSS score of 0.15% (4th percentile) reflects very low exploitation probability, consistent with Chromium's own Low internal severity designation. The attack requires two sequential prerequisites - a co-installed malicious application AND successful social engineering - both of which create substantial friction for opportunistic attackers. CVSS AV:L and AC:H explicitly encode these barriers. No active exploitation is recorded in CISA KEV and no public exploit code has been identified at time of analysis. The provided CVSS shows PR:N (no privileges required), which is technically accurate once the attacker has achieved app installation, but that installation step is itself a meaningful barrier not reflected in the base score. The combination of local-only access, high complexity, and social engineering dependence makes this a low operational priority for most enterprise environments, though it warrants standard patch cadence for mobile-fleet administrators.

A threat actor convinces an Android user to install a seemingly benign application - via phishing, fake app store listing, or direct social engineering - that secretly registers itself as a Chrome Sharing recipient. When the victim subsequently uses Chrome's native Share function (for example, sharing a page URL or document), the malicious app intercepts the intent and captures whatever sensitive data Chrome passes through the sharing mechanism, potentially including authenticated URLs, page titles, or clipboard content. No public exploit code exists at time of analysis, so exploitation currently requires a custom-developed malicious app.