What 2FA and Passkeys Don’t Protect Against
“Turn on two-factor authentication” has become the standard answer to any question about hacked WordPress sites. It does close the most common cases, which are leaked passwords and password guessing, but three stories this year got past 2FA, two of them without touching the login form at all.
What 2FA covers
The authors of the WP 2FA plugin describe it as protection against leaked passwords, automated guessing and brute force. A passkey goes further and also covers phishing, because the login is bound to the domain and on a look-alike page the browser will not hand over credentials. The server keeps only a public key, so there is nothing to steal there. A one-time code from an app works differently, since it can be talked out of a user and entered on someone else’s page. Passkeys are included in the free version of WP 2FA, while several keys per user are only in the paid one.
Three stories that got past it
In the October stored-XSS campaign we wrote about, the script runs inside an administrator’s session that is already open. The password and the second factor have been entered by then, so there is nothing for the script to break.
The backdoor from the UpdraftCentral incident we covered earlier creates a user with the Editor role, grants it manage_options and install_plugins separately, and gets in by setting the cookie directly. The login form is not involved, so 2FA and brute-force protection never run, and a check of the administrator list misses this account too.
In June, code reached sites through the update channel of ShapedPlugin’s paid plugins and stole logins, session cookies, data from wp-config.php and the 2FA secrets of popular security plugins. BleepingComputer advises resetting passwords and regenerating 2FA secrets after something like this, and ShapedPlugin says the free versions from WordPress.org were not affected.
In the first two cases the login form was never part of the attack, and in the third 2FA itself was the target, since its secrets were taken.
What is left
Different measures cover these cases. Patches should be installed quickly, since in the October campaign the first attack came 12 days after the vulnerabilities were disclosed, when fixes were already out. Administrators should be checked against the database rather than the Users screen, and people who handle form submissions and orders don’t need to be administrators, because a stored XSS fires for whoever opens someone else’s data with broad rights.
If you roll out passkeys, Stack Harbor’s guide points out two details. The domain where the key is registered must match the one users visit, with www and the bare domain counting as different. And an editor who works on a Mac at home and a Windows PC at the office needs a key on each device and a backup way to log in, otherwise a browser or platform failure locks them out.
