Who still gets in after a password change

In the July 2026 attack on Hugging Face, most of it came down to a single key. A shared connector key had full administrator rights on every server cluster, and once the agents obtained it, most clusters became reachable within a single second. The rest of the chain is described in the Workshop.

On a small business website, its counterpart is the admin password that several people know: the owner, a colleague, the former agency that built the site, and a freelancer who once fixed a form. Each of them is a possible way in: if the password leaks from any of their computers or mailboxes, the website is open too.

Seven kinds of access that belong to a website

Taking stock starts with seeing that the admin password is only one of the ways in. The table lists what someone who knows each login can reach, and who usually has it.

The list is longer than expected because access is not created all at once. Each one came with a piece of work, and at the end of the work nobody took it back.

Email is the most important key

Of the seven, email matters most, because the passwords of the other accounts can be reset from it. Anyone who can read a mailbox that receives the password reset emails of the domain, the hosting or WordPress gets in everywhere without knowing any passwords. That is why the website's accounts are best registered to the business's own address: a colleague's or the developer's private address leaves with them.

When someone leaves

When a colleague leaves or an agency is replaced, changing the password is the first step, but on its own it is not enough. In WordPress's code, a password change invalidates that account's logins, yet three things remain after it.

Their own account. If the person had their own WordPress account, it has to be removed, with its content assigned to another account. Changing the shared password does not affect it.

Application passwords. Since WordPress 5.6, an application password can also be created for an account, which lets a program, such as a mobile app or a connector service, make changes in the user's name through the API. It cannot be used to log in to the admin area. In WordPress's code, setting a password does not touch these, so they stay valid after a password change and have to be revoked separately in the user's profile.

Other accounts' logins. If you do not know exactly who logged in with which account, changing the secret keys in wp-config.php logs everyone out. According to WordPress's sample file, all users then have to log in again, though this does not revoke application passwords either.

One person, one account, with the rights the job needs

If everyone gets their own account, with only the rights their job needs, a leaked password opens only one account, and that account can be closed on its own. Among the WordPress roles, an Editor can publish and edit any post and page, but cannot install plugins, add users or reach the settings. That is enough for a colleague who manages content; admin rights are for whoever maintains the site.

The Editor role has one risky right too. On a single WordPress site it can write unfiltered HTML into the content, which means it can also put a script on a page, so a hacked editor account can plant code that runs in visitors' browsers. In wp-config.php, the DISALLOW_UNFILTERED_HTML setting takes this right away from every user, admins included.

Two-step login

A second step next to the password, such as a six-digit code from a phone app, protects even when the password has leaked. WordPress does not include one by default; it can be added with a plugin. Most domain, hosting, email and Google accounts offer it built in, and that is where it is worth switching on first, because the other accounts can be reset from those.

What I do about it in my own work

On the sites I maintain, the daily check compares the list of admin accounts with the expected one, so every new admin account raises an alert, whether an attacker added it or a well-meaning colleague. What else this check looks at is listed on the maintenance page.

Where the daily check needs a WordPress account, it reads with a separate machine account whose role only allows fetching the monitoring data. It logs in with an application password that can be revoked with one click, and the same check also flags it if an application password appears on an unexpected account.

The Google key this site uses to refresh its reviews sits in a separate file on my computer, outside the code, and only my user can read it. Whose name the domain, the hosting and the admin should be in is covered in another piece.

Questions on this topic

← Back to Writing