Updating closes the door. It does not tell you whether anyone came through it first, and after the WordPress core flaws disclosed in July there was a window where a lot of sites were standing open. If you have patched and moved on, this is the bit that got skipped.
None of this needs you to be technical. The first three checks you can do yourself, in the same dashboard you use to edit a page. The last two need your host or whoever looks after the site, and the wording for that is below.
Start with your version
Log in, go to Dashboard, then Updates. Anything below 6.9.5, or below 7.0.2 on the newer branch, or below 6.8.6 if you are on the older one, was exposed. If you have already updated, find out when. The gap between 17 July and the day you patched is the window you are checking.
Look at your users
Users, then All Users, and filter by Administrator. You are looking for accounts you do not recognise, and accounts whose role has changed recently. An old developer's login that has been sitting there for three years is a separate problem, but deal with it while you are in there.
Anything you cannot account for, do not delete it yet. Note it down. Deleting it removes the evidence and rarely removes the attacker.
Look at your plugins
Plugins, then Installed Plugins. Two things to spot. Plugins you did not install, and plugins that do not exist in the WordPress directory when you search for them by name. Attackers install their own as a way back in, and they tend to pick dull, plausible names.
The two checks someone else has to do
The last two need access to the site's files and its record of visits, which is your host's territory or your developer's. You do not need to understand them, only to ask. Here is the ask, in words you can forward as they stand.
"Please check for program files where there should only be pictures." The folders holding your uploaded images and documents should contain images and documents. Program files sitting in them were put there by somebody. Ask them to check WordPress's own files for recent changes too, and the end of the main settings file.
"Please search the site's visit records for these three things."
- Requests to /wp-json/batch/v1 or /?rest_route=/batch/v1
- Responses with the code 207, which barely occur in ordinary traffic
- Visitor names containing wp2shell or rezwp2shell
Copy that list into an email as it stands. You do not need to know what it means. The person reading it will.
One thing to understand, because it will come up: being probed is not the same as being broken into. Every site got probed. It is a probe plus something else from this list that matters. And if your host says they cannot give you visit records at all, that tells you something about them regardless of how this turns out.
If you find something
The instinct is to delete the bad thing and carry on. Please do not. If someone got in, assume they made sure they could get back, and that they had time to look around.
The order that works: take a copy of the site as it stands, so you keep the evidence. Change every password and access key the site touches, and that means all of them, not just your own login. Restore from a backup taken before the window if you have one you trust. Then update, then put it back online.
If that sounds like more than you want to take on, that is a completely reasonable place to stop and call somebody. Half-cleaning a compromised site is worse than not starting, because it leaves you confident and still compromised.
If you find nothing
Good, and it is the likeliest outcome. Two things to do while the subject is in front of you. Turn automatic updates back on if someone switched them off (Best Practices for Updating WordPress Plugins and Core covers the rest of that routine). And write down what your site runs, who maintains each part, and when it was last checked. That list is what makes the next incident a ten-minute job instead of a bad week.