◄ part 1Layers upon layersBut let's assume, as Tóth does, that the website operator has catastrophically ignored one of the most important and well-known techniques for securing an authentication workflow. Tóth's exploit still involves some other non-trivial pre-conditions.
The first of these involves the installation of a malicious script into your web browser. Pointing to a 2019 HackerOne post that documented the existence of a malicious XSS on PayPal, Tóth says that end-users should assume that even the most reputable and supposedly well-defended websites can be the source of such malicious scripts. In my conversations with him, he noted that sites that include a significant amount of user-generated content are a favorite target of threat actors because they can add scripts to a post or a review and, if the site lacks the adequate protections to refuse such entries (another act of negligence on behalf of the site operator), all an innocent user must do is visit that post or review in order to execute the malicious script.
Assuming a user stumbles across such a site and loads the malicious script into his or her browser, the script must surreptitiously trick the user into inadvertently launching an authentication ceremony with a type of attack known as a clickjack attack.
As the phrase suggests, a clickjack attack happens when a threat actor tricks you into clicking on a clickable element (e.g., a button or a link) that might not be visible to you. In Tóth's exploit, the malicious JavaScript paints the browser window with a seemingly innocent dialog like a pop-up ad or cookie consent form -- the sort of thing we see all the time and just want to clear off our screen. However, when we click on that element to get rid of it, what we don't realize is that we're actually clicking on something else that was hidden behind it. Insidious, right?
At that moment, your mouse click has essentially been hijacked. But what have you actually clicked on?
In Tóth's proof-of-concept, his malicious script involves a hidden login form, which in turn triggers your password manager into action (as password managers typically do when they detect the presence of a login form). Then, the click he hijacks is the one that instructs the password manager to prepare a golden ticket for transmission back to the legitimate website. Theoretically, since the login form was concealed from view, you don't even realize that you've just completed a passkey authentication ceremony. Once the password manager readies that ticket for transmission, the malicious script intercepts it and, instead of sending it (with an HTTP POST command) to the legitimate server, it HTTP POSTs it to the attacker's server as described earlier.
But, as was just suggested, the attack isn't possible without the involvement of the user's password manager. So, what -- if anything -- can be done by the password manager to mitigate the attack?
The pros and cons of naggingWhen proponents describe passkeys as being more secure than traditional credentials, they often talk about how the passkey process is as simple as logging into your phone with a biometric (fingerprint, Face ID, etc.) or PIN code. For example, on one of its support pages, Microsoft states, "Passkeys are a replacement for your password. With passkeys, you can sign into your Microsoft personal account or your work/school account using your face, fingerprint, or PIN." Even the FIDO Alliance-operated passkeycentral.org's introduction to passkeys states, "A passkey is a FIDO authentication credential based on FIDO standards, that allows a user to sign in to apps and websites with the same steps that they use to unlock their device (biometrics, PIN, or pattern)" -- as though that's always the case.
Other passkey proponents include strikingly similar language on their websites that makes it sound as though every time you try to authenticate with a passkey, you'll have to furnish a biometric or PIN to complete the process (similar to that of logging into a mobile app that prompts you for a fingerprint). However, this is mainly the case when your password manager is also configured to require a biometric or PIN for every authentication attempt. Since some users don't want to be nagged with this additional layer of security each time they login to a website, most password managers give users the option of relaxing the nagging. In other words, you can set it to nag you every time, every now and then, or never.
Recall that Tóth's exploit depends on the user getting tricked into inadvertently authenticating with a website. In other words, it hides all the visual cues that an authentication is in progress so as not to alert the user to the possibility of suspicious activity. If your password manager is configured the way mine is -- to require a PIN or a biometric to allow any authentication ceremony to continue -- you would instantly realize that something is amiss. Suppose, for example, the clickjack attack requires you to click the "Accept" button on a cookie consent form. If your password manager suddenly springs to life, asking for your fingerprint or a PIN after clicking that button, it should be a glaring red flag not to continue. A cookie consent form doesn't need your fingerprint.
By setting your password manager to more aggressively prompt you for your fingerprint, PIN, or password, you're essentially adding a pause button to the authentication process. It gives you a chance to confirm that the password manager is doing something that you actually intended it to do. Choosing a more relaxed setting for this preference is the equivalent of relinquishing an important user-controlled layer of security to threat actors.
Tóth agreed with this assessment but noted that many users might be unaware of how, during installation, some password managers default to a more permissive setting. It's a fair point. But it's also a reminder of how, in the constant pursuit of great personal opsec (operational security) practices, users must progressively take security precautions after educating themselves on the security options that are available to them.
The nuclear optionHowever, even when users have neglected to batten down their hatches, website operators have a special nuclear option at their disposal. In addition to making all authentication ceremonies session-bound and applying the necessary countermeasures to prevent threat actors from installing malicious JavaScript into users' browsers, relying parties also have the power to override users' preferences for when password managers prompt them for their biometrics, PINs, or passwords.
When the relying party sends the aforementioned challenge to the password manager as a part of the PublicKeyCredentialRequestOptions payload, it can also include a special flag called the userVerification parameter. This parameter allows for three possible settings: Discouraged, Preferred, and Required. If the relying party sets the userVerification flag to "Required", the password manager is obligated to prompt the user for a biometric, PIN, or password regardless of how the user has configured that password manager. In other words, the website operator has a way of forcing the user to experience the prompt in a way that should alert them to the website's unexpected behavior.
There is one possibility that would render the nuclear option moot: What if the password manager simply doesn't honor the "Required" option when specified by the relying party? But, of the password manager providers I randomly sampled (1Password, BitWarden, LastPass, and NordPass), all indicated that they fully honor the "Required" setting when specified as a part of the PublicKeyCredentialRequestOptions from the relying party.
If you see something, say something OK. As an end-user, you have little to no control over the sites you visit. You're acting on blind faith that they're doing all they can do to stop an attack of this nature -- but you can never be sure. At the same time, you're logging in and out of so many sites that setting your password manager for its most aggressive form of re-authorization is driving you crazy, and you're left wondering if there's an alternative safety net.
To answer that question, we need to go back to the password managers. As it turns out, in order for your password manager to do what it does, you must grant it the sort of permissions that you should pretty much never give to any other web browser extension. Your password manager can not only read all of the content of every web page you visit, but it can modify it as well. And, because of those permissions, your password manager can also spot the telltale signs of a clickjack attack in progress.
For example, in order to do what it normally does (e.g., autofill user IDs and passwords), your password manager must detect the presence of a login form. However, because the password manager can parse through every bit of HTML that makes up a web page, it can also take action after detecting if a login form is concealed from your view or if that login form is overlaid by other clickable objects (the true mark of a clickjack attack).
Although I didn't contact all password manager vendors, I spot-checked with a handful. Not surprisingly, updated versions of their software are in the works or have already been released.
"Bitwarden has implemented mitigations for this class of attack in the most recent releases out last week," according to BitWarden director of communications Mike Stolyar. "Recent updates introduced safeguards that disable inline autofill when site styling suggests potential manipulation, such as hidden overlays or opacity changes."
Via email, 1Password CISO Jacob DePriest told me that "on Aug. 20, 2025, we released version 8.11.7, which adds the option for users to be notified and approve or deny autofill actions before they occur. This extends the existing confirmation alert for payment information, an alert that cannot be hidden or overlaid by clickjacking, giving users greater visibility and control before anything is filled."
"NordPass icons are now rendered with the highest z-index, preventing anything from being overlaid on top of them," said NordPass head of business product Karolis Arbaciauskas. "It is also now impossible to change the dialog's style attribute, which previously allowed the dialog to be made invisible."
LastPass has also strengthened its defenses against potential clickjack attacks. The latest update "is to detect zero-opacity types of elements and not [autofill]," said LastPass director of product management Greg Armanini. When I asked if LastPass gives the user a warning about any potential risky behavior that it might have observed on the current web page, Armanini responded that "in the first release, it will just appear as though nothing happens." But, [if we decide to take the fix a step further], it would probably be similar to what we do already for your credit cards, which is a prompt to say 'Before you do this, be sure you trust this site.'"
Meanwhile, Tóth is monitoring the various password managers to see how their updates -- some already applied, others still forthcoming -- are faring against his test methodology. He was also quick to point out how the updates alone won't help unless users install those updates. As long as users stay on old versions of their password managers, they could fall prey to a zero-opacity clickjack attack.
Finally, despite the potential for a threat actor to hijack a passkey authentication ceremony once the non-trivial preconditions are met, Tóth's exploit offers additional evidence that passkeys are more secure than traditional credentials. Session-binding renders the one-time passkey-generated golden ticket unusable from the attacker's system. However, it does nothing to stop the threat actor's exfiltration of the user's ID and password when Tóth's clickjack attack encounters an attempt to authenticate with those traditional credentials versus the more time-sensitive and secure passkeys.
source
