Yes, someone can hack your email without knowing your password. Your password is one lock on the account, and attackers have four ways past it. I run AliasFleet, an email-alias service. The inbox is the account I take most seriously: every other account sends its password resets there. Inside your inbox, an attacker needs none of your other passwords. They reset them.
Four attacks. One stop for each. No public number shows how often each hits an ordinary inbox, so nothing here is ranked by scare value.
The fake sign-in page still works
Phishing is the oldest of the four. Still the usual way in. The fake sign-in page never guesses your password, it asks for it, then for the code, and the newer version is worse. In an adversary-in-the-middle attack, the fake page passes everything to the real site, live, as you type it, and the attacker keeps the session that results.
Phishing turned up in over half of Cisco Talos's incident-response engagements in Q2 2026, per SecurityLedger's report on the Talos findings, with authentication abuse at 65 percent, up from 35 percent the quarter before, per Menlo Security's summary of the Talos report. Talos's caseload, not your inbox.
The live relay is real. In October 2026, Cisco Talos documented a phishing kit that lured victims with fake event invitations to a fake Google sign-in page, mirrored Google's real authentication screens, and took the session token once the victim finished the checks (GBHackers). Identical to Google's sign-in, and still a relay.
A code is only information. A fake page that gets your password can get the code too, and pass both on before the code expires. So texted and app-generated codes are not phishing-resistant. CISA's phishing-resistant MFA guidance is blunt: only FIDO/WebAuthn, passkeys and security keys, plus PKI-based methods, count.
A relay with nothing to break
The relay works because nobody breaks the cryptography. They stand between you and the real site, passing everything along. You complete the real login; they keep the session. The fix has to be a login method with nothing to relay, and a passkey or security key checks the domain itself, cryptographically, and stays silent for a lookalike. Turn passkeys on for the inbox first, and never read a verification code to anyone or approve a sign-in prompt you did not start.
A stolen cookie skips the login entirely
Session theft is the one people struggle to believe. Once you sign in, your browser holds a session cookie: proof you already proved who you are. A stolen cookie lets an attacker present that proof as their own, with no password and no second-factor check, because the theft happens after sign-in. Notebookcheck's explainer puts it this way: the attacker needs neither your password nor your second factor, just the small file your browser stores after you sign in.
Infostealer malware is the usual delivery: it reads the browser's stored cookies, saved logins and payment details, then sends them to the attacker. One recent stealer campaign hit 17 Chromium-based browsers plus Firefox, copying cookie and login databases (GBHackers). JSCeal, another, was built to rebuild a browser session from stolen cookies and replay it past Google authentication, per Check Point research via The Hacker News.
A stolen cookie keeps working even after the malware is gone, so clearing the infection leaves the session untouched. After any scare, end every session, because the password alone is not enough.
That copied cookie gets in with neither password nor code prompt, and changing your password does not finish the job here either. Google says a password change does not immediately invalidate stolen tokens, by design, so ending it takes signing out the session, per TechTarget's reporting on Google's position. After any scare, open Google's device list, check every session, sign out anything you do not recognise.
What aliases can and cannot do
Aliases do not stop any of the four attacks against the inbox itself. Fake page, stolen cookie, hijacked recovery, replayed password: all four hit the inbox account, and an alias does nothing about that. I am not going to pretend otherwise. Aliases change everything around the inbox.
Start with the leak itself: give every site its own forwarding address, and a breach names its source, since mail on the address you gave one shop could only have escaped from that shop. Then the kill switch: switch off a leaked address and the whole channel dies while your real inbox stays clean, and your real address stays out of databases, signups and breach files, leaving less raw material for phishing and stuffing. The AliasFleet set-up guide takes about two minutes; the explainer on what an email alias is covers the mechanism.
Keep the inbox sign-in address apart from the addresses you hand out, because if you put your sign-in address on every signup form, every breach file holds your login username. A distinct sign-in address, never published anywhere, plus per-site aliases for everything else, and a leak never hands an attacker your username.
The back door you set up yourself
The third way in is the recovery flow. Most people never think to check it. Every account has a "forgot password" path, only as strong as its weakest link: recovery email, recovery phone, backup codes, security questions. Control any one of those, and the attacker can reset the password and lock you out. No current password needed. Just the recovery channel.
Attackers go for that channel first once they are in. Post-compromise analyses of phished Google Workspace accounts show attackers changing the recovery email and disabling two-factor authentication within hours, then adding forwarding rules to keep receiving mail. The DEV.to analysis sets out that sequence. A rule forwarding mail matching "password" or "reset" to an outside address, then deleting the original, keeps the attacker reading your resets after a password change. Once inside, attackers switch on auto-forwarding to keep receiving mail unnoticed, as the SecureMyEmail guide explains.
Five checks, in this order
Google's own guide to securing a hacked account covers the same ground. My version, in order:
- Recovery email and phone: still yours, and delete anything you did not add.
- Two-factor settings: still on and still your own methods, so re-add anything that looks off.
- Gmail forwarding and filters: in Settings, check Forwarding and POP/IMAP, then Filters and Blocked Addresses, deleting any rule you did not create.
- Third-party access: cut any app or connection you do not recognise.
- Then change the password and sign out every session, following the Gmail sign-out help.
Do them in the same sitting as the password change, because a surviving forwarding rule undoes it on its own.
An old password from another site still opens your inbox
The fourth way is the simplest. Credential stuffing takes email and password pairs leaked in one breach and tries them automatically against other sites. It works when you reuse a password. The attacker needs no current inbox password. They need your 2019 forum password, if it still matches the one on your inbox today. If it matches, they are in.
Enzoic's explainer sets out the mechanism: stuffing replays real leaked pairs, and it works because people reuse passwords. Microsoft was already reporting this in 2016: attackers testing an average of 12 million leaked credential pairs a day against its accounts. Old, not a current rate, but it shows how long this has run at industrial scale. The AliasFleet guide to how credential stuffing works covers the same ground for the inbox.
Stuffing hits email harder than most accounts, because your email address is your username almost everywhere, so the attacker already holds half the pair. Everything else resets through your inbox, so one stuffed login cascades to every account tied to it. The fix is dull and total: a unique inbox password, in a password manager, never reused anywhere. Then check the address at Have I Been Pwned, which names the breach, its date, and the data types exposed, and the AliasFleet guide to checking if your email was leaked walks you through it.
Stuffing never beats a strong password, it beats a reused one. The attacker is not guessing, they are replaying.
Four attacks, four separate fixes
Each attack has its own fix, and the fixes barely overlap. That is the point. Against stuffing, a strong password only counts when it is unique. Two-factor codes stop guessing, not relays or stolen sessions. A password change evicts a password thief. It does nothing to a live session or a forwarding rule.
| Attack | What it bypasses | What stops it |
|---|---|---|
| Phishing, including live relays | Password and codes, by getting you to hand both over | Passkeys or security keys; typing addresses yourself; never approving prompts you did not start |
| Session theft | Password and 2FA, by stealing the post-login cookie | Sign out every session; remove the malware; check devices |
| Recovery-flow abuse | Password, by resetting it through a weaker channel | Recovery email and phone kept current and yours; no spare recovery paths left open |
| Credential stuffing | Password strength, by replaying a leaked pair | Unique inbox password; password manager; breach checks |
Three moves cover all four. Do them in one sitting. Turn on app-based two-factor authentication on the inbox, or better, a passkey. Hand the inbox a password used nowhere else. And go through the settings a password change leaves untouched: sessions, recovery options, forwarding rules, filters. Codes arriving by email? Read the AliasFleet piece on whether email is safe for two-factor codes next. One lock down, three doors to go.
