Category: Security

Open the Users screen and filter to Subscriber.

If the list is full of accounts you do not recognise, with usernames that look machine-made, you are looking at the thing this post is about.

The harder question is not how to delete them. It is which settings let them in, and whether the comment queues are filling up through the same open door.

Short answer: WordPress spam registrations are new accounts created on a site by people you did not invite. Two settings decide how easy that is: whether anyone can register, and which role a new account gets. A read-only playbook can check both, count the comment queues and list accounts that are worth a look, without changing a user or a comment.

What this post is, and is not: A method write-up of one read-only playbook, based on its two step files as shown in the Protuno dashboard and on its public page on 27 October 2026. It is not a result from a real run: no playbook was run for this post, and every number in the images and video is an example value. It does not say how spam accounts get past a registration form on any particular site, because that depends on the site.

Two Doors Spam Walks Through

A WordPress site has two common ways for a stranger to leave something behind. One is an account. The other is a comment.

The account door is set in two places on the Settings, General screen. The WordPress documentation for that screen describes the first as “Anyone can register”, a checkbox for when “you want anyone to be able to register an account on your site”. The second is New User Default Role, which “allows you to select the default Role that is assigned to new users”. The valid choices it lists run from Subscriber up to Administrator.

Those two settings work together. Open registration with a Subscriber default is a small risk. Open registration with a higher default role is a different kind of problem, because every stranger who signs up arrives with more power. The user roles post explains what each default role can do.

The comment door is set on the Settings, Discussion screen. The documentation for that screen lists, among others, a checkbox that only lets logged-in, registered users comment, and a setting that closes comments on older posts after a number of days. A site where comments stay open everywhere and anyone can register has two open doors, and the queues behind them can grow without anyone noticing.

An exposure audit reads both doors in one pass. It does not close either.

What An Exposure Audit Looks At

The playbook’s public page says it looks at three things:

• Comment settings and queue sizes. Whether comments and pings are open by default, where they are still open, and how many comments sit in each queue.
• Users by role and recent signups. How many accounts exist in each role, and how many registered in the last 30 days.
• Accounts worth a look. Accounts with a throwaway email domain or a username that looks machine-made.

It then gives an exposure rating and the next steps that apply. The next sections go through how.

The Playbook, Step By Step

The Comment & Signup Spam Exposure Audit playbook has two steps, in a fixed order. In the dashboard it carries a Beta label, sits in the Content group and only reads. The public page files it under Security, says it needs no connector, and says it runs when you start it with no schedule set. This post uses the public page’s category.

Step 1: Read Exposure Signals

Step 1 is read-only. Every call it makes is a GET. It does four things:

1. It reads the settings that open the doors: the default comment and ping status for new posts, whether anyone can register, the default role, whether comments are held for moderation, whether commenters must be registered, and whether comments close on old posts.
2. It counts the comment queues: held for moderation, spam, trash and approved. It reads them 100 at a time, up to 20 pages, and reports “2000+” when a count hits that limit.
3. It looks at where comments are still open on posts, pages and media, reading up to 10 pages of each.
4. It counts users by role and how many registered in the last 30 days, using the 500 newest accounts.

From those users it picks out accounts worth a look. That part gets its own section below.

Step 2: Spam Exposure Report

Step 2 makes no calls. It takes the numbers from step 1 and rates exposure as Low, Medium or High from fixed rules, then writes a report with these headings: Comments, Signups, Accounts worth a look, Not readable on this connection, Next steps, and Note.

“Not readable on this connection” matters. If an option cannot be read, the report says so instead of guessing.

How To Read A Rating

The rules are plain counts, so you can check any rating against the numbers in the report. A Medium rating on a site that simply allows registration is not an alarm. A High rating because the default role is above Subscriber is worth fixing today.

The report’s next steps depend on what it found. They can point to the Spam Comment Deleter playbook when pending plus spam is 50 or more, to the Disable Comments playbook, to a review of the listed accounts in the Users screen “before changing anything”, and to fixing the default role or unticking “Anyone can register”. If something could not be read, it adds a pointer to check Settings, General and Discussion by hand.

What “Worth A Look” Means

This is the part most likely to be misread, so the step file is strict about it.

Only accounts with the Subscriber role, or Customer on a shop, are considered. An account is called worth a look for one of two reasons:

• Its email is on a fixed list of 30 throwaway domains, such as mailinator.com.
• Its username looks machine-made. Two patterns count: a username with no separator that ends in six or more digits, or one of ten or more characters that switches between letters and digits four or more times.

A few rules sit around that:

• The report shows only the username and the email domain, never a full email address.
• It says “worth a look”. It never calls an account fake, a bot, a spam account or malicious.
• It never recommends deleting, banning or removing a user.

The caution is fair. A real person can have a username that ends in digits, and a real person can use a throwaway address for a free download. A flag is a prompt for you to open the account and decide, nothing more. The playbook only reads, so no account changes whichever way you decide.

What The Settings And The Public Page Say

The two sources agree on the substance. Both say the playbook only reads, has two steps and needs no connector, and the public page says no step is set to pause for your approval. The one difference found is the group label: the dashboard says Content, the public page says Security.

The settings panels for both steps, viewed in the dashboard on 27 October, show Automatic backup None and Approval checkpoint Off. For a playbook that changes nothing, that fits: there is nothing to back up and nothing to approve.

What The Playbook Does Not Do

The step files and the public page set clear limits:

• It does not stop anyone registering. There is no blocklist and no email check at signup.
• It does not say how an account got in. It reads signals; it does not trace them.
• Counts stop at 2,000 comments per queue and at the 500 newest users, and the report says when a count hit its limit.
• It flags only Subscriber and Customer accounts. An account with a higher role is not flagged for its email or username.
• It does not approve, trash or delete any comment, and it does not change any user.
• “Worth a look” is not a verdict. A clean report is not proof that nothing is wrong.

A plugin that blocks signups is a separate tool. A read-only audit tells you how exposed you are; it does not close anything.

Two cases deserve their own posts. If spam accounts keep appearing after you close registration, the question changes from exposure to compromise, and WordPress Hacked: The First Hour, In Order covers what to do first. And if you want to know which accounts can be found from outside, the user enumeration post is about the routes that list usernames.

A Careful Version You Can Do By Hand

You can read the same signals yourself. It takes longer as the site count grows.

1. Open Settings, General. Note whether “Anyone can register” is ticked and what New User Default Role says. If registration is open and the role is above Subscriber, fix that first.
2. Open Settings, Discussion. Note whether commenters must be registered, and whether comments close on older posts.
3. Open Comments and read the count beside Pending, Spam and Trash.
4. Open Users and click Subscriber. Read the usernames and the email domains on that list. A page of near-identical names is a reason to look closer.
5. Write down what you found and the date, so the next check has something to compare with.
6. Only then decide what to change. Closing registration and trashing spam are separate decisions, and neither needs to happen the same day.

On one site this is a short job. Across twenty sites it becomes a recurring chore, and the repeatable part is the reading. The judgement stays with you: which accounts to open, and whether a site needs open registration at all.

The two-factor post is the next layer if a flagged account turns out to be a real one with a weak login. It separates turning two-factor on from enforcing it.

Two Outside Views

A hosting company’s video and a forum thread. Both are about neighbouring problems rather than signup spam itself, and neither describes the Protuno playbook. They are here for the habit they share with it: read what is there before you change anything.

Ahosting INC’s “Could Not Create Directory in WordPress: Find the Folder First (2026)“, published 5 October 2026, is about a plugin install error, not about accounts. Its advice is to diagnose first: find the folder path, check disk space and inode limits, and only then look at folder modes.

Check both your space and inode gauges in your control panel or you will end up chasing permission ghosts forever.

Ahosting INC, Could Not Create Directory in WordPress: Find the Folder First (2026), auto-generated English captions, 5 October 2026

It is a hosting company’s explainer that points to its own written guide, and the captions are automatic. The same video is a source in the file permissions post, which covers the error itself.

In an r/Wordpress thread, a poster describes investigating a compromised site. They say an attacker used a valid administrator session, installed a file manager plugin and used it to upload executable PHP files. Their main lesson:

A successful WordPress admin login should be treated as a full application compromise.

u/ThaiHeartly, r/Wordpress, 11 August 2026

The poster says how the administrator session was first obtained is unknown. This is one poster’s account that I could not verify, and some replies asked whether the write-up was machine-written, which the poster denied. My reading, not theirs, is that the playbook would not see a case like this. It flags only Subscriber and Customer accounts, and an account created with a higher role is outside what it flags. The user roles post is the place to look at those.

Where Protuno Fits

The Comment & Signup Spam Exposure Audit playbook is the reading part of this job. It reads the comment and signup settings, counts the queues and the recent signups, lists accounts worth a look, and writes a Low, Medium or High rating with the rule that decided it. It needs no connector, runs when you start it and has no schedule set. It changes nothing.

Two other playbooks cover the writing side, and the report points to them when they apply. Spam Comment Deleter trashes comments confirmed as spam, and Disable Comments stops new comments. Protuno publishes its playbooks as written-out steps you can read first. The playbooks page lists them, and this one has its own page at Comment & Signup Spam Exposure Audit.

The Point

Open registration is a choice, and the default role decides how big a choice it is. The comment queues are a second door. Neither tells you anything until someone reads them.

Read both doors, treat a flag as a question, and keep the decision about each account with a person. A rating on paper is a reading list, not a verdict.

If someone registered on your busiest site tonight, would you know which role they got?

Sources And Further Reading

• Settings General Screen, WordPress Documentation
• Settings Discussion Screen, WordPress Documentation
• WordPress 7.1.3 Maintenance and Security Release, WordPress.org News, 6 October 2026
• WordPress 7.2 Beta 1 is Ready for Download and Testing, WordPress.org News, 20 October 2026
• Could Not Create Directory in WordPress: Find the Folder First (2026), Ahosting INC, YouTube, 5 October 2026
• A WordPress attacker logged in as admin, installed a file manager plugin and uploaded PHP webshells, r/Wordpress, 11 August 2026. Title shortened.
• Comment & Signup Spam Exposure Audit, Protuno playbook page

A plugin install stops with “Installation failed: Could not create directory.” An upload in the media library says “Unable to create directory wp-content/uploads/2026/10. Is its parent directory writable by the server?” Or an update stops on a screen that says “To perform the requested action, WordPress needs to access your web server. Please enter your FTP or SSH credentials to proceed.”

The advice for all three is usually a number: set the folder to 777. The WordPress handbook warns against it, and a hosting company’s video about the first error says you never need it. These messages are not asking for a bigger number. They say WordPress tried to write something and the server refused, and the refusal has more than one possible cause.

Short answer: find out who owns the files and which account PHP writes as, then read the mode. WordPress itself decides whether it can write by comparing owners, not by reading digits. For servers where PHP runs as the file owner, the handbook’s baseline is 755 for directories and 644 for files, with wp-config.php at 440 or 400, and it treats 777 as a number to question. The number is the last thing to change.

What this post is, and is not: a walk-through built from the WordPress handbook, the WordPress 7.1.3 source on GitHub, two videos and one forum thread. I did not test anything on a site, and the commands near the end are read-only ones I have not run. The right values depend on your host, so the post says where to measure instead of giving one number to copy. Latest checked: WordPress 7.1.3 (6 October 2026) is the current stable release and 7.2 Beta 1 came out on 20 October. Neither announcement mentions file permissions or the filesystem.

Three Digits, Three Audiences

A mode is three digits: the owner, the group, and everyone else. Read is 4, write is 2 and execute is 1, and each digit is the sum. So 7 is read, write and execute, 5 is read and execute, and 4 is read only. That is the scheme the handbook’s file permissions page describes.

“Everyone else” means every other account and process on that server. The handbook’s warning about 777 is about those accounts and processes, not about visitors reading files.

How WordPress Decides It Can Write

Before it writes during an install or update, WordPress runs a small test. In the 7.1.3 source it is the function get_filesystem_method() in wp-admin/includes/file.php. Unless the FS_METHOD constant is defined, it works like this:

1. It tries to create an empty file named temp-write-test- plus a random string inside the wp-content directory.
2. If that works, it compares the owner of the new file with the owner of a WordPress core file.
3. If the two owners match, it writes directly from PHP.
4. If they differ, or the test file could not be created at all, it falls back to SSH or FTP and shows the credentials screen quoted at the top.

There is one more branch. A caller can allow “relaxed” ownership, and then a writable directory is enough to alter existing files, though that mode never creates new ones. The code comment says so.

Two consequences follow from reading the code. I have not run either. First, a folder at 755 that is owned by the account PHP runs as passes the test, so no 777 is needed. Second, loosening a folder to 777 does not fix an owner mismatch. PHP can create the test file, but if PHP runs as a different account from the one that owns the core files, the new file has a different owner and WordPress still asks for FTP details. The same prompt also appears when the test file cannot be created at all, which is why it can mean two different problems.

The handbook describes the working case for servers it calls “suexec”, where PHP runs as the owner of the files. There, it says, WordPress “will not ask for FTP credentials when upgrading or installing plugins”.

FS_METHOD is the documented override. The handbook’s wp-config page says it forces the filesystem method and that you should generally change it only if you have update problems. It also says “direct” is chosen automatically when appropriate, and that forcing it is “fraught with opening up security issues on poorly configured hosts”. In the code, defining it skips the test above. It does not change who owns anything.

What The Handbook Recommends

The handbook’s file permissions page gives a scheme for servers where PHP runs as the file owner, and its hardening page repeats the key values.

The page also notes that wp-config.php is “initially created with 644 permissions, and it’s a hazard to leave it like that”.

Three cautions on that table. First, the handbook says permissions differ from host to host, and that its guide covers general principles. Second, the page is not consistent about 777. Its general section says to start restrictive and raise permissions until it works, lists modes to try in order, and ends with “Only use 777 if necessary, and hopefully only for a temporary amount of time.” It also says “when you see 777 ask why it’s necessary”. Third, the hardening page says automatic updates run as the file owner and set files to 0644 and directories to 0755, so a mode you set by hand on core files is not guaranteed to survive. Check after an update, and read the auto updates post for what updates run on your site.

777 In Plain Terms

The handbook says 777 makes a file or directory readable, writable and executable by all users, groups and processes. Its worst case is that if an attacker can upload or modify a file to execute code, “they will have complete control over your blog, including having your database information and password.”

The description of that same video, from Ahosting INC, is blunter. It says the usual advice is to make wp-content 777, and “You never need it.”

The better fix is the one the handbook points to: any file that needs write access from WordPress should be owned, or group-owned, by the account WordPress runs as. That means changing the owner, then keeping the mode at 755 or 644. It does not mean raising the mode until the error goes away.

Four Causes, One Message

The same sentence can come from causes that have nothing to do with a mode.

• Wrong owner. The Ahosting video says that if a 755 mode fails to let you write to a directory, the folder likely belongs to a different user account.
• Mode too strict. The Ahosting video says a security plugin may have hardened folders to 555. The handbook’s .htaccess example says a mode set too low stops the server reading the file, which causes an error.
• Disk or inode limit. The Ahosting video says WordPress creates every empty folder before it writes a file, that each folder needs an inode, and that an account near its inode limit can fail on folders while the storage gauge still shows room. It also says the server needs slightly more than twice the unpacked plugin size to hold the zip and the extracted copy.
• A security module. The handbook says SELinux denials are often hard to tell from regular permission errors. It is typically installed on Red Hat family systems, and it can block writing the .htaccess file.

I confirmed that the sentence “Could not create directory.” appears in the 7.1.3 file wp-admin/includes/file.php, and that the upload message above appears in wp-includes/functions.php. I did not count the places the Ahosting video says the sentence comes from.

Find The Cause In Order

The Ahosting video’s order is a good one: find the path, check space and inodes, then look at modes and ownership, and only then change anything. Adapted, with two extra steps:

1. Read the full message. The Ahosting video says the Install Now button drops the folder path from its output, and shows two ways to retrieve it, which its written guide also covers. The path tells you which folder failed.
2. Ask WordPress what it can write. Go to Tools, then Site Health, then the Info tab, and open Filesystem Permissions. In 7.1.3 it lists the main WordPress directory, wp-content, uploads, plugins, themes and fonts, plus the must-use plugins directory if it exists, each as Writable or Not writable. It asks PHP, so it reports what the web process can do, not what your own login can do.
3. Check space and inodes. Look at both gauges in your hosting panel, or run the commands below on a server where you have a shell.
4. Compare owner and mode. List the owner, group and mode of wp-config.php, wp-content, uploads and plugins, and compare the owner with the account PHP runs as. Your host can tell you which account that is. A command-line php run reports the command-line user, which may not be the one that serves pages.
5. Check for a security module. On Red Hat family systems, ask whether SELinux is enforcing.

df -h
df -i
stat -c '%U %G %a %n' wp-config.php wp-content wp-content/uploads wp-content/plugins
getenforce

These are read-only commands, and I have not run them on a site. stat -c is the GNU form and differs on macOS. getenforce exists only where SELinux is installed. On shared hosting without a shell, the same information is usually in the file manager and the hosting panel.

Write down the result before you change anything. If the owner is the account PHP runs as and the modes match the handbook’s table, the mode was never the problem, and the next suspect is space, inodes or a security module.

The Outside View Is A Different Check

Nothing about a mode is visible over HTTP. An outside check can only show a file being served that should not be, and two earlier posts already cover that: the exposed twin of wp-config.php and the debug log that is readable from outside. Run those alongside this one. This post is the inside view.

For a wider look at a whole install, the hardening measurements test advice on live sites before repeating it, which is the right habit for any permission change too.

What Correct Permissions Do Not Solve

Permissions say who on the server may touch a file. They are a small part of the picture.

• A write made through WordPress. WordPress writes as whichever account PHP runs as. A plugin weakness, or a stolen administrator login, can make it write something unwanted even when the modes are correct.
• An administrator. Anyone who can install plugins or edit files from the dashboard works around the filesystem question. Who really has the keys is the check for that.
• File contents. A mode says nothing about whether a file changed. If something looks wrong, a malware scan and the first hour after a hack are the next steps.
• A tightened mode that gets reset. The handbook says automatic updates set files to 0644 and directories to 0755.
• A full account. As above, the error can come from space or inodes, and chasing a mode will not fix it.

A permission pass belongs inside a bigger one. The security audit walk-through puts the order of work in one place.

Two Outside Views

Both picks below are about spam accounts, which is a neighbour of this topic rather than the same one. They are here for the point in the previous section: a correct mode does not say anything about who is allowed to create an account or what a form lets through.

A video. WP Ultimate Security’s “Stop Fake and Spam Email Signups in WordPress“, published 3 August 2026, walks through two features of its own plugin, an email blocklist and email verification. It blocks addresses and whole domains, and it checks sign-ups, comments and WooCommerce checkout for badly formed, disposable or no-MX-record addresses. It tests each one on screen.

It’s a simple way to keep spam accounts out and block problem users without having to delete anyone’s account manually.

WP Ultimate Security, Stop Fake and Spam Email Signups in WordPress, auto-generated English captions, 3 August 2026

It is a vendor’s tutorial for its own plugin, and the description says the features need both the free plugin and its Pro version. I did not test the plugin, and the captions are automatic. Nothing in the video touches file modes.

A thread. In an r/Wordpress thread, a poster running a course site on Tutor LMS, with registration set to need manual administrator approval, describes accounts with crypto, casino and pharma names appearing as approved with no approval step and no notification email.

Lately though, my site has been flooded with user registrations that are somehow automatically approved, no admin input required.

u/realcryptogd, r/Wordpress, 18 September 2026

The replies disagree. One says this is a backdoor symptom and suggests checking for hidden administrators, webshells in uploads and files in mu-plugins. Another asks why a backdoor would need registration open, and suspects a second registration endpoint that skips the approval step. The poster tried hiding the default login page and says it did not help, and the thread does not report a cause. My reading, not theirs, is that this is the kind of problem where a folder’s mode cannot tell you anything, because the accounts are created by the application, not by a file write. It is one poster’s account that I could not verify, and the replies are guesses.

The Point

Pick one site you manage. Without changing any mode, can you say which account owns wp-content and which account PHP writes as?

If not, the number on the folder is not the thing to look at yet. The question is what WordPress sees when it tests a write, and what you would do if the answer were different on the next site.

Sources And Further Reading

• Changing File Permissions, Advanced Administration Handbook, WordPress Developer Resources, page read 27 October 2026.
• Hardening WordPress, Advanced Administration Handbook, page read 27 October 2026.
• Editing wp-config.php, WordPress upgrade constants, Advanced Administration Handbook, page read 27 October 2026.
• wp-admin/includes/file.php at the 7.1.3 tag, WordPress source on GitHub, read 27 October 2026.
• wp-admin/includes/class-wp-debug-data.php at the 7.1.3 tag, WordPress source on GitHub, read 27 October 2026.
• get_filesystem_method(), Code Reference, WordPress Developer Resources.
• Site Health screen, WordPress.org Documentation.
• WordPress.org News: WordPress 7.1.3 Maintenance and Security Release, 6 October 2026; WordPress 7.2 Beta 1 is Ready for Download and Testing, 20 October 2026.
• Could Not Create Directory in WordPress: Find the Folder First (2026), Ahosting INC, YouTube, 5 October 2026, and its written guide. Used for the causes and the diagnosis order.
• Stop Fake and Spam Email Signups in WordPress, WP Ultimate Security, YouTube, 3 August 2026.
• Spam user registration automatically approved even though the registration process requires MANUAL admin approval, r/Wordpress, 18 September 2026. Title shortened.

Open any user’s profile in the dashboard and scroll past the password box.

Below it sits a section called Application Passwords, with a name field, a button that says Add New Application Password, and a list of the keys that already exist.

Most people never scroll that far. The keys in that list can outlive the password you changed last week.

Short answer: WordPress application passwords are separate, revocable keys that apps and scripts use to sign in without the account’s normal password. Each one stays valid until someone revokes it, so a site can carry old keys nobody remembers. The New Admin Watch playbook reads every administrator and every application password, flags the recent and never-used ones, and, if you paste in a baseline, shows what changed since the last run. It only reads. It never creates, changes or revokes anything.

What this post is, and is not: A method write-up of one read-only playbook, based on its two step files as shown in the Protuno dashboard and on its public page on 22 October 2026. It is not a result from a real run: no playbook was run for this post, and every username, date and id in it is an illustration with example values.

What WordPress Application Passwords Are

Application passwords arrived in WordPress 5.6. The core team’s integration guide describes them as a way to make authenticated requests to WordPress APIs without using the account’s normal password. Cookie sign-in stays as it was. An application password cannot be used on the login page, because it is meant for programs, not people.

The same guide says how one is stored:

• It is 24 characters of upper-case letters, lower-case letters and numbers.
• It is kept in the user’s meta data, with the name given to the application, the time it was created, and when and from which IP address it was last used.
• Each one also gets its own uuid, so it can be referred to without using its name.

You manage them from the Edit User page, where you can create new ones and view or revoke the ones that exist. The Last Used column is accurate to within 24 hours, because WordPress only writes the date once a day. The guide says that makes it useful for finding passwords that are no longer in use, so they can be revoked.

By default the feature is available on sites served over HTTPS and on local environments, and the developer reference says a filter can change that. The REST API handbook adds that the credentials go to REST requests over HTTPS using Basic Auth.

Latest changes checked on 22 October 2026: WordPress 7.1.3 (6 October) is the current stable release, and 7.2 Beta 1 came out on 20 October. Neither announcement mentions application passwords or administrator accounts. So everything above comes from the 5.6 guide, the developer reference and the REST API handbook, not from release notes.

Why A Key Outlives A Password

A password reset feels like a clean slate. An application password does not care.

A tutorial from SmartWP, covered below, makes the point in plain terms. An application password is a separate credential that you give to one app. You can issue several, and you can revoke one without touching the others. In his demo, changing the account’s normal password does not interrupt the app that holds a key.

That is exactly why they are useful, and exactly why they get forgotten. The key sits in a list, nobody opens that list, and the app that used it may be long gone.

A key also carries the powers of the account it belongs to. A post on WordPress MCP write access makes the point for AI connections: an application password issued to an administrator carries administrator capabilities.

Two Lists To Read Together

The first list is who can act as an administrator. The second is which keys exist for each user, and when each was last used.

Neither list answers the real question on its own. “Who can get in?” needs both. A post on user roles covers listing every account and the three accounts to question first. This playbook adds the second list and puts both into one report.

The Playbook, Step By Step

The New Admin Watch playbook has two steps, in a fixed order. In the dashboard it carries a Beta label and only reads. The public page files it under Security and says it needs no connector. It runs when you start it, and no schedule is set.

No step pauses for approval. I opened the settings panel for both steps, and both show Automatic backup None and Approval checkpoint Off, which fits steps that only read.

Step 1: Snapshot Admins And Credentials

Step 1 makes one call to a Protuno read tool. The tool reads the site itself and applies every check in code. The step does not compare, count, judge or sort anything on its own. It copies what the tool returns into one fixed block for step 2.

The step file says the tool applies eight checks, and names what it covers:

• Which application password is this connection’s own, so it is not listed as a stranger.
• Changes since the baseline, if one was pasted.
• Recent accounts and recent passwords.
• The admin username.
• Passwords that have never been used.
• Extra capabilities on a user.
• Admin-level powers held without the administrator role.
• Administrators through a second role.

If the administrator list cannot be read, the step stops with “Could not read the administrator list.” and fails. In every other case it ends as a pass.

The baseline is optional. It is three lines pasted into the playbook’s Instructions: a line starting BASELINE, then admins: and app-ids:.

Step 2: Admin Watch Report

Step 2 makes no calls and judges nothing. It lays out the block from step 1 in a fixed layout. A header line gives the number of administrators, the number of application passwords and whether a baseline was given, followed by the connection and the users by role. Then come six sections, always in this order:

1. Checks.
2. Changes since the baseline, as a table.
3. Things to confirm, as a table with finding, user, detail, severity and what to do.
4. Administrators, as a table with id, username, registered date, email domain and application passwords.
5. Not checked.
6. Baseline, a new set of three lines to copy.

The findings are exactly the lines the tool returned. Nothing else counts as a finding, and the step may not add, drop, reword or re-rate a row. Two privacy rules apply. An email address is shown as its domain only. An application password is shown by the first 8 characters of its id, never by its name, because two passwords can share a name.

How A Baseline Turns A List Into A Change

Without a baseline, the report says “No baseline given: date-based checks only.” An administrator or an application password created in the last 30 days is flagged as recent. That is a useful nudge, but it cannot tell you what changed.

With a baseline, the next run can say what is different. The dashboard card says the next run also shows new administrators, raised roles and new application passwords. If there is a baseline and nothing moved, the report says “No changes since the baseline.”

The report ends with a new baseline to paste back in next time. To use it, open the playbook page, find “Runs on these sites”, open Instructions for the site, paste the three lines, and save.

That is the whole habit: read, paste, compare later. A list you read once tells you what exists today. A list you compare tells you what moved.

Reading A Finding

The report is strict about words. It must never say the site “is secure”, “is safe”, “was hacked” or “is compromised”. A finding is something to confirm with the site owner, not an accusation.

That matters in practice. A new administrator may be a new hire. A never-used key may be a connection someone set up last week and has not tested yet. The row tells you where to look and who to ask. It does not tell you what happened.

What The Report Does Not Cover

The step files list what stays out of reach:

• Users hidden from the REST API by a plugin or malware. The list comes from the REST API, so it can never be proven complete.
• Changes made directly in the database.
• Powers a custom role grants by itself. Only powers given directly to a user are read.
• Login history and failed logins.

It also never reads a password, and it creates, changes or revokes nothing. If you find a key you do not recognise, the revoking is your decision, made on the Edit User page.

If the REST user list is part of the question for you, a post on WordPress user enumeration looks at how that user list is exposed from outside.

A Careful Version You Can Do By Hand

You can do a rough version of this without any playbook. It follows the same order.

1. Open Users, filter to the Administrator role, and write down every username. Mark any you cannot place.
2. Open each administrator’s Edit User page and scroll to Application Passwords.
3. For every key, write down its name, when it was created and its Last Used value.
4. Mark keys that were never used, and keys that have not been used for a long time. Remember Last Used is accurate to within 24 hours.
5. For any key you do not recognise, find out who owns it before you revoke it. Revoking cuts off whatever app uses it, and in the SmartWP demo that is the point.
6. Save your notes as a plain text file with each username, key name and created date. That file is your baseline.
7. Repeat monthly and compare the two files.

Two keys can share a name, so a note by name alone can mislead. That is why the playbook identifies each key by the first 8 characters of its id.

Application passwords are one of the sign-in routes that do not use the login form. A post on two-factor enforcement lists those routes, and a post on the first hour after a hack includes application passwords in the WordPress layer of access to review.

Two Outside Views

A tutorial and a forum thread. Neither is an endorsement, and neither describes the Protuno playbook.

In a November 2024 video, SmartWP explains how to set up and use application passwords safely. He says an application password is like a normal WordPress password but meant for one app, and that sharing it is safer than sharing your real password. He says you can make several and revoke access to a specific application. In the demo he creates one named for Zapier, says it can be pasted into Zapier, and notes that resetting his normal password would not interrupt it. When he is done with Zapier he revokes the key so Zapier can no longer edit the site. The video is older than the releases above, and near the end he mentions a blogging platform he built that supports the feature.

On Reddit, an r/Wordpress thread titled “How many people can log into your sites as Administrator, and do they open links?” starts with a site manager asking a simple question: “How many Administrator accounts are on the sites you look after?” This post does not rely on the opening post’s security claims. It uses the question and one reply, which describes the baseline habit in a few words:

“We have a single administrator account on all the sites we manage, our own. There is a specific list of capabilities we have never given out and our nightly sync will alert us if this somehow changes in a site.”

Reply in the thread, r/Wordpress, 3 October 2026

Another reply in the same thread gives a different answer: “2-3 admin acccounts is the normal number but I only manage a couple dozen WP installations.” A count on its own does not settle much. What matters is whether you can see a change when it happens.

Where Protuno Fits

The New Admin Watch playbook is the repeatable, read-only part of this job. It lists every administrator and their application passwords, flags recent accounts, the default admin username, new or unused keys and extra capabilities, and writes a report with a baseline you can paste back in. It needs no connector, runs when you start it, and has no schedule set.

It sits beside the other security posts rather than replacing them. The Security Audit playbook has its own post. The playbooks page lists the playbooks as Protuno publishes them, and this one has its own page at New Admin Watch.

The Point

A password is something you change. An application password is something you have to find.

Read both lists together, keep a baseline, and treat every unfamiliar row as a question for the site owner. A report that revokes nothing is the safest way to see how many keys your sites are holding.

Which keys on the sites you manage could you name today without looking?

Sources And Further Reading

• Application Passwords: Integration Guide, Make WordPress Core, 5 November 2020
• wp_is_application_passwords_available(), WordPress Developer Resources
• Authentication, REST API Handbook, developer.wordpress.org
• WordPress 7.1.3 Maintenance and Security Release, WordPress.org News, 6 October 2026
• WordPress 7.2 Beta 1 is Ready for Download and Testing, WordPress.org News, 20 October 2026
• WordPress Application Passwords – How to Set Up & Use Them Safely, SmartWP, YouTube, 18 November 2024
• How many people can log into your sites as Administrator, and do they open links?, r/Wordpress, 2 October 2026
• New Admin Watch, Protuno playbook page

Every WordPress site has an account nobody remembers creating.

It might belong to a freelancer from two years ago, a plugin vendor’s support login, or a colleague who has since left. It still works. It is still an Administrator.

The password is only half the problem. The bigger question is how many people can change your site today, and whether you could name every one of them.

Short answer: To audit WordPress user roles, open the Users screen, filter by role, and count the Administrators. Each one can install plugins, edit code and create more users. Any Administrator with no named owner and no clear reason to exist is the first account to question. Then check whether anyone has a role above their job, and whether any login is shared.

What this post is, and is not: A read-only audit of WordPress user roles, for people who look after several WordPress sites. The role descriptions follow how WordPress core documents its default roles. Nothing here is a result from a real client site, and it does not replace a full security audit.

An Administrator is not a job title. It is a list of everything someone can break.

WordPress User Roles: What Each Default Role Can Do

A single WordPress site ships with five roles. They are ordered by how much damage one stolen login can do.

For a short overview of the defaults, there is a recent video, WordPress User Roles Explained (2026), from VIS Mountain Marketing & Advertising. Its description says it is narrated with an AI voice and shows simplified diagrams, not live screenshots, so use it as a refresher and check the official documentation for detail.

What each WordPress role can really do, which one to give each kind of person, and how to change someone’s role in under a minute.

VIS Mountain Marketing & Advertising, “WordPress User Roles Explained (2026): Which Role to Give Each Person + How to Change It” on YouTube, 6 Oct 2026

Two things change this picture.

First, plugins add roles and change what the default ones can do. A store plugin adds a Shop Manager. A membership plugin adds its own. These roles can carry real power, and they rarely stand out in a quick look at the Users screen.

Second, a multisite network has a Super Administrator above every site. That one account controls the whole network, not a single site.

Of all the WordPress user roles, one matters most for an audit. Administrator decides who can change everything else.

Listing Every Account From Outside And Inside

You can see your accounts and their WordPress user roles from two places, and the two lists do not match.

From inside, the Users screen or the command line shows every account, its role and when it registered. From outside, you only see what the site chooses to reveal. By default, a WordPress site can reveal usernames through public routes. We covered all three of them, and how to close them, in WordPress user enumeration is still on by default, so this post does not repeat that.

What matters here is the gap between the two lists.

A small audit you can run today:

• Count the accounts in each role on the Users screen.
• Save the Administrator list with name, email and registered date.
• Write an owner and a reason beside every Administrator.
• Mark every account you cannot explain.

With command-line access, these two commands cover the first steps:

wp role list
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

The registered date is the cheapest clue you have. An old account with no known owner is the first one to question.

One more caution. Code that runs inside WordPress can change what WordPress shows you. The r/Wordpress write-up linked below describes malware that kept a list of administrator accounts to hide, so a Users screen can look clean when it is not. If you suspect a problem, ask the database directly. This query lists every account with the Administrator role, and you should change each wp_ to your own table prefix:

wp db query "SELECT u.ID, u.user_login, u.user_email, u.user_registered FROM wp_users u JOIN wp_usermeta m ON m.user_id = u.ID WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%'"

If that list is longer than the Users screen, treat it as an incident and not a tidy-up.

The Three Accounts To Question First

An audit of WordPress user roles does not need to be long. Three kinds of account cover most of the risk.

1. Administrators nobody can name. If no one on your team can say who it belongs to and why it exists, treat it as a finding. A forgotten Administrator is an unlocked door that nobody knows about.

2. Accounts with a role above their job. A writer who publishes their own posts needs Author, not Editor. A client who updates one page needs Editor at most. Ask whether the person could do their job one role lower. Agencies argue about whether a client should get Administrator all the time, and the least-privilege answer is almost always no.

3. Shared logins. One account used by three people cannot be traced to any of them. When something changes, nobody can say who did it. Give each person their own account, then remove the shared one.

One r/Wordpress thread, “Found a WordPress malware using __GA_INJ_START__ and hidden admin accounts — full incident analysis”, is a write-up of a hacked site where the attacker kept hidden administrator accounts. The author describes how the malicious code worked:

“The malicious code maintained a list of administrator accounts that should be hidden.”

r/Wordpress, “Found a WordPress malware using __GA_INJ_START__ and hidden admin accounts — full incident analysis”, August 2026

What Changing A Role Breaks

Removing access is easy to say and harder to do. A role change can stop things that quietly depend on it.

Check these before you demote an account:

• Scheduled work. Does a plugin run jobs as that user?
• Authorship. Posts belong to the account. Deleting the user forces a choice about where the content goes, while demoting does not.
• Integrations. An automation tool or API may sign in with that login.
• Backups and updates. Some tools act as a named Administrator.

The safe order is short. Demote first, and do not delete. Watch the site for a few days. Delete only when nothing has broken.

Take a restore point before changing roles on a real site. If something does break, a rollback is only as good as what it can actually undo, so find that out before you need it.

Checking It On A Schedule

A WordPress user roles audit done once goes stale. People join, leave and change jobs, and plugins add roles.

Keep the software current as well. WordPress 7.1.3 was released on 6 October 2026 as a maintenance and security release, and the announcement recommends updating immediately. A tidy account list says nothing about the code that guards it.

A monthly pass is enough for most sites. Compare this month’s Administrator list with last month’s. Anything new needs an owner and a reason. Anything missing should be a change you expected.

For agencies, this belongs in the client report as one short line: how many Administrators, and whether each one is accounted for. We wrote about what goes into a client report and what stays out. An Administrator list is a good example of a short finding that earns its place.

A role review also fits inside a wider WordPress security audit, next to the basics in WordPress hardening.

What This Does Not Solve

An audit of WordPress user roles is a view of access, and it has limits.

• It does not tell you a password is strong. A well-named account with a weak password is still a weak account.
• It does not show activity. Core WordPress does not record who logged in or what they changed. You need an activity log for that.
• It does not see plugin roles in full. Some plugins grant power through their own settings, not through the role name.
• It does not see an account that hides itself. The Users screen is only as honest as the code running behind it. Compare it with a direct database query when something feels off.
• It does not catch an account that was created and removed. If someone added an Administrator, did their work and deleted it, the list looks clean.
• It does not cover access outside WordPress. Hosting panels, SFTP, database users and DNS each have their own accounts.
• It does not cover access given to software. Connecting an AI tool or an automation is another kind of access and needs its own questions. We listed them in AI agent permissions on WordPress.

A clean list from a check that skipped half these places is worse than an honest “I reviewed WordPress users only.” Say which places you covered.

A Five-Site Audit You Can Do This Week

Pick five sites you look after. For each one, write down:

• The count of accounts in each role.
• Every Administrator, with a name, an owner and a reason.
• Any account that has not logged in for a long time, if you can tell.
• Any account with a role above the person’s job.
• Any shared login.

Then choose one outcome for every account you questioned:

1. Keep it, with an owner and a review date.
2. Demote it one role.
3. Test the change on a copy first, then demote.
4. Replace a shared login with named accounts.
5. Remove it, after a demotion period with nothing broken.
6. Investigate it, if nobody can explain it.

Investigate first. An Administrator nobody can explain decides whether this was a tidy-up or an incident.

Sources And Further Reading

• Roles and Capabilities, WordPress documentation: the official summary of the default roles, including Super Admin.
• Roles and Capabilities, WordPress developer handbook: how roles are stored and how plugins add their own.
• wp user list and wp role list: the two WP-CLI commands used above.
• WordPress 7.1.3 Maintenance And Security Release: the 6 October 2026 security release.
• WordPress User Roles Explained (2026): a short video overview of the default roles, by VIS Mountain Marketing & Advertising.
• Found a WordPress malware using __GA_INJ_START__ and hidden admin accounts — full incident analysis: an r/Wordpress incident write-up that includes hidden administrator accounts.

The Point

WordPress user roles are a list of who can change your site. Most sites hold more of that power than anyone has written down.

You do not need a tool to start. You need an hour and a list.

How many Administrators does your busiest client site have, and could you name every one of them?

The worst moment of a hacked site is not the discovery. It is the next ten minutes.

You open the dashboard, you start deleting things, you reset one password, you restore a backup. Every one of those moves feels like progress. Several of them destroy the evidence you need, or lock the door while the intruder is still inside.

Short answer: When a WordPress hacked site lands on your desk, do the first hour in this order. Write down what you see. Copy the site as it is. Cut off access, including the access that sits above WordPress. Check the backup before you trust it. Clean, update, and rotate passwords again once the site is clean. Only then ask how they got in. The order matters more than any single tool.

What this post is, and is not: A practical response checklist for people who run or look after WordPress sites. It draws on the official WordPress.org guide to a hacked site. The order of the seven moves, and the reasons for it, are ours. It is not a malware removal service, not legal advice, and not a result from a real incident. If the site holds customer payment data or personal data, tell your host and take professional help early.

A scan tells you what is wrong. A response tells you what to do first.

Why Panic Cleaning Makes It Worse

The urge is to fix what you can see. A strange admin user, a defaced page, a spam redirect. You remove it and the symptom goes away.

That tells you very little. A visible symptom is often the last thing an intruder did, not the first. The way in is usually still open, and a copy of the way back in may already be sitting in a file you have not looked at.

The WordPress.org guide opens with a plain instruction: stay calm, then document. It says a hack is an ambiguous word that tells you little about what happened, so the symptoms you can name are the thing to write down first.

Panic cleaning has three common results:

• Evidence is lost. If you delete before you copy, you cannot tell afterwards what was changed.
• The door stays open. Cleaning files without changing access lets the same account or key back in.
• A bad backup gets restored. A copy taken after the break-in can bring the problem straight back.

We looked at the scanning side in WordPress Malware Scan. A scan answers “what is on this site”. This post answers the question that comes before and after it: what do I do, and in what order.

Seven Moves For A WordPress Hacked Site

Each move gets its own section below.

Move One: Write It Down Before You Touch Anything

Open a note and write four things. It takes five minutes and it is the most useful five minutes of the hour.

• What you are seeing that tells you the site is hacked.
• When you noticed it, with the time zone.
• What changed recently: a new plugin, a theme edit, a new user, a host move.
• Where the site is hosted, and who else has access.

The WordPress.org guide lists the kind of symptoms that count as clear signs: the site is blocked by a search engine, the host has disabled it, it is flagged for distributing malware, visitors report their antivirus is warning them, you hear it is being used to attack other sites, or you see actions nobody authorised, such as new users.

Write down which of those you actually saw. “It looks hacked” is not a symptom. “A new administrator account appeared on Tuesday” is.

Move Two: Copy The Site As It Is

Before you clean, take a full copy of the files and the database. Keep it somewhere that is not the same server.

This copy is not a backup you plan to restore. It is evidence. If the cleanup breaks something, you can go back. If you later need to work out how the intruder got in, you have something to read.

The same WordPress.org guide makes the point that even an infected copy is worth keeping. It recommends one more snapshot of the environment before the cleaning starts.

Ask your host for logs while you are at it. Many hosts keep very little for very long, so ask early. We cannot say what yours keeps. The point is that a log you did not ask for in time is a log you will not have.

Move Three: Lock Access, Including The Part Above WordPress

Locking access means more than changing the admin password.

Think of access in three layers:

For WordPress itself, the official guide suggests forcing a password reset for all users, especially administrators, and changing the secret keys in wp-config.php. Changing the keys logs everyone out, including a session the intruder may still be holding.

For hosting, change the SFTP, control panel and database passwords, and remove any key or user you do not recognise. If you cannot name an account, treat it as a finding.

For people, the guide recommends scanning your own computer too. In many cases the infection starts on a local machine that captured a login.

If you cannot log in at all, the guide describes a way back through the database tools your host provides, by resetting the user record directly. That is a task for someone comfortable in the database.

We looked at how accounts and routes get exposed in WordPress user enumeration. It is a useful read for the question “which names can an outsider see”.

Move Four: Check The Backup Before You Trust It

Restoring a backup feels like the safest move. It is only safe if the backup is older than the break-in.

An intruder may have been inside for days before anything visible happened. A backup taken last night can contain exactly what you are trying to remove. The WordPress.org guide notes that you can restore a backup and move straight into the investigation, which is the careful way to read it: restore to look, not to relax.

Three questions to ask of every backup:

• When was it taken, compared with the first sign of trouble? Use your notes from move one.
• Where is it stored? A backup on the same server may have been reached too.
• Has it ever been restored on a test copy? If not, it is a file with a hopeful name. We wrote about that in verifying a WordPress backup.

Move Five: Clean The Cause, Not The Symptom

Cleaning means replacing, not patching. The guide’s approach is practical and worth following closely.

• Core. The folders wp-admin and wp-includes can be replaced safely with a fresh copy of the same WordPress version. The guide suggests using SFTP to upload them rather than the dashboard reinstall, because the dashboard installer tends to overwrite existing files and intruders add new ones.
• Plugins and themes. Reinstall them from their original source. A modified file that looks normal is the whole point of a backdoor.
• The .htaccess file. The guide calls it one of the most commonly modified files, whatever the type of infection, and notes it may sit in more than one folder.
• Files that load on every request. index.php, header.php, footer.php and functions.php are named in the guide because a change there affects every page.
• Users and the database. Check administrator accounts and look for anything you did not create.

Deactivating is not removing. A file that runs when someone requests its address does not care whether the plugin around it is switched on. Delete what should not be there.

The official guide calls finding and removing the hack the most daunting part of the whole process, and it gives no single method, because the right steps depend on the symptoms and on your own technical skill. If you are not sure, a professional clean is cheaper than a second hack.

One practical walk-through is Ferdy Korpershoek’s video, WordPress Getting Hacked? Here’s What To Do Now, which shows a real hacked website being scanned and cleaned. The description says it uses the MalCare plugin and discloses an affiliate link, so read it as one practitioner’s method, not as a recommendation from us.

I’ll even show you a REAL hacked website, how malware was detected, and how we removed it in just a few clicks.

Ferdy Korpershoek, “WordPress Getting Hacked? Here’s What To Do Now” on YouTube, 18 May 2026

Move Six: Update, Then Change The Passwords Again

Once the site is clean, update WordPress, plugins and themes to the latest versions. The guide says older versions are more prone to being hacked, and that is where many incidents start.

A timely example. WordPress 7.1.3 was released on 6 October 2026 as a maintenance and security release. The announcement lists seven security fixes and four bug fixes, and says that because it is a security release, updating immediately is recommended. We cannot say whether any particular hack used any of those issues, and this post does not claim that. The practical point is smaller: if your site is behind on core updates, that is the first thing to fix.

Then change the passwords a second time. The guide is explicit about this. If you changed them when you found the hack and the intruder was still inside, the new passwords may have been seen. Change them again after the site is clean, and consider changing the database user and password as well.

Two things are worth turning on at this point: a second factor on logins, and a short list of who has access at all. We looked at what happens when a vulnerable plugin goes unnoticed in WordPress vulnerability scanner design and at forgotten plugins in removed plugins.

Move Seven: Find Out How They Got In

This is the step that gets skipped, because the site looks fine again.

The WordPress.org guide calls it forensics: understanding what happened and how the attacker got in, so it cannot be used again. It admits that is hard for most site owners because of missing data and technical depth.

You can still narrow it down with what you already wrote and copied:

• Compare the date you first saw a problem with the dates of your last plugin and theme changes.
• Look at the accounts that were added, and when.
• Check whether any plugin or theme was out of date, abandoned or removed from the repository.
• Ask whether the PHP version was supported. See the WordPress PHP version problem.
• Ask the host what they saw on their side.

If you cannot find the cause, say so in your notes. “Unknown, access rotated, monitoring added” is an honest record. A made-up cause is worse than none.

A site that comes back dirty is exactly what this step is for. One r/Wordpress thread, “How to fix wordpress hacked website? Can anyone guide step by step.”, starts from a site owner whose developer cleaned the site and saw the files return. Without knowing how the intruder got in, a clean-up can only hope the same door stays shut.

“I got that checked by developee and he cleaned it but everything came back.”

r/Wordpress, “How to fix wordpress hacked website? Can anyone guide step by step.”, October 2026

Blacklists And Search Console Warnings

Search engines and antivirus tools may flag a hacked site. The guide recommends registering the site with the webmaster consoles so you hear about it from them. Google Search Console also has a Manual actions report. If Google has issued a manual action against the site, you fix every affected page and then select Request Review in that report, describing what you fixed. Check the report for the exact wording that applies to your case.

Treat that as a signal, not as proof. Not seeing a warning does not mean the site is clean, and seeing one does not tell you what is wrong. Check the site, then check the report.

What This Does Not Solve

A first-hour order is a way to stop making it worse. It does not make a hack impossible.

• It does not tell you how you were hacked. Move seven narrows it down. It does not prove it.
• It does not guarantee a clean site. Intruders can plant more than one way back in. A single clean scan is not the end.
• It does not replace professional help. Customer data, payment data and legal duties need someone qualified.
• It does not prevent the next one. Prevention is a different job. We measured common hardening advice in WordPress hardening.
• It is not a result from a real incident. Nothing in this post comes from a site we cleaned.

A response checklist is for the day it happens. A monitoring habit is for the days before it. Our write-up of WordPress security monitoring covers the second one.

A Five-Site Check You Can Do This Week

You do not need a hack to practise. Pick five sites you look after and answer these for each:

1. Where would you write down what you see, and who gets the note?
2. Can you take a full copy of files and database in under an hour?
3. Who holds hosting, SFTP and database access, and when were those passwords last changed?
4. Has your newest backup ever been restored on a test copy?
5. Is the site on the latest WordPress version, with a supported PHP version?

Then pick one outcome per site: fix it now, test it first, hand it to someone who owns it, or accept the gap with an owner and a date.

If a site fails three of the five, start with that one. Our piece on the client report is a useful reminder of how to tell a client what you found, in the order they need it.

Sources And Further Reading

• FAQ: My Site Was Hacked: the official WordPress.org guide this post draws on.
• WordPress 7.1.3 Maintenance And Security Release: the 6 October 2026 security release.
• Hardening WordPress: the official guide to securing a site once it is recovered.
• Manual Actions Report, Search Console Help: how Google reports a manual action and how to request a review.
• WordPress Getting Hacked? Here’s What To Do Now: a video cleanup walk-through by Ferdy Korpershoek.
• How to fix wordpress hacked website? Can anyone guide step by step.: an r/Wordpress thread from a site owner whose cleaned site was reinfected.

The Point

A hacked site is two jobs: stop it, then understand it.

The first hour is about doing them in that order.

Which of your sites has no written answer to “who has access, and when did we last change it”?