Check for the traces attackers usually leave: PHP files in the uploads folder, core or plugin files that differ from the official release, administrator accounts or SSH keys you didn't create, new scheduled tasks, and PHP starting shell commands. Clean results don't prove a site is safe, but any hit means you should isolate the site, keep the logs and rotate secrets before cleaning up.
This guide covers check 01: Authentication and access control; check 08: Observability and deployment in the Zenveus Production Readiness Standard.
For builders
When someone breaks into a WordPress site, they usually leave something behind so they can get back in: a hidden PHP file, a changed core file, an extra admin account or a scheduled task. These checks look for those traces. If you find one, stop the site from being used, save the logs, and rebuild from clean copies rather than trying to patch the infected files.
A scoped repair request
Use this prompt in Lovable, Cursor, Replit, or Claude Code with the relevant server files available.
Help me check my WordPress server for signs of compromise without changing anything yet. Give me read-only commands to verify core and plugin checksums, list PHP files in wp-content/uploads, find PHP and .htaccess files changed in the last 21 days outside the cache, list administrator accounts with registration dates, and list WordPress cron events. Explain what each result would mean. Do not delete, edit or execute any suspicious file.The same failure may appear as
Find the failure layer
Each check removes a class of causes. Keep the first failing result, its timestamp, and the production log beside it.
WP-CLI compares your WordPress core and wordpress.org plugin files with the official releases. Premium plugins and themes aren't covered, so compare those against a fresh download.
wp core verify-checksums
wp plugin verify-checksums --allThe uploads folder should hold media, not code. List PHP files there, then search recent PHP files for patterns common in web shells.
find wp-content/uploads -type f -iname '*.php*'
grep -rlE 'eval\s*\((base64_decode|gzinflate|str_rot13)|\$_(POST|REQUEST)\[' wp-content --include='*.php'List administrators with their registration dates, and check the server's authorized SSH keys and any hosting-panel users.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredList PHP and .htaccess files changed in the last few weeks and compare them with deploys and updates you know about. Review WordPress cron events and the server crontab.
find . -type f \( -name '*.php' -o -name '.htaccess' \) -newermt "$(date -d '-21 days' +%F)" -not -path './wp-content/cache/*'
wp cron event listRanked diagnosis
A known vulnerability in a plugin, theme or PHP itself lets an attacker write files without logging in.
An admin, hosting-panel or SFTP password was reused, phished or never changed from a default.
A form or plugin accepts a file that the server later executes as PHP.
Old plugins, test scripts or backups left in the web root give attackers an extra way in.
Step-by-step repair
Work over SSH with WP-CLI in the site root. Take a full file and database copy for evidence before you change anything.
Production safety ruleNever disable access controls, expose service keys, or add wildcard CORS as a routine shortcut.
Put the site in maintenance mode or behind an IP allowlist, and copy the web server, PHP and WordPress logs before they rotate. Cleaning first destroys the evidence of how they got in.
Reinstall WordPress core and every plugin and theme from official downloads instead of editing infected files. Remove anything you can't match to a source.
Change admin, database, hosting, SFTP and API credentials, generate new WordPress salts, and remove unknown users and SSH keys.
Update the vulnerable component or PHP version, and block PHP execution in the uploads folder.
Implementation example
# wp-content/uploads/.htaccess
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>This blocks direct execution of uploaded code; it does not remove a backdoor that already exists elsewhere. On Nginx, add a location block for the uploads path that denies .php.
Prove the repair
Run these checks with synthetic data in your test environment, then repeat the relevant acceptance checks after deployment.
When the built-in AI fix makes it worse
Pause generated changes, restore a known working branch, and capture one failing request with its logs. Change one layer and rerun the allowed and denied checks before proceeding.
Engineering handoff
We trace one production request through the complete path, isolate the failing boundary, and leave behind evidence your team can repeat.
Which vulnerability or credential let the attacker in, and when.
Backdoor files, users, keys, cron jobs and database changes.
What the attacker could read or change, for notification decisions.
Known-good code, rotated secrets and the controls that keep it closed.
Typical repair pattern
Checksums pass, uploads hold no code, every credential is new, and the component that let the attacker in is patched or removed.
Before the next release
Clear answers
Not necessarily. Checksums only cover WordPress core and wordpress.org plugins. Attackers also hide code in uploads, themes, premium plugins, the database and cron, so run the other checks too.
Copy them and the logs first. Deleting a backdoor without finding how it arrived usually means it comes back.
It depends on what data the site held and where your users are. If personal data may have been accessed, get advice on your notification duties promptly; some laws set short deadlines.
Run the verification checks on this page after cleanup, then repeat them a week later. A returning file or user means the entry point is still open.
Related symptoms
Official documentation and library references
Free next step
The free tool helps you inspect this symptom. Its result does not establish whether the whole app is production ready.
Take it further
This fix solves one symptom. A guided self-assessment walks you through the rest of the app, one session at a time, and ends with a report and a ranked fix list you can act on or hand to a developer.
Every fix breaks something else? Freeze what works, trace bugs to a few root causes, add guardrails and leave with a ranked plan.
See the sprint Preparing to launch · $997-Day Launch Readiness SprintTest the running system against the nine-area Production Readiness Standard and reach a Ready, Conditional release or Hold decision with a ranked fix list.
See the sprintPlanning more than one stage? Founder Bundles combine the guided products from $149 and save up to $405.
The Verdict
We can see the symptom from here. What we cannot tell you from outside is whether it is contained or structural. A scanner collects evidence. A named senior engineer makes the decision. For $299, a named senior engineer reads your code and signs a written Verdict against the nine checks in the Zenveus Production Readiness Standard. The 48-hour clock begins when the required access and context are available. If the report does not give your developer a list they can act on, you do not pay.
The 48-hour clock starts when the required access and context are available.
If each fix breaks something else, you probably have a few root causes, not dozens of bugs. Find out where you stand.
Free. No email needed. Close this and we won’t show it again during this visit.