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.

Loud signs:

• The site redirects to another domain
• Pages show unexpected ads, popups, or another brand's content
• Chrome shows a red "Deceptive site ahead" warning
• Your hosting provider has 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 on your hosting metrics
• Search Console warning about "hacked content" or a 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, the same card across many accounts

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

The first 4 hours

Speed matters. Clean thinking matters more. Do these 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 plus 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 in the secrets manager and roll 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 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 every backup is 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. The 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 the 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 for 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
• A forced password reset for every user

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 California residents exposed	Without unreasonable delay	Most US companies above thresholds
New York SHIELD	Private info of New York residents exposed	Without unreasonable delay	Any business holding New York 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 holding residents' data

The FTC sample data breach response guide has a usable letter template. Keep a copy filed so you are not writing one at 2 a.m.

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 understate. 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 full 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 the document 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 for business owners.

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 work through exactly this scenario through a fractional CTO engagement. The first few hours are the ones that matter most.

The patterns that hold up under pressure tend to be the ones built in from day one. The Instill AI skills platform case study covers a hardened-from-day-one stack — a useful reference for what a fresh build looks like when you are starting from scratch after a breach. 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. The high-stakes work that informs how I think about incident response: bolttech payment integration — 40+ payment providers across a $1B+ unicorn, 99.9% uptime, zero post-launch critical bugs — and the 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, one to two 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 review recent file changes by hand.

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 United States, paying some sanctioned groups is itself a crime. Most ransom-paying victims still do not get full data back. The CISA StopRansomware guide is the right starting point.

What if the hack came through a third-party plugin?

Treat it as a supply-chain incident. Notify the plugin author, document which version was compromised, and check whether other tools share the same vendor. Subscribe to the Patchstack vulnerability database so you hear about the next one before it hits.

Reflecting on what separates a bad week from a bad year

The clients I have helped through breaches all share one pattern in hindsight. They knew, somewhere on a backlog, that something was overdue. The 2FA they meant to roll out. The plugin they meant to retire. The backup they meant to test. None of it was secret. None of it was hard.

A breach is not usually the result of a clever attacker. It is usually the result of a long-standing item that quietly got punted week after week until somebody else found it first. That is the hopeful read of all this — almost everything in the playbook above could have happened on a calmer Tuesday for less money and no public letter.

If you are mid-breach right now and want someone to walk through this with you, reach out. I drop what I am doing for active incidents.