WordPress hacked? The checklist for what no scanner can see
Your site was hacked, the logs show the changes were made from your own account — sometimes from your own IP address — and the security scan comes back clean. That combination usually means the way in wasn't the server at all. Every scanner and monitor that looks at the site, Relvato included, sees what's on the server and what the pages show. Attackers increasingly get in through places that live somewhere else: an admin's browser, their computer, or the accounts around the site. This checklist covers those places, in the order to lock them down. For the places malware hides on the server itself, see where WordPress malware hides.
Why a clean scan doesn't mean a clean site
A security plugin, a file-integrity check and an admin audit all answer the same question: what is on the server? They catch a planted file, a changed core file, an unknown administrator. They can't tell whether the person using a real administrator account is the administrator. If an attacker is using your session or your passwords, every change they make looks like yours — the logs show your account, and when the attack runs inside your own browser, your IP address too.
So once the server is clean, the job isn't finished. Work through the places below, and do it from a device you trust.
1. Browser extensions
An extension can read and change every page you open, including wp-admin, while you're logged in. Extensions get sold, and a new owner can push an update that quietly acts on the sites you administer: adding an admin, installing a plugin, editing a theme file — all with your session, from your browser, at your IP. This is the most common explanation for "it was done from my own account".
Open your browser's extensions page (chrome://extensions in Chrome) on every computer an administrator uses. Remove anything you don't recognise, don't use, or that asks to "read and change all your data on all websites" without a clear reason. From now on, do WordPress admin work in a separate browser profile with no extensions.
2. The administrator's computer
Password-stealing malware (infostealers) copies the passwords saved in your browser and the login cookies of every site you're signed in to. A stolen login cookie is a session that has already passed two-factor authentication, so 2FA doesn't stop whoever holds it. These infections often come from a cracked program, a fake update or a fake CAPTCHA that asked you to paste a command.
Scan every computer that has logged in to wp-admin, hosting or email. Until you're sure a device is clean, treat every password saved in its browser as known to the attacker, and change passwords from a different device.
3. What the site left in your own browser
A service worker registered while you were in wp-admin lives in your browser, not on the server, and it keeps running after the site is cleaned. Your browser also holds the site's cookies and cached scripts.
In each administrator's browser, open the site, then Developer tools → Application → Storage → Clear site data. That removes its service workers, cookies and cached files for that site.
4. Hosting, SFTP, SSH and the database
Your hosting account sits above WordPress. An attacker who got in there can add a control-panel user, an FTP or SFTP account, an SSH key in authorized_keys, a database user that accepts remote connections, or a cron job in the hosting panel that rewrites files every hour. None of these are visible from inside WordPress, so no WordPress plugin can report them.
Log in to the hosting panel and list every user, FTP account, SSH key, database user and scheduled task. Remove what you didn't create, and change the hosting, SFTP and database passwords.
5. The email inbox
The inbox that receives WordPress password resets, and the hosting and registrar notices, is the key to everything else. A forwarding rule that copies password-reset emails to an outside address, or a filter that archives security alerts before you see them, survives every change of your WordPress password.
Check the mailbox's forwarding rules, filters, app passwords, connected apps and recovery email and phone. Turn on two-factor authentication, and sign out all other sessions.
6. Google, Search Console and Tag Manager
After a break-in, attackers often add themselves as an owner in Google Search Console or Bing Webmaster Tools. From there they can submit spam sitemaps, ask Google to remove your real pages and read your search data — and an owner stays an owner after the site is cleaned. Relvato's SEO integrity check flags a new verification token on the site, but the list of owners lives in Google's account, not on your server.
Google Tag Manager is the other one: whoever can publish a container can put a script on every page without touching your server. Check the users in Search Console (Settings → Users and permissions), Bing Webmaster Tools, Tag Manager and Analytics, and remove anyone you don't know.
7. Domain registrar, DNS and CDN
Whoever controls the domain controls where the site and its email point. Check the users and API tokens at your registrar, your DNS host and your CDN (Cloudflare especially), turn on two-factor authentication and the registrar's transfer lock. Relvato's DNS monitoring flags a nameserver or mail-server change, but it can't see who holds a login to those accounts.
8. Deploy keys, integrations and backups
If the site deploys from GitHub or another repository, check its deploy keys, CI secrets and who can push. Check the integrations that hold a key to the site: backup services, uptime monitors, page builders' cloud accounts, application passwords you created for Zapier or a mobile app.
And the backups themselves: restoring one taken after the break-in restores the break-in. In Relvato, the site's Security page shows when every integrity check last passed at once — a backup from that window is the safest one to restore.
Lock it down in this order
Order matters because each account can reset the next. Start with the device: from a computer you trust, or a freshly cleaned one. Then the email inbox, because it receives every other reset. Then the registrar, DNS and CDN accounts, then hosting, SFTP, SSH and database users. Then WordPress: remove unknown administrators and application passwords, change every administrator's password, and generate new security keys in wp-config.php so every existing session is signed out. Last, the third-party consoles: Search Console, Tag Manager, analytics and deploy tools.
At every step, use the "sign out of all sessions" option where there is one. Changing a password doesn't end a session that was already stolen.
What Relvato checks, and what it can't
Relvato checks the site from outside, the way a visitor does, and through its WordPress plugin, which reports what's on the server — never file contents. It finds planted files and code evaluated from the database, administrators hidden from the Users screen, application passwords, service workers registered by injected code, DNS changes and new Search Console verification tokens. When it sees signs of a hack, it shows this checklist beside them and can put the site in quarantine for 48 hours.
It can't see your browser, your computer, or the accounts on this list. Nothing running on a server can. That part is yours to check — and it's often where the attack started.
Where attackers get in that a server scan can't see
| Where | Why the server can't see it | What to check |
|---|---|---|
| Browser extensions | They act inside wp-admin with your session, from your IP | Remove unknown extensions; admin work in a profile with none |
| The admin's computer | Stolen passwords and login cookies are used elsewhere; a cookie skips 2FA | Scan it; change passwords from another device |
| The admin's browser data | A service worker or session lives in the browser | Clear site data for the domain in each admin's browser |
| Hosting, SFTP, SSH, database | These accounts sit above WordPress | Users, SSH keys, database users and the host's cron jobs |
| Email inbox | Password resets arrive there | Forwarding rules, filters, app passwords, recovery settings |
| Google and Bing consoles, Tag Manager | Owners and containers live in Google's and Microsoft's accounts | Owners in Search Console and Bing; who can publish in Tag Manager |
| Registrar, DNS, CDN | The domain's control panel is somewhere else | Users, API tokens, two-factor login, transfer lock |
| Deploy keys and backups | Keys live in other services; a backup can hold the infection | Deploy keys, CI secrets, integrations; restore from before the break-in |
Questions, answered
Why do my WordPress logs show my own account and IP address?
Because the changes probably came from your own browser: a malicious extension acting with your session, or malware on your computer. The server sees a real administrator doing real things, so every log looks legitimate. Check your extensions and scan the computer before trusting it again.
Doesn't two-factor authentication stop this?
Not session theft. Two-factor authentication protects the login; a stolen login cookie is a session that has already passed it. Generating new security keys in wp-config.php signs every session out, and changing the password afterwards — from a clean device — keeps the attacker from signing back in.
Is changing my WordPress password enough?
No. It doesn't end sessions already in use, it doesn't revoke application passwords, and it doesn't touch your hosting, email, registrar or Google accounts. Work through the checklist in order, starting with the device and the email inbox.
Which backup should I restore?
One taken before the break-in — restoring a later one restores the infection. Relvato shows when every integrity check last passed at once ("last known clean") on the site's Security page and in the alert, so you know which window to restore from.
Can Relvato see my browser extensions or my accounts?
No, and neither can any tool running on the server. Relvato checks the site and what its plugin reports from the server. When it sees signs of a hack it shows this checklist, because the way in is often somewhere it can't look.