At DEF CON 2025, security researchers disclosed a clickjacking vulnerability affecting the browser extensions of 1Password, Bitwarden, and LastPass. The attack allows malicious websites to steal autofilled credentials by overlaying invisible elements on password fields.
Here's what happened, why browser extensions are inherently vulnerable to this attack class, and why we chose a completely different architecture for The Password App.
The clickjacking attack explained
Clickjacking works by placing an invisible iframe or element over a legitimate page. When you think you're clicking a "Submit" button, you're actually clicking a hidden element that performs a different action.
For password managers, the attack flow looks like this:
- You visit a malicious website that mimics a legitimate login page
- Your password manager's browser extension autofills your credentials
- An invisible iframe overlays the password field
- When you click "Login," the hidden iframe captures your autofilled credentials
- Your password is sent to the attacker's server
The user sees nothing wrong. The page looks normal. The password manager worked as expected. But the credentials are now in the attacker's hands.
Why browser extensions are vulnerable
Browser extensions operate in a hostile environment by design. They must:
- Trust the page DOM: Extensions interact with webpage elements they don't control
- Autofill into foreign contexts: Credentials are injected into third-party content
- Run in the browser's sandbox: Limited ability to verify page authenticity
- React to user actions: Must respond when users interact with password fields
This creates an inherent tension. The extension must be helpful (autofill passwords) while operating in an environment controlled by potentially malicious actors (the webpage).
The technical problem
Password manager extensions typically:
- Detect login forms by examining DOM elements
- Match the current URL against saved credentials
- Inject the password into the detected field
- Trust that the field is what it appears to be
Step 4 is where clickjacking attacks succeed. The extension fills the "real" password field, but that field is actually visible through an invisible iframe that captures the input.
Even sophisticated extensions with phishing detection can be fooled because:
- The URL is legitimate (the attack works on real sites with injected malicious ads)
- The DOM appears correct (until you account for invisible overlays)
- User behavior is normal (clicking buttons they can see)
The 1Password, Bitwarden, LastPass disclosure
The DEF CON research demonstrated attacks against all three major password manager extensions:
| Extension | Vulnerable | Attack vector |
|---|---|---|
| 1Password | Yes | Invisible iframe overlay |
| Bitwarden | Yes | CSS opacity manipulation |
| LastPass | Yes | Z-index layering attack |
At the time of this writing, none of the affected vendors have issued public statements about remediation timelines.
Why we chose desktop-only
When we built The Password App, we made a deliberate architectural decision: no browser extensions. Here's why:
1. Controlled environment
A desktop application runs in an environment we control. We're not fighting against malicious webpage code because we're not executing in the webpage context.
Browser extension: [Your Code] → [Webpage DOM] → [Unknown scripts]
Desktop app: [Your Code] → [Our UI] → [Isolated browser instance]
2. No autofill, no autofill attacks
The Password App doesn't autofill passwords into webpages. Instead, our AI agent navigates to sites and fills credentials through a controlled browser instance that we manage.
The key difference:
- Extension approach: Inject credentials into untrusted page context
- Our approach: Control the entire browser session in isolation
3. Visual confirmation
Because password changes happen in a visible browser window, you can see exactly what's happening. There's no invisible iframe attack possible when you're watching the AI navigate to the password change form.
How clickjacking fails against our architecture
Let's walk through why a clickjacking attack can't steal credentials from The Password App:
Step 1: Attacker sets up malicious overlay
The attacker creates a page with hidden elements designed to capture password input.
Step 2: User initiates password change
You select an account in The Password App and click "Change Password."
Step 3: Isolated browser opens
Our AI agent opens a fresh browser instance with no extensions. It navigates directly to the account settings URL—not a malicious page.
Step 4: Credentials never touch the webpage
The AI identifies the password field and calls our secure credential injection function. The password travels through a separate channel, never entering the DOM in a way that JavaScript can intercept.
Step 5: Even if compromised...
Even if a malicious script somehow ran in our controlled browser, it couldn't exfiltrate the password because:
- Domain locking prevents navigation to attacker URLs
- The AI never has the password value in its context
- Network requests are restricted to the target domain
Multiple defensive layers mean no single failure compromises credentials.
The broader problem with browser-based security
This isn't just about clickjacking. Browser extensions face a constant stream of attack vectors:
| Attack type | Description | Extension vulnerable? | Desktop app vulnerable? |
|---|---|---|---|
| Clickjacking | Invisible overlays steal input | Yes | No |
| DOM manipulation | Malicious scripts modify forms | Yes | No (isolated browser) |
| Extension compromise | Malicious update pushed to extension | Yes | No (local only) |
| Cross-site scripting | Attacker injects scripts into trusted sites | Yes | No (domain locked) |
| Man-in-the-browser | Malware modifies browser behavior | Yes | Partially (isolated process) |
The fundamental issue is that browser extensions must coexist with arbitrary webpage code. Every new web API, every browser update, every clever attacker creates new potential vulnerabilities.
What this means for users
If you use a password manager with a browser extension, you should:
- Keep extensions updated - Vendors will likely patch this vulnerability
- Be cautious on unfamiliar sites - Don't autofill on sites you don't fully trust
- Consider the attack surface - Browser extensions add risk, even from trusted vendors
- Use 2FA everywhere - A stolen password with 2FA is less damaging
If you're evaluating password security tools, ask:
- Does this tool inject credentials into webpage contexts?
- What happens if a malicious script runs alongside the extension?
- How does the tool verify page authenticity before autofilling?
Our security architecture
The Password App takes a different approach entirely:
Zero-knowledge: Passwords never leave your Mac. They exist in memory only during the change process.
Credential isolation: The AI agent never sees actual password values. It calls functions like enter_password() that retrieve and inject credentials through a separate secure channel.
Domain locking: During password changes, the browser can only navigate to the target domain. Attempts to redirect elsewhere are blocked at the browser level.
No browser extension: We eliminated the attack surface entirely by not putting code into the browser context.
The bottom line
Clickjacking against password manager extensions isn't a theoretical risk—it's a demonstrated attack that works against the most popular tools. The affected vendors will likely patch this specific vulnerability, but the underlying problem remains: browser extensions operate in a hostile environment.
When we designed The Password App, we asked: "How do we handle credentials securely in a world where we can't trust the browser?" The answer wasn't to build a better browser extension. It was to avoid the browser extension model entirely.
Desktop-only. Local-only. Zero-knowledge. No extension attack surface.
Originally published at thepassword.app/blog
Top comments (0)