I was logged into a client's WordPress dashboard, editing a product page for their online store, when a second admin login notification hit my email. Same account. Different city. I hadn't logged out. I was still sitting right there, cursor blinking in the same edit window.
My first thought was that the client had logged in themselves and forgotten to tell me. Ten seconds of checking killed that theory — the login location was nowhere near either of us, and there was already a new draft post sitting in the queue with a spammy affiliate link buried in it.
Nobody had guessed the password. Nobody had reset anything. Whoever was in there was just... in there, riding along on the same logged-in session I already had open. That's when it clicked — this wasn't a password problem. It was a cookie problem.
Also Read: How Firewalls Protect Your Network From Cyber Threats
What a Session Cookie Actually Is, in Plain Terms
Every time you log into a website — Gmail, your bank, a WordPress dashboard, Netflix, whatever — the site doesn't ask you to type your password on every single click. Instead, after you log in once, it hands your browser a small piece of data called a session cookie. That cookie basically says, "This browser has already proven who it is, let it through."
Your browser sends that cookie back with every request you make on that site. The server checks it, sees it's valid, and treats you as logged in. No password re-check needed. That's why you can close a tab, open it again, and still be signed into your email — the cookie is doing the work quietly in the background.
Here's the part that matters for this whole topic: the cookie IS the login, as far as the server is concerned. It doesn't know or care who's holding it. If I steal your session cookie and paste it into my own browser, the site sees a valid session and lets me straight in — no username, no password, no 2FA prompt, nothing. I just become you, for as long as that cookie stays valid.
How Mine Actually Got Taken
I went back through everything after the fact, because I do freelance cybersecurity work and this was embarrassing enough that I needed to know exactly what happened. Turned out I'd installed a Chrome extension a few weeks earlier — a small "SEO helper" tool I grabbed to check meta tags faster while doing client site audits. It looked harmless. It had a few thousand installs and decent reviews.
What I didn't check closely enough was the permissions it asked for. It wanted "read and change all your data on all websites you visit." I clicked allow without really sitting with what that meant, because I was mid-task and just wanted the tool working.
That permission is basically a blank check. An extension with that access can read cookies straight out of your browser and quietly send them off to wherever it wants. Mine had been doing exactly that, apparently for a while, and the WordPress session was just the one that happened to get noticed because of the login alert email.
I'm not going to pretend this was some sophisticated nation-state attack. It was a sloppy extension install and me not reading a permissions prompt properly. That's genuinely how most of these happen.
The Other Common Ways It Happens (Not Just Extensions)
Extensions are one route, but they're far from the only one. A few others I've run into or seen while doing client work:
- Public Wi-Fi with no HTTPS enforcement — a session cookie sent over plain HTTP on an open coffee shop network can be grabbed by anyone else on that network with basic packet-sniffing tools.
- A malicious or compromised website running injected JavaScript that reaches into other tabs — this is what XSS attacks are built to do.
- Malware sitting on the actual device, reading browser storage directly. This doesn't even need you to visit anything shady that day; the malware could've landed weeks earlier.
- A man-in-the-middle setup on a rogue or shared hotspot, grabbing session tokens straight out of unencrypted requests.
None of these need your password. That's the uncomfortable bit. You can have a strong password, 2FA turned on, all the right habits — and still get walked around all of it because the attacker isn't logging in, they're just reusing a session that already logged in successfully as you.
What an Attacker Can Actually Do Once They Have It
This depends on the site, but in my case, with WordPress admin access, it was basically full control for as long as the session stayed valid — creating posts, changing settings, possibly installing a plugin if they'd had more time. On an email account, it could mean reading everything, sending from your address, or using "forgot password" resets on other sites since your inbox is usually the master key to everything else.
On something like a banking or shopping session, the window is usually shorter because those sites tend to expire sessions faster and re-verify sensitive actions, but even a short window is enough for a fraudulent transaction if they move fast.
The scary part isn't really what they do while they're in — it's that from the server's point of view, none of it looks suspicious. It's not a failed login attempt. It's not a password reset. It's just "the logged-in user did something," because technically, as far as the cookie's concerned, they are the logged-in user.
What I Actually Did Once I Realized What Was Happening
-
Killed the session immediately. Most platforms have a "log out of all devices" or "log out of all sessions" option buried in account or security settings. I used that on the WordPress site first, which invalidates every active cookie tied to the account, including the stolen one.
-
Changed the password anyway. Ending the session stops the current intruder, but a fresh password — plus regenerating any API keys if the site has them — closes the door properly, especially if the extension had grabbed other stored data too.
-
Removed the extension immediately, then went and checked every other browser profile on that machine. I had it installed on both my personal Chrome and my work profile, which meant two sets of sessions were potentially exposed, not one.
-
Cleared cookies for anything sensitive and logged back in fresh. This forces new session tokens to get issued, so even if the old cookie got cached somewhere, it's dead weight now.
-
Checked the activity log. WordPress, Gmail, most banking apps — they usually keep a login history with device and rough location. I went through it looking for anything else that looked off, not just the one alert that had tipped me off.
-
Told the client straight away, because it was their site and they had every right to know someone else had been sitting in their dashboard, even briefly.
Mistakes That Made This Worse Than It Needed to Be
I hadn't set session timeout limits on that WordPress install, so the login had been sitting active for way longer than it should have. Most sites let you configure how long a session stays valid before it forces a re-login — I'd never bothered touching that setting on client sites because it felt like a minor detail. It isn't. A shorter session window shrinks the whole attack opportunity down to almost nothing.
I also hadn't turned on login notifications for that account until after a previous unrelated scare, which is honestly the only reason I caught this one in time. Without that email alert, I'd have had no idea anything was wrong until the fake post either went live or got flagged by the client.
And obviously, the extension. I still use browser extensions, but now I actually read what permissions they're asking for, and I check the developer's history and reviews before installing anything that touches "all sites." If a tool that's supposed to check meta tags wants access to everything I do online, that's a mismatch worth questioning.
A Few Things That Genuinely Help Going Forward
Using separate browser profiles for sensitive work versus everyday browsing keeps the exposure contained — if one profile gets compromised, it doesn't automatically drag every account you own down with it.
Logging out of sites you're not actively using, rather than leaving fifteen tabs permanently signed in, shrinks the number of live sessions someone could grab in the first place.
On anything that supports it, turning on "sign out of inactive sessions after X minutes" is a small setting that does a lot of quiet work.
HTTPS matters here too, obviously, but most legitimate sites enforce it by default now, so the bigger real-world risk these days is less "unencrypted connection" and more "something already running on your device or in your browser that has access it shouldn't."
Where This Leaves Things
Session hijacking doesn't feel dramatic while it's happening. There's no scary popup, no ransom note, no obvious sign anything's wrong — just a quiet second login that looks, to the server, exactly like you. The only reason I caught mine was a login alert email I'd almost turned off months earlier because I found it annoying.
That's really the takeaway I keep coming back to. Passwords and 2FA protect the front door. A stolen session cookie walks in through a window you didn't know was open. Worth checking what's got access to your browser every now and then, even when nothing feels wrong.
comments