They didn’t guess the password. They didn’t break 2FA, bypass the firewall, or trigger a single alert. The activity log shows no failed attempts, no unusual login times, no new accounts created.
And yet, the attacker is inside your WordPress site, accessing your WordPress dashboard.
Session hijacking leaves no login trace, because the attacker never logged in. They took an authentication cookie and reused an existing session. To WordPress, every request looks legitimate; the real user’s credentials, their 2FA, their login restrictions, none of it applies. The session was already authenticated.
Most WordPress security advice is built around hardening and protecting, however, that leaves a critical blind spot: what happens after authentication succeeds?
In this talk, we’ll walk through how WordPress creates and validates authentication cookies and session tokens, explore the real-world scenarios where sessions get stolen, and map out what an attacker can do with a hijacked session before the damage becomes visible.
Then we’ll get practical. We will look into how session visibility, timeout policies, concurrent login controls, device recognition, and activity logging that captures post-login behaviour are the controls that catch what firewalls and 2FA miss.
Firewalls, 2FA, and passkeys are essential. This talk covers what comes after them.
