# My WordPress site was hacked — what to do in the first hour | RootCore LLC > Incident handling step by step — what to do immediately, what never to do, how to find how they got in, and how to restore so it does not happen again. Page: https://cyber-security.rootcr.com/en/knowledge/hacked-wordpress/ Updated: 2026-08-20 --- # My WordPress site was hacked — what to do in the first hour? > **In short:** Do not delete anything, and do not restore from backup straight away. First contain the site, preserve the evidence, then work out how they got in — because if you skip that, the restored site gets broken into again within days by the same route. The right order: contain, preserve, find the cause, clean, rotate credentials, and only then go live again. ## First: what NOT to do These three steps are how most people ruin their own recovery. 1. **Do not delete the suspicious files immediately.** They are the evidence. Once they are gone, you will never learn how the attacker got in — and you cannot stop it happening again. 2. **Do not restore from backup right away.** If the backup is already infected (and it usually is, because the break-in happened weeks earlier), you are restoring the back door. And if it is clean but the entry route is still open, they simply come back the same way. 3. **Do not conclude that “it was just one file”.** The vast majority of WordPress compromises spread: plugin directory, uploads folder, `wp-config.php`, the database, scheduled tasks, admin users. ## The first hour, in order ### 1. Contain (minutes 0–5) The goal is that visitors stop receiving malicious content and the attacker cannot keep working, while the evidence survives. - Put the site into maintenance mode, or set the web server to serve a static message. - Do not shut the server down entirely if you can avoid it: anything in memory is lost. - Lock the admin interface down by IP. ### 2. Preserve (minutes 5–20) Before touching anything, take a snapshot: - A full copy of the file system, timestamps included (`rsync -a`, or a snapshot at the hosting provider). - A database dump. - The web server logs, covering at least the weeks before the suspected break-in. - The current process list, scheduled tasks and admin users. That copy is your only chance to reconstruct what happened later. ### 3. Find the way in (minutes 20–45) Four places to look, in this order: | Where | What to look for | What it indicates | |---|---|---| | File modification times | Anything changed after the last update, especially under `wp-content/uploads` | An uploaded web shell | | Web server logs | POST requests to unknown PHP files, repeated `wp-login.php` hits | The route and the timing | | Database | Unknown admin users, modified `siteurl`, suspicious content in posts | Persistence | | Scheduled tasks | Unknown `wp-cron` entries or system-level cron jobs | A way back in | The usual causes, in order: an outdated plugin with a known vulnerability, a weak or reused admin password, an outdated PHP or WordPress version, or another site on the same hosting account (on most shared hosting the accounts can reach each other). ### 4. Close the access (minutes 45–60) Once you know the route — or if time is pressing: - Rotate every admin password, the FTP/SFTP password, the database password and the hosting account password. - Delete unknown admin users. - Generate fresh security keys in `wp-config.php` (`AUTH_KEY` and friends) — this invalidates every logged-in session, including the attacker's. - Review API keys and webhook secrets: if `wp-config.php` leaked, so did they. ## The recovery After containment comes the slower part. Here the clock no longer matters; being thorough does. 1. **A clean base.** Reinstall the WordPress core and every plugin from the official source rather than patching the existing files. Anything from an unofficial source (cracked premium themes, “nulled” plugins) goes. 2. **Your own content, reviewed.** The uploads directory should contain media only; a PHP file has no business being there. 3. **Database clean-up.** Injected scripts in posts, suspicious `option` values, foreign users. 4. **Updates.** WordPress, plugins, theme, PHP version. 5. **Hardening** so it does not repeat: disable file editing in the admin, block PHP execution in the uploads directory, two-factor authentication on admin accounts, [a WAF in front of login and `wp-admin`](/en/waf-configuration/), automatic security updates. 6. **Blacklist check.** If Google flagged the site, you have to request a review after cleaning, otherwise the warning stays in search results. ## When do you have to report it? If personal data was affected — and for a shop or a site with forms it usually is — the GDPR requires the breach to be reported to the supervisory authority within **72 hours** of becoming aware of it, unless it is unlikely to result in a risk. If the risk to individuals is high, they have to be informed too. For the precise assessment it is worth taking legal advice — but the 72-hour clock starts at discovery, not at the end of the recovery. This is another reason step 2 matters: when reporting, you have to be able to say what happened, when, and which data was involved. Without logs, that is not possible. ## How do you know it is actually clean? Not because “the symptom is gone”. The practical measures: - There is no executable file on disk that did not come from the official installation. - The admin user list matches what you expect. - The logs show no further suspicious requests since the break-in. - An external assessment finds no back door. - And most importantly: **you can name how they got in**, and that route is closed. If you cannot answer the last point, the recovery is not finished — the symptom just disappeared. ## Frequently asked questions ### My hosting provider says this is not their job. Are they right? Usually yes. Hosting covers the infrastructure; what runs on the site — WordPress, plugins, passwords — is yours. With managed WordPress there can be overlap, but the contract decides what they take on. ### Is installing a security plugin enough? Not on a compromised site. The security plugin runs inside the system the attacker already controls — it can be disabled or bypassed. A plugin makes sense **after** the clean-up, as prevention. ### How long does all this take? A simple case (one vulnerable plugin, caught early) is half a day. A hosting account infected for months and running several sites takes several days. The longest part is always finding the way in — and that is exactly the part that must not be skipped. ### Can I restore from backup without knowing how they got in? You can, but it will most likely be compromised again, because the vulnerability is still there. If you must go live quickly, close the most likely routes at the same time: rotate every password, apply every update, restrict `wp-admin` by IP, and block PHP execution in the uploads directory. ### Is an external assessment worth it afterwards? Yes, because most back doors are not visible on the site. A [vulnerability assessment](/en/penetration-testing/) after the clean-up tells you whether anything is still open — and it is the only way to stop merely hoping it is over. --- If it is happening right now and you would rather not do it alone: [write to us](/en/#kapcsolat) — the first assessment is free, and within the first hour we can at least tell you what not to do.