Guides
Something is wrong with the site, or you want to keep it that way
Most WordPress security advice stops at "run a scan". These pages start where that leaves you. Work out which infection you have from what you can actually see, take it out by hand, put back whatever a cleanup already broke, and set up the defences that stop the next one. Each one is a procedure you can finish with a file manager and a text editor.
When the cleanup went wrong
A scanner removed something and the site stopped working, or the malware came back. These pages get you to a working site.
- The malware cleanup broke my site
Read the fatal error, work out whether the file was removed, emptied or rewritten, and put that one file back.
- Restore modified core, plugin and theme files
Where the pristine copy of each file class comes from, which files you must never overwrite, and how to check the result.
- Is this a real detection or a false positive?
Three checks that settle whether a flagged file is infected, and what to do when they still leave you unsure.
- A security plugin deleted or quarantined my files
Where each of the common plugins puts what it removes, how long it keeps it, and how to get the file back.
- The malware came back after the cleanup
Reinfection means the entry point stayed open. Find it, close it, and only then clean the site again.
- Cleaning a file that has no clean copy anywhere
Custom theme code and wp-config.php have no pristine version to download. Cut the injection out by hand instead.
Working out what you have
You can see the symptom and not the cause. Each page takes one named infection, shows you where it hides, and gets it out by hand.
- Japanese text is showing in your Google results
Google indexed pages you never wrote. Find the cloaked sitemap, the injected file behind it, and the account that keeps letting it back in.
- Pharmacy spam in your pages and search results
The spam is served to crawlers and hidden from you. Reproduce it in one command, then find the payload in files or in the options table.
- Your site redirects visitors to somewhere else
Five layers can be doing it and the fix differs in each. Narrow it to one in about ten minutes before you edit a single file.
- wp-vcd, the nulled theme backdoor
Named files, a fixed install pattern and a copy in every theme you have. Remove it in the right order or it rebuilds itself.
- Reading eval and base64_decode in a PHP file
Decode an injected block without running it, tell it apart from packed but honest code, and cut it out leaving the file working.
- PHP files turned up in wp-content/uploads
A handful belong there. Everything else is a shell or a dropper. Find them, confirm what they are, and stop the directory executing PHP.
- Rewrite rules injected into .htaccess
Read every .htaccess on the site, tell the WordPress block from the injected one, and stop the file being rewritten an hour later.
- An administrator account you did not create
The account is the symptom. Find the ones the user list hides, remove them without losing content, and find the file that made them.
- A cryptominer is running on your site
Two different infections wear this symptom. One burns your visitors' CPU, one burns your host's. Tell them apart, then remove.
- A plugin that is itself the backdoor
No vulnerability to patch, because nothing is broken. Recognise the plugin, check whether it is hidden from your list, and remove it.
Closing the doors
Nothing is broken yet and you want it to stay that way. Each page sets up one defence by hand first, then shows the toggle that does the same job.
- Turn on two-factor authentication
WordPress ships no second factor. Set one up, enforce it by role without locking the team out, and get back in when the phone is gone.
- Stop the attacks on wp-login.php
Read the attack in your access log, rate-limit the three doors WordPress leaves open, and know which layer your block actually runs in.
- Block a country, without locking yourself out
What country blocking really measures, where it is wrong, and how to switch it on without ending up on the other side of the door.
- Add the security headers, including a CSP
Ten headers, what each one stops, and how to read them back. Then the one that breaks sites, and the mode that lets you test it safely.
- Hide the WordPress version, and what that is worth
Every place your version leaks and how to close each one. Also the honest part: what an attacker still knows afterwards.
- Check core, plugin and theme files against upstream
Run the checksum tools, read what they say, and learn the two silences that look like a pass and are not one.
- Write IP and CIDR firewall rules
Find the range in your log, block it at the right layer, and get your proxy list right so a rule does not block everyone or nobody.
Doing this the slow way once is enough
Two things make these pages long. Finding every copy of the injected code, and then getting it out of a file the site still needs. The reason a cleanup breaks a site is the second one: a few lines were injected into a working file, and the tool that found them removed or blanked the whole file instead of the lines. Segurium takes the injected code out and leaves the file working, so there is nothing to restore afterwards. It is free for three files every 30 days, and the hardening settings in the last group above are free on every install.
Install the free plugin from WordPress.org
No card, no trial clock. Uninstall takes one click if it is not for you.