Marek Tóth

Přes 16 000 placených videí zdarma ke stažení - více než 50 TB dat 🔥 Chyby se týkaly tvůrců jako: DVTV, Oktagon, Čestmír Strakatý, Vojta Žižka, Ondřej Koběrský, U Kulatého stolu a mnoho dalších 💡Šlo získat: zveřejněná videa, videa připravená k vydání, filmy, placené dokumenty a články, mp3 rozhovory, materiály ke kurzům... Nalezené chyby byly u společnosti Tivio Studio, která spravovala pro ně obsah. Více informací na: marektoth.cz/blog/tivio-stu…

@CyberMedicsOrg If there have been any fixes from password manager vendors since publication, this is noted at the beginning of the research and the "Password Managers: Vulnerable & Fixed Versions" section is also updated, specifically "Fix Status (Updated: 11.9.2025)". Everything in these updated sections reflects the current situation as of today. I will not correct any tables or conclusions from the original research. At most, only the above-mentioned sections will be updated.

@KeePassXC @marektoth @NordPass @ProtonPass @roboform @dashlane @Keeper @Bitwarden @LastPass @1Password @EnpassApp @LogmeOnce Blog summary should be updated From Blog Fixed: NordPass, ProtonPass, RoboForm, Dashlane, Keeper Still vulnerable: Bitwarden, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce

We loved your article on Password Manager extension clickjacking attacks. We would love it if you evaluated KeePassXC as well and included it as an addendum to your blog. @marektoth marektoth.com/blog/dom-based…

Proud to have a friend like @marektoth — DEF CON 33 speaker whose talk on Password Stealing through Browser Extension Clickjacking resonated worldwide 🌍 Great to catch up at Cyb3r Days Prague!

@conradchircop @1Password Yes, that's problem. In default configuration is 1Password still vulnerable. How many users will actually enable this? 1%? And for the rest, their data will be at risk.

@marektoth @1Password have updated most of their browser extensions (Firefox is pending) however the end user must manually enable explicit user confirmation before any autofill process on each browser extension. It's not something you can enforce through a Group Policy on staff for example

I disagree with these statements: ❌ "If a website has an XSS vulnerability, then clickjacking is redundant." ❌ "If a website has an XSS vulnerability, then any data leakage is the webadmin's fault." ❌ "If you only visit trusted websites, then your data in a 'vulnerable' password manager is safe." My full opinion is below ⬇️: TL;DR: • If XSS exists and I click just once, nothing happens. But if I use a vulnerable password manager and click, my credentials will be stolen. ⚠️ → My data is at greater risk if I use a vulnerable password manager than if I don't use one at all. The webadmin is not responsible for my choice to use a vulnerable password manager. • A user cannot (easily) detect Stored XSS or other vulnerabilities on a trusted website → No, this is not possible during normal use. You would have to manually analyze every script on every page. • It is not safe to visit domains/subdomains where you have saved credentials if you are using a vulnerable password manager → At the moment, on any site where you have stored credentials, you should avoid clicking anywhere at all • Can an attacker steal a user's login credentials via XSS with just one click from the victim? NO ⚠️ → They might attempt a social engineering attack (the user would have to manually enter their credentials), but the success rate of such an approach is much lower compared to exploiting a vulnerable password manager. 1️⃣ NEW LOGIN FORM Yes, an attacker could create a new login form, but that is a COMPLETELY DIFFERENT ATTACK VECTOR. This is a very common mistake and it's necessary to separate the method by which an attacker gets data and what the success rate of such an attack is. Comparison of number of interactions: - number of interactions by the victim on the vulnerable website DOM-based extension clickjacking: 1 click (anywhere) - attacker has your login credentials (9 password managers) 1 click (anywhere) - login credentials + TOTP (5 password managers) 2. clicks (anywhere) - login credentials + TOTP (8 password managers) ... 3 clicks - login credentials + TOTP + credit card 4 clicks - login credentials + TOTP + credit card + personal data Copy/paste credentials and TOTP from password manager (e.g. KeePass): 1. Right mouse click (CTRL) 2. Select "Copy username" (B) 3. Right mouse click (CTRL) 4. Select "Paste" Username (V) 5. Right mouse click (CTRL) 6. Select "Copy password" (C) 7. Right mouse click (CTRL) 8. Select "Paste" Password (V) # 8 interactions vs 1 click 9. Right mouse click (CTRL) 10. Select "Copy TOTP" (T) 11. Right mouse click (CTRL) 12. Select Paste TOTP (V) # 12 interactions vs 1-2 clicks - and I'm not counting switching between windows What if the victim changes their mind during the process? Then the attacker will not get access to the victim account. The user decides what to enter and the form is fully visible. It depends ONLY on the user = it's a social engineering attack One click anywhere on the page and the user's credentials are stolen (the user doesn't see the form or the UI) = not user mistake, it's exploiting a vulnerability in the password manager ("social engineering" is minimal - only a single click) Result: 🔹 When exploiting clickjacking vulnerability, the attacker needs significantly fewer interactions from the victim 2️⃣ ATTACK SUCCESS RATE When will the attacker have greater attack success rate? When the user only has to click once anywhere on the page? Or when the user has to enter all their credentials into a new form? Definitely, just one click will have greater success rate. If you see a login form anywhere on a page, do you ALWAYS enter your credentials into it? What if you're already logged in, would you still enter your credentials again? What about clicking on an annoying cookie banner or login dialog, which prevents you from seeing any content on the page? Won't this happen more often? If you want to see the content, you have no choice but to click. How many times have you logged into X today? And how many times have you clicked on comments/posts/like on X? (...is X always secure? – more in part 3. An attacker can use an exploit containing all vulnerable password managers and browsers - this also significantly increases the chance of success. If I hadn't reported the vulnerabilities, we would now be talking about 12 password managers and 6 browsers (marektoth.com/blog/password-…). Yes, I'm also counting automatic autofill (0-click autofill). An attacker could have a script containing exploits for 18 password managers and steal stored credentials with 0-1 mouse click from the victim (2 clicks only for LastPass). For browsers, the limitation is only to the same domain and cannot be applied to subdomains like in password managers. 1Password, Bitwarden, Dashlane, iCloud Passwords, Enpass, Keeper, LastPass, LogMeOnce, NordPass, ProtonPass, RoboForm, Google Chrome, Mozilla Firefox, Microsoft Edge, Opera, Internet Explorer, Vivaldi I believe an attacker would have a very high success rate with stealing credentials if they found XSS on a page, don't you think? Result: 🔹 Just one click on a cookies banner will have significantly greater attack success rate than displaying a new form. With the new form the user is not forced to fill in the credentials (or is forced to, but doesn't have to do it) - An attacker can first use a clickjacking exploit and if they don't steal anything from the click, THEN they can start their social engineering attack 3️⃣ VISIT ONLY TRUSTED SITE Password manager vendors recommend "only visit trusted sites." But what does "trusted site" actually mean? Can I visit any of these sites? https://paypal[.]com/signin https://gitlab[.]com/Nyangawa/test/merge_requests/1 https://amazon[.]com/clouddrive/share/P9RHny1WRdZtZHKVnqzyXclDf6U7d2Ma9qy5Z5Y40 If you accepted cookies there, congratulations - your credentials was stolen. All of these sites have had vulnerabilities in the past: hackerone.com/reports/488147, hackerone.com/reports/508184, miro.medium.com/max/1312/0*MB0… But if you weren't using a vulnerable password manager, a single click wouldn't have resulted in data theft. Vulnerabilities have existed, exist, and will continue to exist. Users have the choice to decide whether to use a vulnerable password manager or not. And what about here on X? Is there really no risk for you here? I don't know the current situation, but according to the post, there was probably a web cache poisoning vulnerability on X (impact the same as stored XSS): x.com/WatcherGuru/st…, x.com/WatcherGuru/st… Just one click here on X and an attacker had your account login credentials. So what does "only visit trusted sites" actually mean? Can someone from the password manager vendors teach me how to detect such a site? Result: 🔹 It is not easy to detect whether a trusted website has an exploitable vulnerability - No, it is not possible during normal use. You would have to analyze every script on every page. 🔹 You cannot safely visit domains/subdomains where you have stored data if you are using a vulnerable password manager. - Currently, on all sites where you have stored data, you shouldn’t click anywhere at all. 🔹 If you are not using a vulnerable password manager, a single click will not allow an attacker to obtain your data. 4️⃣ IMPACT WITH XSS I very often read that an attacker can do this and that with XSS. Ok, important question: Can an attacker steal a user's credentials in plaintext with a single click via XSS? NO An attacker could steal a session using XSS… Yes, maybe a few years ago. But today, it's not that simple - especially on widely used websites. Most modern frameworks automatically set the HttpOnly flag on session cookies, which means sessions cannot be stolen via javascript (=XSS). Even if it were possible, a session is not the same as credentials. With credentials, an attacker can create a completely new session, which won't be invalidated when the user logs out. Autofill on subdomains: All password managers that I tested in research fill credentials not only on the "main" domain but also across all subdomains. For example, if credentials are saved for x.com, they may also autofill on test.x.com, dev1.subdomain.x.com etc. Now, let's say there's an XSS vulnerability on dev1.subdomain.x.com. What's the actual impact? Almost none! The main domain and its core functionality are on x.com. Any attempt to make a request from dev1.subdomain.x.com to x.com will be blocked by the Same Origin Policy (en.wikipedia.org/wiki/Same-orig…). So, the session cannot be stolen, no request is sent, and no data is obtained. However, if you use a password manager that is vulnerable to clickjacking, a single click is enough for an attacker to get your credentials. This is precisely the major problem when credentials are autofilled across all subdomains. Example with 1Password: On the bug bounty platform HackerOne, they have the domain support.1password.com listed as "Out of Scope" (hackerone.com/1password/poli…). No ethical hacker will look for bugs there, so there could be many vulnerabilities with no one motivated to find them. And what about a "non-ethical" hacker? If they find an XSS vulnerability there and send you an email with a link to support.1password.com, what happens if you click it once? The attacker could steal your credentials stored for my.1password.com - your email and password for your vault (but not your secret key). Result: 🔹 Autofilling credentials across all subdomains significantly increases the risk of abuse. The attacker has a large scope for finding vulnerabilities. 5️⃣ BLIND XSS AND CLICKJACKING Blind XSS is a type of XSS where the script executes on a completely different page that is hidden from the attacker. For example, an attacker injects XSS into a review on an e-commerce site (e.g., amazon.com). The script does not execute on the public-facing site, but it executes later in the administration when an employee accesses it (e.g., admin.employee.amazon.com). Did the employee visit a malicious site? NO They were simply using their administration panel as usual. One click, and the attacker could steal their credentials. And these credentials don't have to be limited to administration panel. They could also be used, for example, for the employee's email. Why can't the attacker just export more data immediately? They can't, because they don't know the structure of the web application. Which requests should they send? Yes, they can immediately get the content of the current page - but that might be limited to, for example, a list of reviews, and not sensitive information. Theoretically, their script would have to collect all URLs and send requests to them repeatedly, and so on. But we are still only talking about the impact of the XSS vulnerability. Can an attacker obtain stored credentials with just one click from the victim using only XSS? NO However, if the employee us using a vulnerable password manager, then YES. Result: 🔹 An attacker can exploit a vulnerability (blind XSS) along with clickjacking to obtain employee login credentials. - Without clickjacking, the attacker would not be able to easily obtain the credentials and would need to rely on a social engineering attack. -------- And this is what companies often label as an "acceptable risk". I looked around but couldn't find any similar explanation of security risks from companies that still have these vulnerabilities, leaving most users unaware. If you've read all the way to this point, I truly appreciate it 👍 If you agree, I would be grateful if you could share this to help it reach a wider audience. Thank you 🙌

@martyd420 Já taky děkuju :)

@marektoth Skvělé čtení, navíc sepsané i v češtině.. Díky :) Husté to je.. :D

New update to the "DOM-based Extension Clickjacking" research 🔐 Bitwarden: 2025.8.1 (in progress), <=2025.8.0 (vulnerable) ⚠️ Enpass: 6.11.6 (fixed) ✅ KeePassXC-Browser <=1.9.9.2 (latest) is vulnerable ⚠️ + New demo sites for: 1Password, Bitwarden, iCloud Passwords, KeePassXC-Browser, LastPass + New videos with all currently vulnerable password managers marektoth.com/blog/dom-based…

@degenetr0n @Bitwarden Bitwarden: latest version (2025.8.1) still vulnerable x.com/marektoth/stat…

@Bitwarden is this fixed? marektoth.com/blog/dom-based…

DOM-based Extension Clickjacking UPDATE (24.8.): FAQ: An attacker can create a new login form using XSS, so why would they use clickjacking❓ My answer: #issuecomment-3217885523" target="_blank" rel="nofollow noopener">github.com/keepassxreboot… Bitwarden: latest version (2025.8.1) still vulnerable ⚠️ Demo sites: websecurity.dev/password-manag… LogMeOnce: New release - I am waiting to be added to Chrome Web Store support.logmeonce.com/hc/en-us/artic…

@TheNewNatha @Bitwarden New demo sites for 2025.8.1 websecurity.dev/password-manag…

@TheNewNatha @Bitwarden 2025.8.1 is still vulnerable and I’m creating new demo sites

@JakubUrbanec Děkuju moc

@marektoth Excelent find! Impressive. Kudos a pěkný den.

@madonomori 「詳しい調査はこちら：」/ Full research here: marektoth.com/blog/dom-based…

ほとんどのパスワード管理アプリから機密情報を盗み出せる ～拡張機能を狙う攻撃手法が明らかに／未対策のパスワードマネージャーも多数 forest.watch.impress.co.jp/docs/news/2040…

@kriztalzmuse Four years ago, I reported a clickjacking vulnerability in KeePassXC-Browser (KeepassXC browser extension). I used a very complicated procedure back then, but it was already vulnerable at that time... So he was also vulnerable for at least 4 years. github.com/keepassxreboot…

@marektoth Very nice blog - amazing work showing all the demos! KeepassXC wasn't mentioned. iirc the default behavior is to prompt when accessing information / if a fido2 key is enabled you need to touch it to fill which renders the vulns less likely to succeed.

[CZ níže👇] Newly described clickjacking technique "DOM-based Extension Clickjacking". I tested it on 11 password managers and all of them were vulnerable. 💳 1 click and the attacker has your credit card details 🔥 Currently still vulnerable: Bitwarden, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce 👉 Full research: marektoth.com/blog/dom-based… ------ CZ: Nově popsaná clickjacking technika "DOM-based Extension Clickjacking" Testoval jsem ji na 11 správcích hesel a všichni byli zranitelní 💳 1 kliknutí a útočník zná údaje k vaší platební kartě 🔥 Stále jsou zranitelní: Bitwarden, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce 👉 Celý research (CZ): marektoth.cz/blog/dom-based…

@KamilZm CZ verze: marektoth.cz/blog/dom-based…

@KamilZm Děkuji. Před pár dny jsem přiletěl z Las Vegas z DEFCON konference, kde jsem vše prezentoval. Research bude do středy i v češtině. Momentálně ještě dopřidávám případy, které nebyly prezentovány, např. zneužití passkeys přihlašování.

Tohle je docela masakr - Clickjacking ve správcích hesel. Některé aplikace (resp. rozšíření) stále nejsou opraveny. marektoth.com/blog/dom-based…

@albinowax Thank you @albinowax, and thank you for sharing 🙌

This is some really nice research! It's definitely worth trying these techniques against cryptocurrency extensions! marektoth.com/blog/dom-based…