Deep-Dive Analysis of the New Threat to Password Manager Security

This article provides a comprehensive technical analysis of the vulnerability, a critical assessment of the divergent industry response, and exhaustive mitigation strategies for end-users and enterprises.

In August 2025, the cybersecurity landscape was altered by the disclosure of a novel and potent vulnerability affecting the browser extensions of many of the world's most popular password managers. Presented at the DEF CON 33 security conference by independent researcher Marek Tóth, the attack technique, termed "DOM-based extension clickjacking," was found to impact products used by tens of millions of individuals and organizations, creating a significant risk of widespread credential and data theft. This report provides a comprehensive technical analysis of the vulnerability, a critical assessment of the divergent industry response, and exhaustive mitigation strategies for end-users and enterprises.

The attack's mechanism represents a significant evolution from traditional clickjacking methods. Classic clickjacking relies on layering a transparent <iframe> containing a target website over a decoy page to hijack user clicks. In contrast, DOM-based extension clickjacking does not use iframes. Instead, it leverages a malicious website's ability to execute JavaScript that directly manipulates the visual properties of user interface (UI) elements that the password manager extension itself injects into the webpage's Document Object Model (DOM). By setting the opacity of an autofill prompt to zero or covering it with another element, an attacker can render it completely invisible. This invisible, yet still interactive, element is then precisely aligned with a benign-looking decoy on the page, such as a cookie consent button, a CAPTCHA checkbox, or a pop-up's close icon. An unsuspecting user, intending to interact with the decoy, inadvertently clicks the invisible password manager prompt, triggering the autofill action and exfiltrating their stored data to the attacker.

The scope of the potential data compromise is extensive and severe. The attack can be used to steal not only usernames and passwords but also a wide range of other sensitive information stored within the password vault. This includes credit card details, personal identifying information (PII) such as names and addresses, Time-based One-Time Password (TOTP) codes, and even modern authentication credentials like passkeys. The ability to steal a password and its corresponding TOTP code in a single, user-initiated action effectively neutralizes this common form of two-factor authentication. The research demonstrated that all 11 of the major password managers tested were vulnerable to at least one variant of the attack, underscoring a systemic weakness in the way these extensions interact with web content.

The response from the affected vendors has been markedly inconsistent, revealing a significant philosophical divide on security responsibility within the industry. A number of vendors, including Dashlane, Keeper, and NordPass, responded proactively by developing and deploying patches to mitigate the threat. Others, such as Bitwarden, acknowledged the issue and released a fix shortly after the public disclosure. However, two of the market's largest players, 1Password and LastPass, initially categorized the vulnerability report as "informative" rather than a direct flaw in their products. Their position posits that clickjacking is a general, browser-level risk that should be mitigated by the user or the browser itself, not the extension. This stance of deflecting responsibility stands in stark contrast to the majority of the market and raises critical questions about the security assurances provided to their customers.

Given the severity of the threat and the inconsistent state of patching across the market, immediate user action is required. The most critical and effective mitigation is to disable the automatic autofill feature within the password manager's browser extension settings. For users of Chromium-based browsers (such as Google Chrome and Microsoft Edge), an additional and highly effective layer of defense is to configure the extension's "site access" setting to "On click." This measure prevents the extension from activating on a webpage until the user explicitly clicks its icon in the browser's toolbar, thereby breaking the attack chain. These steps should be considered essential until all vendors have issued comprehensive and verified patches.

The Anatomy of a Modern Clickjacking Attack

To fully appreciate the novelty and severity of the DOM-based extension clickjacking vulnerability, it is essential to first understand the mechanics of its predecessors and the specific architectural choices in modern browser extensions that created this new attack surface. The technique disclosed by Marek Tóth is not merely an incremental improvement on an old attack; it is a fundamental shift in the targeting of clickjacking, moving away from the webpage itself and towards the trusted security tools that users have installed to protect them.

2.1 A Primer on Traditional Clickjacking (UI Redress Attacks)

Clickjacking, also known as a "UI redress attack," is a well-established client-side attack technique where an attacker uses multiple transparent or opaque layers to deceive a user into clicking on a button or link on a page other than the one they believe they are interacting with. The classic execution of this attack involves the use of an HTML

This method has been used in various high-profile attacks over the years, including exploits against Adobe Flash settings pages to gain access to a user's microphone and camera, and the propagation of Twitter worms by tricking users into retweeting malicious links. However, the impact of traditional, iframe-based clickjacking has been significantly curtailed by modern browser security models. The Same-Origin Policy, a cornerstone of web security, generally prevents a page from one origin (the attacker's site) from interacting with the content of an iframe from another origin (the target site). More importantly for clickjacking, modern browsers often prevent a user from being considered "authenticated" within a cross-site iframe. This means that even if an attacker can trick a user into clicking a button, the resulting action may fail because the target site does not recognize the user as being logged in.

To counter this threat directly, web developers have been provided with specific defense mechanisms. The most common are HTTP response headers sent by the server to the browser, instructing it on how the page may be framed. The older X-Frame-Options header can be set to DENY (preventing all framing) or SAMEORIGIN (allowing framing only by pages from the same domain). Its more modern and flexible successor, the

Content-Security-Policy (CSP) header, includes a frame-ancestors directive that provides more granular control over which domains are permitted to embed the page. The widespread adoption of these server-side defenses has made traditional iframe-based clickjacking attacks against well-configured websites increasingly difficult to execute successfully, compelling attackers to seek new methods.

2.2 The Evolution: DOM-Based Manipulation of Browser Extensions

The research presented by Marek Tóth introduces a paradigm shift by circumventing these traditional defenses entirely. The core innovation of DOM-based extension clickjacking is that it does not use iframes. Instead of attempting to load an external target site, the attack targets the UI elements that the password manager browser extension

itself injects directly into the Document Object Model (DOM) of the current webpage. This is a critical distinction. Password managers, in order to provide the convenience of autofill, must dynamically add their own HTML elements—such as the small icon inside a login field or the dropdown menu that appears when a user clicks on it—to the structure of the page the user is viewing.

This architectural necessity creates a unique and vulnerable situation. The DOM of a webpage is, by definition, a space that is fully scriptable and controllable by the website itself. When a password manager injects its UI, it is placing a trusted element into an untrusted environment. The fundamental principle of the attack is to leverage the website's control over its own DOM to find and manipulate these extension-injected elements. A malicious script running on the attacker's page can programmatically identify the HTML elements corresponding to the password manager's autofill prompt and alter their CSS properties to render them invisible to the user, all without the user's knowledge or consent.

This approach brilliantly sidesteps all the defenses designed to prevent iframe-based attacks. Since no cross-origin framing is involved, headers like X-Frame-Options and CSP: frame-ancestors are completely irrelevant. The attack occurs entirely within the DOM of a single page, exploiting the inherent trust a user places in the familiar UI of their security software. The password manager is not being attacked at its core—the encryption and the secure vault remain intact. Rather, the attack targets the insecure interface layer where the extension's functionality meets the untrusted content of the web. This exploitation of the trust boundary between the user and their extension is the defining characteristic of this new vulnerability class. The user sees their password manager's icon, trusts the subsequent UI that appears, and is unaware that this very UI has been turned into an invisible trap by the page they are visiting.

2.3 Attack Vectors and Exploitation Scenarios

The execution of a DOM-based extension clickjacking attack involves a two-pronged strategy: first, rendering the password manager's UI invisible, and second, overlaying a convincing decoy to hijack the user's click. The research demonstrated several sophisticated methods for achieving this.

The most straightforward technique is Opacity Manipulation. Using a simple line of JavaScript, the attacker's script can find the password manager's autofill dropdown menu in the DOM and set its CSS opacity property to 0. This makes the element completely transparent, but crucially, it remains in the same position in the page's layout and is still fully interactive. The attacker then places a visible decoy element, like a button, directly underneath the now-invisible password manager prompt.

A more robust method involves Overlaying. An attacker can place a decoy element, such as a large cookie consent banner, over the top of the password manager's UI. Normally, this would prevent clicks from reaching the elements underneath. However, by setting the CSS property pointer-events: none on the overlaying decoy, the attacker instructs the browser to ignore all mouse events on that element. This allows the user's click to "pass through" the visible decoy and register on the invisible password manager element hidden beneath it. This technique is particularly effective as it can be used to cover large portions of the screen.

The most advanced variant demonstrated is Cursor Following. In this scenario, the attacker's script continuously monitors the position of the user's mouse cursor. It then dynamically updates the position of the invisible form and its associated password manager autofill prompt to always be directly under the cursor. The result is that

any click the user makes, anywhere on the webpage, will land on the invisible prompt and trigger the exploit. This removes the need for precise alignment and dramatically increases the probability of a successful attack.

To make these technical tricks effective, attackers must provide a plausible reason for the user to click. This is achieved through the use of carefully crafted "intrusive web elements" that serve as decoys. Users have become conditioned to interact with elements like cookie consent banners, Cloudflare-style CAPTCHA challenges, newsletter subscription pop-ups, and "Verify you are human" checkboxes. An attacker can create a pixel-perfect replica of one of these common UI patterns. A user, wanting to dismiss the banner or solve the CAPTCHA, clicks on the "Accept" or "Verify" button. This single, seemingly innocuous click is all that is required to be hijacked, trigger the invisible autofill prompt, and exfiltrate all the stored credentials and data for that website to the attacker's server.

The impact of this vulnerability is then massively amplified by two common, convenience-oriented default settings in most password managers: enabling autofill by default and using broad URI matching schemes. The research found that, by default, all tested password managers would offer to fill credentials not only on the specific domain where they were saved (e.g., https://www.secure-bank.com) but also on all of its subdomains (e.g., https://blog.secure-bank.com). This "base domain" matching creates a dangerous scenario. While compromising a high-security primary banking domain is exceptionally difficult, finding a lower-severity vulnerability, such as a cross-site scripting (XSS) flaw, on a less-maintained ancillary property like a marketing blog or a user-content subdomain is far more plausible. This default behavior acts as a force multiplier, allowing an attacker to leverage a minor flaw on a low-value subdomain to launch a devastating, high-impact attack that steals the credentials for the high-value parent domain. This mechanism dramatically lowers the barrier to entry for a successful and highly damaging compromise.

Market-Wide Impact and Vendor Accountability

The disclosure of the DOM-based extension clickjacking vulnerability sent ripples across the password manager industry, not only because of its technical ingenuity but also because of its broad applicability. The research conducted by Marek Tóth was not limited to a single product but was a systemic review of the market's leading solutions. The findings revealed a near-universal susceptibility, and the subsequent responses from vendors exposed a deep and concerning schism in their philosophies on security and corporate responsibility.

3.1 Vulnerability Landscape Across Major Password Managers

The investigation targeted 11 of the most popular password managers, and the results were stark: every single one was found to be vulnerable to at least one of the attack methods demonstrated. This indicates that the vulnerability is not the result of an isolated coding error in one product but rather a systemic issue stemming from the fundamental architectural decision to inject interactive UI elements into untrusted web pages to facilitate autofill. The attack puts the full spectrum of data stored within a password manager's vault at risk. This includes not just login credentials (usernames and passwords), but also Time-based One-Time Password (TOTP) codes, passkeys, credit card details (including expiration dates and security codes), and personal data such as names, addresses, and phone numbers.

The ability to exfiltrate TOTP codes alongside passwords in a single click is a particularly critical threat. It completely neutralizes this layer of two-factor authentication, which many users rely on as their primary defense against credential theft. The research found that 9 out of the 11 tested plugins could have their stored TOTPs stolen, and 10 out of 11 could have their login credentials compromised with just a single click.

The following table summarizes the status of the tested password managers as of late August 2025, compiling information on vulnerable versions and the nature of the vendor's response. This data provides a clear, at-a-glance overview of the industry's posture in the immediate aftermath of the disclosure.

3.2 In-Depth Analysis of Vendor Responses

The disparate reactions from the affected vendors provide a compelling case study in corporate security philosophy. The responses can be broadly categorized, revealing a clear divide between companies that accept responsibility for mitigating threats within their operational environment and those that draw a harder line, placing the onus on other layers of the technology stack or on the end-user.

The Proactive Responders (Patched): A significant portion of the market, including Dashlane, Keeper, NordPass, ProtonPass, and RoboForm, took the vulnerability report seriously and had already issued patches by the time of the public disclosure in late August 2025. These companies implicitly acknowledged that, regardless of where the root cause of clickjacking lies, they have a responsibility to implement defense-in-depth measures within their own products to protect their users. Their swift action demonstrates that mitigation at the extension level is not only considered possible but is viewed as a necessary component of providing a secure service.

The Responsive Responders (Patched Post-Disclosure): This category includes Bitwarden and Enpass. Bitwarden's response was particularly notable. While the company initially acknowledged the report but reportedly downplayed its severity, they moved quickly following the public outcry and media attention, informing BleepingComputer that a fix was being rolled out in version 2025.8.0. This response can be viewed in the context of previous security research from early 2023 by the firm Flashpoint, which highlighted a related vulnerability in Bitwarden's handling of autofill within iframes. At that time, Bitwarden had defended its decision not to fix the iframe issue, arguing it was necessary for usability. The recurrence of a fundamental autofill security issue, albeit through a different attack vector, may have contributed to their more responsive posture this time. Enpass also took action, releasing fixes to address the manipulation of their inline menu.

The "Informative" Stance (Responsibility Deflection): The most controversial responses came from two of the industry's most prominent players, 1Password and LastPass. Both companies chose to classify the vulnerability report as "out-of-scope/informative," a designation typically reserved for issues that are not considered direct, actionable flaws in their product.

1Password's position, articulated by CISO Jacob DePriest, is that clickjacking is a "long-standing web attack technique" and that a "comprehensive technical fix from browser extensions alone is not possible due to the underlying issue being in how browsers render webpages". This argument places the ultimate responsibility on the browser vendors to secure the DOM. However, this stance is undermined by the fact that numerous competitors
did implement effective mitigations. While not addressing the root cause in the browser, these patches clearly demonstrate that the risk can be managed at the extension level. In a concession that implicitly acknowledges the risk, 1Password announced it would extend its existing "ask before filling" confirmation prompt for payment cards to other data types, giving users more granular control.
LastPass adopted a similar "informative" classification. The company stated that it had already implemented "certain clickjacking safeguards," such as pop-up notifications for credit cards and personal details. However, their fix was only partial; the vulnerability remained unpatched for the most critical data types: login credentials, passkeys, and TOTP codes. This response is particularly concerning when viewed through a historical lens. LastPass has a documented history of dealing with clickjacking and autofill-related vulnerabilities, with significant flaws reported and patched in both 2015 and 2019. This recurring pattern suggests that the secure implementation of autofill has been a persistent architectural challenge for the company. Their decision not to issue a comprehensive patch for this latest iteration marks a significant departure from their past actions and raises serious questions about their current security posture.

The divergent responses from these vendors are not merely a matter of different patch timelines; they represent a fundamental schism in security philosophy. On one side are the vendors who practice a "defense-in-depth" approach, taking responsibility for protecting their users from threats in the operational environment, even if the root cause lies in a lower layer of the tech stack. On the other side are vendors who adhere to a stricter, more narrowly defined boundary of responsibility, effectively telling their users that they are on their own when it comes to threats originating from the browser or the websites they visit. For customers paying for a security service, this distinction is critical. It determines whether they are purchasing a product that will do everything in its power to protect them or one that will only protect them from a narrowly defined set of flaws within its own code.

Comprehensive Mitigation and Defense-in-Depth Strategies

Given the severity of the DOM-based clickjacking vulnerability and the inconsistent patching status across the market, users cannot rely solely on vendors for protection. A proactive, multi-layered defense strategy is essential to mitigate the risk of data exfiltration. The following guidance provides actionable steps for immediate triage, advanced hardening, and long-term strategic security improvements for both individuals and organizations.

4.1 Immediate Mitigation for All End-Users

These steps are the most critical and should be implemented immediately by anyone using a password manager browser extension, particularly those from vendors that have not yet issued a complete patch.

Disable Automatic Autofill: This is the single most effective defense against this specific attack vector and is the primary recommendation from the researcher who discovered the flaw. The entire exploit chain relies on tricking the password manager's autofill feature into activating without clear, unambiguous user intent. By disabling this feature, the user removes the mechanism that the attacker seeks to hijack. Instead of the password manager proactively offering to fill credentials via an inline prompt, the user must take a more deliberate action, such as clicking the extension icon or using a keyboard shortcut, which is not susceptible to this form of clickjacking. Users should consult their password manager's settings, typically found under an "Autofill" or "Settings" menu, to disable any options related to "automatic filling," "inline autofill," or "show autofill suggestions on form fields".
Configure "On Click" Site Access (Chromium Browsers): For users of Google Chrome, Microsoft Edge, Brave, and other Chromium-based browsers, there is an additional, powerful mitigation available at the browser level. By changing the extension's site access permissions, users can prevent it from running automatically on every webpage they visit. The recommended setting is "On click". To configure this, the user typically right-clicks the password manager's icon in the browser toolbar, navigates to "Manage extension," and under "Site access," selects the "On click" option. This configuration ensures that the extension remains dormant until the user explicitly clicks its toolbar icon to activate it for the current site. This action provides a clear, user-driven signal of intent and prevents a random click on the page content from being able to trigger the vulnerable autofill functionality.
Maintain Software Updates: While some vendors have been slow to respond, many have issued patches. The only way to receive these critical security fixes is to ensure that both the web browser and the password manager extension are configured to update automatically. Users should periodically check their browser's extension management page to confirm they are running the latest available version of their password manager.

4.2 Advanced Configuration and Hardening Practices

For users who desire a more robust security posture or who cannot completely disable autofill for workflow reasons, the following advanced techniques can significantly reduce the attack surface.

The Copy-and-Paste Dilemma: While disabling autofill and resorting to manually copying and pasting credentials from the password manager's vault or desktop app is a valid way to bypass this specific vulnerability, it is not a panacea. This method introduces its own set of risks. If the user's system is compromised with clipboard-scraping malware or a keylogger, credentials copied to the clipboard can be stolen. Therefore, while it is a defense against clickjacking, it may expose users to other threats.
Alternative Autofill Methods: A safer middle ground exists between fully automatic inline autofill and manual copy-pasting. Most password managers offer alternative ways to trigger autofill that require more explicit user intent and are not vulnerable to this clickjacking technique. These include using a dedicated keyboard shortcut (e.g., Ctrl+Shift+L), right-clicking on a form field and selecting the autofill option from the context menu, or opening the extension's pop-up from the toolbar and clicking the "Autofill" button. These methods are more secure because the user's interaction is with the browser's chrome or a trusted context menu, not with a potentially compromised element within the webpage's DOM.
Refine URI Match Detection: As discussed previously, the risk of this attack is greatly amplified by the default "Base Domain" URI matching setting. Users should audit the settings for their most sensitive accounts (e.g., banking, email) and change the URI matching to a stricter setting like "Host" or "Exact". For example, instead of allowing credentials for
example.com to be filled on any subdomain, setting the match detection to "Host" for the URI https://login.example.com will ensure the password manager only offers to fill them on that specific hostname, directly mitigating the subdomain attack vector.
Keep the Vault Locked: The DOM-based clickjacking exploit can only succeed if the password manager's vault is unlocked. By configuring a short auto-lock timeout (e.g., 5-15 minutes of inactivity or on browser close), users can significantly reduce the window of opportunity during which an attack can be executed.

4.3 Strategic Guidance for Organizations and IT Administrators

The threat posed by this vulnerability extends beyond individual users to the enterprise. Organizations that rely on password managers as part of their identity and access management strategy must take proactive steps to protect corporate assets.

Policy and Training: IT security departments should immediately update their acceptable use and security policies to mandate the mitigation steps outlined above, particularly the disabling of automatic autofill and the configuration of "On click" site access where applicable. This should be enforced through configuration management tools if possible. Furthermore, user awareness training is crucial. Employees should be educated about the nature of this threat, with examples of how benign-looking pop-ups and CAPTCHAs can be weaponized. This fosters a healthy skepticism and encourages users to report suspicious UI behavior, even on seemingly trusted websites.
The Critical Importance of Separating TOTP Generation: This vulnerability starkly illustrates a critical weakness in the security model of many modern password managers: the consolidation of multiple authentication factors into a single vault. Two-factor authentication (2FA) is based on the principle of requiring two different kinds of factors—typically something you know (a password) and something you have (a physical token or authenticator app). When a password manager stores and autofills both the password and the TOTP code, it collapses these two distinct factors into a single point of failure, protected only by the master password.

The DOM-based clickjacking attack exploits this consolidation perfectly. By tricking the user into a single click, the attacker can exfiltrate both the password and the current TOTP code simultaneously. In this scenario, the "second factor" provides no additional security whatsoever; the authentication method is degraded from true two-factor to merely two-step. Therefore, a foundational defense-in-depth strategy for organizations is to mandate the separation of these factors. TOTP generation should be handled by a separate, dedicated application on a different device (e.g., a smartphone authenticator app) or, ideally, by a phishing-resistant hardware security key (e.g., a YubiKey utilizing FIDO2/WebAuthn protocols). This ensures that even if website credentials are stolen from the password manager, the attacker still lacks the second factor required to compromise the account.

Conclusion: The Autofill Dilemma and the Future of Browser Extension Security

The discovery of DOM-based extension clickjacking is more than just another vulnerability disclosure; it is a seminal event that exposes deep-seated tensions in modern web security. It serves as a powerful case study on the perpetual conflict between user convenience and robust security, and it acts as a harbinger for a new class of attacks that target the increasingly complex and often insecure interface between browser extensions and the web at large.

5.1 The Enduring Tension Between Security and Usability

At its core, this vulnerability is a direct consequence of the "autofill dilemma." The automatic filling of credentials is one of the primary value propositions of a password manager. It provides immense convenience and, under normal circumstances, can even enhance security by ensuring users can easily use strong, unique passwords for every site and by helping to thwart some phishing attacks (as the manager won't autofill on a mismatched domain). However, the implementation of this convenience feature—injecting interactive UI into an untrusted environment—is what creates the very attack surface that this vulnerability exploits.

The divergent vendor responses highlight this tension. The most straightforward technical solution to comprehensively prevent this attack is to implement a confirmation dialog that prompts the user for explicit approval before any data is autofilled. Yet, vendors are historically reluctant to implement such measures because they introduce "friction" into the user experience, degrading the seamless convenience that is a key selling point. The decision by 1Password to add optional confirmation prompts in the wake of this disclosure is a direct market reaction to this dilemma. It represents an acknowledgment that in the face of a credible threat, users must be given the choice to prioritize security over seamlessness. This incident forces a necessary re-evaluation of where the default balance should lie, suggesting that for high-stakes operations like releasing credentials, a small amount of user-affirming friction may be a necessary price for security.

5.2 Broader Implications for the Browser Extension Ecosystem

Perhaps the most critical takeaway from this research is that its implications extend far beyond password managers. The researcher, Marek Tóth, explicitly warns that the DOM-manipulation technique is general in nature and could almost certainly be applied to other categories of browser extensions that inject UI elements into web pages. This vulnerability should therefore be seen not as an isolated flaw, but as a proof-of-concept for a new class of attacks targeting the insecure boundary between privileged browser extensions and the untrusted DOM of web content.

The fundamental architectural pattern—a trusted extension with elevated permissions adding its own interactive elements to a webpage—is common across a vast ecosystem of tools. Consider a cryptocurrency wallet extension that injects a "Confirm Transaction" or "Sign Message" button into the UI of a decentralized finance (DeFi) application. An attacker could employ the exact same DOM-manipulation and overlay techniques to render that critical button invisible and place it over a benign decoy, such as a "Play Video" or "View NFT" button. A single, deceived click from the user could result in them unknowingly signing a malicious transaction and draining their wallet of all its assets. The same logic applies to note-taking extensions, ad-blocker configuration menus, and any other tool that presents a clickable interface within the context of a webpage.

Ultimately, the true significance of the DOM-based extension clickjacking discovery is not just that it found a flaw in password managers, but that it has illuminated a systemic weakness in the prevailing browser extension security model. It serves as a stark warning to the entire extension development community that injecting trusted UI into untrusted environments is an inherently risky practice. The industry must now grapple with this new threat paradigm, which will likely necessitate architectural changes, the adoption of more robust sandboxing, and a fundamental rethinking of how extensions can safely interact with the web pages they are meant to enhance. We are likely to see variants of this attack deployed against a much wider range of targets in the near future, and the lessons from this incident must be learned and applied broadly to avert the next wave of extension-based exploits.