Critical Google Chrome Bug Lets Malware Steal Passkeys

Key Takeaways

• Malware on a compromised Windows PC can exploit a critical Google Chrome vulnerability to steal synced passkeys.
• The flaw allows attackers to hijack user accounts without requiring passwords, PINs, or biometrics.
• The “Pass-ta-key” family of attacks leverages weaknesses in Chrome’s handling of identity keys and passkey recovery processes.
• A fix is not explicitly mentioned for all aspects, but some affected services have patched their verification gaps.

Chrome Bug Exposes Google Passkeys to Malware Hijack

New research has uncovered a critical flaw in Google Chrome that enables malware on an already compromised Windows machine to silently steal synced passkeys, granting unauthorized access to user accounts without any password, PIN, or biometric prompts. This vulnerability undermines the very security benefits passkeys were designed to deliver.

The findings, part of an ongoing series by researchers at Unit 42 examining the security landscape of passwordless authentication, highlight significant weaknesses in how Google’s Cloud Authenticator manages device trust, onboarding, and recovery mechanisms.

Passkeys were introduced as a robust replacement for traditional passwords, leveraging public-key cryptography to eliminate shared secrets vulnerable to phishing and credential stuffing. However, this new research demonstrates that implementation details can introduce new attack vectors.

Unit 42 researchers found that Chrome stores critical passkey metadata locally in an unencrypted and easily accessible database. This provides malicious software with a clear map of every service where a user employs passkey login, all without requiring elevated system privileges.

The core of the problem lies in Chrome’s management of its “identity key,” a hardware-backed credential intended to verify device ownership to Google’s Cloud Authenticator. Instead of being securely locked within the Trusted Platform Module (TPM), this key is generated as a temporary, exportable data blob. This allows malware to extract the key and use standard Windows cryptography APIs to forge authentication requests, mimicking legitimate Chrome behavior.

This exploitation enables a complete passkey login, dubbed the “Pass-ta-key” attack, to proceed silently, bypassing any expected device unlock or biometric verification prompts.

Bypassing Multi-Factor Protections

A more sophisticated variation, the “Silver Pass-ta-key” attack, takes the compromise further by circumventing user verification entirely. By corrupting or deleting the local passkey state file, attackers can force Chrome into a re-onboarding sequence. During this critical window, the Cloud Authenticator accepts a newly registered, attacker-controlled verification key without properly validating its origin. This effectively grants the attacker a persistent and reusable authentication method, allowing them to impersonate the victim from their own machine, even for accounts protected by stringent multi-factor authentication.

The most severe attack identified is the “Golden Pass-ta-key” attack, which targets the master encryption key, known as the security domain secret (SDS), that protects all of a user’s synced passkeys.

Researchers discovered this 32-byte secret was briefly exposed in Chrome’s internal logs and remains accessible in memory during device recovery processes. Extracting this secret allows an attacker to decrypt every passkey associated with an account, both current and future. This creates a persistent access vector that can survive even after the initial compromise is detected, largely because Google currently does not offer a mechanism to rotate this master key.

The researchers emphasize that these attacks do not signify a fundamental cryptographic break in passkey technology. Instead, they exploit discrepancies between design assumptions and real-world implementation, particularly concerning the level of trust implicitly placed in client devices and inconsistencies in validation by relying parties. Following responsible disclosure, some affected services, including eBay, have already implemented patches to address these verification gaps.

What You Should Do

• Enforce strict user-verification checks on all critical authentication flows.
• Implement robust validation of device key attestation before allowing new passkey registrations.
• Restrict local access to browser credential stores through endpoint security measures.
• Monitor for any unexpected re-triggering of onboarding or recovery processes for passkey-enabled accounts, as this could indicate an ongoing attack.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.