Hacked Website Recovery in 2026: The 48-Hour Playbook

How to know you have been hacked

Some hacks are loud. Most are quiet and expensive. The signs I see on client sites:

Loud signs:

• Your site redirects to another domain
• Pages show unexpected ads, popups, or a different brand's content
• Chrome shows a red "Deceptive site ahead" warning
• Your hosting provider disabled the site
• Customers report malware warnings from their antivirus

Quiet signs:

• New admin users you did not create
• .php or .js files with random names in /wp-content/uploads, /tmp, or your webroot
• Unusual outbound traffic in your hosting metrics
• Search Console warning about "hacked content" or manual action
• Email deliverability suddenly tanks (your server is being used to spam)
• Orders that do not match normal buyer patterns (new carts from TOR exits, same card across many accounts)

If you see any of the quiet signs, assume compromise until proven otherwise.

The first 4 hours

Speed matters, but clean thinking matters more. Do these steps in order.

1. Isolate, do not wipe

Take the site offline behind a holding page. Do not delete files yet. Logs and a messy disk are what let you find the entry point later.

On most hosts: switch DNS to a static "We are down for maintenance" page on a different server, or use Cloudflare's "Under Attack Mode" combined with a single worker serving a maintenance page.

Do not rebuild into the same environment. Assume backdoors exist where you cannot see them.

2. Freeze backups

Tag the most recent backups as "possibly compromised, keep forever." Stop rotating them out. You need evidence.

If you run automated backups that prune old ones, disable pruning now.

3. Capture evidence

Pull these while they still exist:

• Server access logs (Nginx, Apache, or CDN logs)
• Database dump of the current compromised state
• List of all files modified in the last 90 days
• ls -la of your webroot and uploads
• Current list of admin users, API keys, cron jobs, scheduled tasks
• Current git diff if you have a repo

Put the whole snapshot into an off-site, write-once bucket. S3 with object lock, Backblaze with immutability, or a USB drive on a shelf.

4. Rotate every secret

Assume every credential the compromised server touched is leaked. Rotate all of these now:

• Database passwords
• API keys for payment, email, analytics, CRM
• OAuth tokens issued to the server
• SSH keys
• Admin account passwords
• Email passwords if the server sent email
• Cloud provider API keys
• Encryption keys (re-encrypt data if needed)

If you store secrets in environment variables, change them at the secret manager and rotate the downstream apps.

5. Notify your bank and processor early

If you take payments and suspect card data exposure, tell your acquiring bank and processor within hours. Not because the law says so (yet). Because they can fraud-monitor affected accounts, and because being ahead of them looks very different from being behind them if a forensic audit comes.

The next 24 hours: clean restore

6. Spin up a fresh environment

Never restore onto the compromised host. Spin up a new server, new container, or a new Vercel project. Fresh OS image. Fresh database.

7. Pick a known-clean backup

This is the hardest step. You need a backup from before compromise. How to find one:

• Check access logs for the first suspicious file upload or admin login
• Go 7 days before that timestamp
• Verify by running a malware scanner (Wordfence, Sucuri SiteCheck, or ClamAV) against the backup

If all backups are infected, restore from your last known-clean source code (git) and a database dump you can hand-inspect. Any backup from before you linked the domain to the compromised host is typically safe.

8. Restore, then scan

Restore code and data onto the fresh environment with DNS still pointing to the maintenance page. Then:

• Run a full malware scan on the filesystem
• Diff every file against a known-good baseline (git or a previous clean backup)
• Dump the database and grep for suspicious content: <script>, eval(, base64_decode(, document.write
• Inspect all admin users, scheduled tasks, cron jobs, and webhooks

Delete anything suspicious. Keep a record of every delete.

9. Patch the entry point

You cannot flip DNS yet. You have to find how they got in first. Common entry points:

• Outdated plugin or theme with a known CVE
• Compromised admin credentials (often from a reused password)
• Exposed /wp-admin without 2FA
• Leaked API key in a public GitHub repo
• SQL injection on a custom endpoint
• Supply-chain compromise (a plugin you trust got hijacked)

Use your logs from step 3. Look for the first unusual request, then the first successful admin login or file write. That is typically the door.

Patch it on the fresh environment. Update every dependency. Remove plugins you do not use. Force password resets on every admin.

10. Flip DNS when confident

Once you have:

• A clean restore
• A patched entry point
• All secrets rotated
• Admin 2FA enforced
• A full filesystem scan with zero alerts
• Reset passwords for all users (force them to reset, do not store old ones)

Then switch DNS to the new environment. Keep the old compromised environment off the internet, but do not destroy it yet. Forensics may still need it.

The next 24 hours: notify and document

Breaches have legal weight. Ignoring notification law is how a $30K breach becomes a $500K fine.

Who has to tell whom

Law	Trigger	Deadline	Who
GDPR (EU)	Personal data of EU residents exposed	72 hours to data protection authority	Anyone serving EU users
UK GDPR	Same as GDPR, ICO in the UK	72 hours	Anyone serving UK users
California CCPA / CPRA	Personal data of CA residents exposed	Without unreasonable delay	Most US companies above thresholds
New York SHIELD	Private info of NY residents exposed	Without unreasonable delay	Any business with NY resident data
PCI-DSS	Card data exposure suspected	Immediately, per acquirer contract	Any merchant processing cards
HIPAA	PHI exposure	60 days (500+ individuals)	Healthcare covered entities
State laws (all 50)	Varies by state	Varies (30-90 days)	Any business with residents of that state

Use a template so you are not writing from scratch at 2 a.m. The FTC has a sample breach notification letter. Keep a copy filed.

What a good notification says

• What happened, in two sentences
• What data was affected (and what was not)
• When you detected it and when you contained it
• What you are doing for affected users (credit monitoring, free account freeze, etc.)
• How to reach you with questions
• Steps users should take (reset password, watch statements)

Do not speculate. Do not under-state. Regulators forgive imperfect early notice. They do not forgive late notice or cover-ups.

Post-mortem

Write it. Even if you are a one-person team. Include:

• Timeline from first bad request to restoration
• Entry point identified
• What you changed to close it
• What you will do in the next 30 days
• What detection would have caught this sooner

Keep this internal. Share only what your lawyer approves externally.

Prevention after recovery

A clean restore without hardening is a countdown to the next breach. Install these in the 30 days after recovery:

• Admin 2FA everywhere. Hosting, CMS, email, cloud, Git.
• A WAF in front. Cloudflare Pro at $20 per month blocks most repeats. See my WAF vs CDN guide.
• Automated off-site backups. Daily, with weekly and monthly retention. Test restore quarterly.
• Dependency scanner in CI. GitHub Dependabot, Snyk, or Renovate.
• File integrity monitor. Wordfence for WordPress, AIDE or OSSEC for VPS.
• Log shipping. Axiom, Datadog, or CloudWatch so logs survive a compromise.
• SSL + HSTS. See my SSL setup guide.
• Password manager for the team. 1Password or Bitwarden. End reused passwords.
• A written incident plan. Printed. In a binder. Because the laptop password manager is no help when the laptop is locked out.

For the wider view of what "secure by default" looks like for a modern business site, see my website security guide.

WordPress-specific recovery

WordPress gets hit more than any other stack because it is everywhere and has a long plugin tail. Two extra steps help:

1. Reinstall WordPress core from the official zip, overwriting everything except wp-content and wp-config.php. This replaces any modified core files with clean ones.
2. Reinstall every plugin from the official repo. Delete the plugin folder, download fresh, drop it in. Update to the latest version. If a plugin is abandoned (no update in 12+ months), remove it.

Wordfence Central, Sucuri, and Patchstack will scan for leftover backdoors in wp-content after you do this.

When to call a professional

Some signs you are out of your depth:

• You cannot identify the entry point after a day of log review
• The site was hit with ransomware that encrypted files
• Customer card data was clearly exposed
• A regulator is already asking questions
• You are responsible to enterprise customers with a contractual SLA
• The hack involves your internal network, not just the website

In those cases, pause and call. A senior engineer with incident experience will save you days and often money. I have helped clients through exactly this scenario through a fractional CTO engagement; the first few hours are the ones that matter most.

The Instill AI skills platform case study covers the hardening-from-day-one approach I now default to so that a breach of one component cannot take the whole thing down. For scoped project work, see websites (fixed-price from $2,000, 14-day money-back guarantee, 1-year bug warranty) or custom web applications at $3,499/mo. Case studies: bolttech payment integration (40+ payment providers in a $1B+ unicorn) and Cuez API optimization. Related reading: website security for ecommerce and WAF vs CDN.

FAQ

Can I just restore the backup and be done?

No. Backups often contain the backdoor because the attacker was in before your last good backup. You have to patch the entry point and scan the restore before you flip DNS.

How long does a full recovery take?

For a small business site with good backups and a clear entry point: 24–48 hours. For a compromised site with no clean backup and no logs: 1–2 weeks and counting.

Do I have to tell customers?

Usually yes if their personal data was exposed. The law varies by jurisdiction. Assume yes and check with counsel before hitting send.

My host says the site is clean after their scan. Am I safe?

Host scans catch known malware signatures. They miss custom backdoors tailored to your stack. Run an independent scan and do a manual review of recent file changes.

Should I pay the ransom if it is ransomware?

Pay only as a last resort and only after legal counsel and your insurer are in the loop. In the US, paying some sanctioned groups is itself a crime. Most ransom-paying victims still do not get full data back.

Closing

A hacked website is a bad day. It does not have to be a business-ending week. Run the playbook in order: isolate, restore clean, notify, harden. Skip steps and you will see the same attacker again in 90 days.

If you are in the middle of a breach right now and need someone to walk through this with you, reach out. I drop what I am doing for active incidents.