Unit 42 extracted every synced passkey from a Windows machine. Ars Technica called it a nothingburger

What Unit 42 actually demonstrated

On 3 August 2026, Arie Olshtein of Palo Alto Networks Unit 42 published the third part of a series on passwordless authentication. It describes three attacks against Google's synced passkey implementation, named with more humour than the subject usually attracts.

The three Pass-ta-key attacks

Attack	What it achieves	The assumption it breaks
Pass-ta-key	Account takeover with no privilege escalation, no device unlock and no user interaction	That a passkey login proves a person was present
Silver Pass-ta-key	Convinces the Google Cloud Authenticator that a biometric unlock happened, taking over the account without using the victim device at all	That the verification step was actually performed
Golden Pass-ta-key	Extracts every synced passkey in a form that can be shared or sold on the credential black market	That a private key cannot be copied off the device

The scope is narrower than the headlines suggest, and Unit 42 states it plainly: Google Password Manager, in Chrome, on Windows, on machines with a TPM. Chrome persists synced credentials locally as proto-encoded WebauthnCredentialSpecifics records inside its sync database, at a path anybody can go and look at right now:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Unit 42's own note on that store is the sentence to take to a design review: reading those records does not require elevated privileges. Before any of the three attacks runs, it tells an attacker every site where the victim holds a passkey.

Then there is the sentence most of the coverage skipped, which is Unit 42's own disclaimer:

All presented attacks rely on malware already existing on the victim's device during the initial stage.

The research was responsibly disclosed. This is not a live unpatched hole, and nothing here is a reason to go back to passwords.

Two outlets read the same paper and disagreed

Worth showing rather than resolving quietly, because the disagreement is the useful part.

Ars Technica went further than its own headline. The piece now runs as "New Pass-ta-key attack reveals all the things we didn't know about passkeys", but the address it lives at still reads heres-why-the-new-pass-ta-key-attack-is-mostly-a-nothingburger. The slug is the first verdict, left behind in the URL bar after the headline softened.

Both readings are defensible, and a practitioner does not have to pick one. Unit 42 is right that three assumptions can be broken. Ars is right that breaking them requires code already running on the endpoint. The argument between them is not really about the research. It is about what the phrase "phishing-resistant" was ever promising.

Phishing-resistant is a narrower claim than it sounds

The specification is precise, and it holds. A passkey cannot be phished because there is no shared secret to hand over, the credential is bound to an origin, and a lookalike domain cannot elicit a valid assertion no matter how convincing the page is. Nothing in this research dents that property.

What the specification never claimed is resistance to an attacker who is already inside the machine holding the credential. Nobody promised that. Plenty of people heard it.

Where the promise stops

Unit 42 · 3 Aug 2026

Phishing-resistant, and it holds

1. 01

   Lookalike domain

   A convincing sign-in page on an origin that is not yours

2. 02

   Origin binding refuses

   There is no shared secret to type, and no valid assertion to make

3. 03

   The attacker gets nothing

   This holds however good the page is, and this research does not dent it

The specification stops here

Nothing below this line was ever claimed, and it was very widely assumed.

Never claimed, and where all three attacks begin

1. 01

   Malware already on the device

   Unit 42's own precondition for all three attacks

2. 02

   Read the Chrome sync store

   Proto-encoded WebauthnCredentialSpecifics records, held locally

3. 03

   Forge presence and verification

   Pass-ta-key and Silver: no unlock, no interaction, no victim device

4. 04

   Export every synced key

   Golden: a resaleable credential, in a model built to remove one

That is why "extracts every synced passkey" and "mostly a nothingburger" are both accurate sentences about the same paper. The first describes the outcome. The second describes the precondition. A control is not defeated by an attack that only begins after the control has already done its job.

The fourth time this week

Four stories, one shape

1. 11 Aug

   Daybreak

   OpenAI ships a model that finds exploit chains. The refusal rate is a dial, and the dial is somebody else’s setting.

2. 12 Aug

   Patch Tuesday

   The only exploited flaw in 420 is rated Important. Severity scores the vulnerability and says nothing about who wants it.

3. 12 Aug

   Grok Bot

   Sensitive actions can go through Auto Review. Can, not do, and the containment controls sit on a waitlisted tier.

4. 13 Aug

   Pass-ta-key

   Phishing-resistant still holds exactly as specified. Theft-resistant was never claimed, and was very widely assumed.

In every case the control does what its specification says. In every case the gap sits between that specification and the sentence somebody put on a slide. That gap is not a vulnerability, no patch closes it, and it is precisely why it keeps producing incidents.

What this changes for a rollout

Nothing here is a reason to slow passkey adoption. Passwords remain the worse option by a distance and the credential theft market really is being disrupted. But some of the deployment guidance written over the last three years needs revisiting.

The first item is the one to do this week, because it is cheap, it is a property of your own estate rather than Google's, and a relying party that ignores the User Verified flag is a single-factor login wearing a passkey badge.

The position

The research is good and some of the reporting around it was worse than the research. A finding that requires local malware is not a passkey break, and saying so out loud is not defending a vendor.

But the correction has its own failure mode. "Mostly a nothingburger" invites a reader to conclude that nothing changed, and something did. Before this paper, a synced passkey on a compromised machine was a problem for that account on that machine. After Golden Pass-ta-key it is an exportable asset that can be listed for sale, and the entire point of moving to public-key credentials was that there would be nothing left worth selling.

So the honest summary is narrower than either headline. Passkeys still end phishing. They were never going to end malware. The industry has spent three years letting people hear the first as the second, which is a communications failure rather than a cryptographic one, and considerably harder to patch.