Someone's WordPress got hacked. We got it back.

Anonymised case study: four hours from infection to clean restore, zero customer data exposed. The unglamorous monthly stack at work.

Talk to us

What we actually did

The Digital Care plan had been in place for two years before the incident — daily off-site backups, daily plugin updates, uptime monitoring. None of that is heroic; it's the unglamorous monthly stack at work. What follows is what the retainer actually bought on the one day it mattered most.

  • Detection

    Daily backup integrity checks flagged unexpected file changes inside wp-content/uploads within 24 hours of the compromise. No customer-facing symptoms yet — the malware was staging, not yet exfiltrating. Monitoring caught it before anyone outside the team noticed.

  • Isolation

    Site was taken offline within 20 minutes of confirmation; a static holding page replaced it. The compromised state was preserved on a forensics snapshot before any cleanup ran. Short outage now beats long incident later — that was the call, and the client backed it.

  • Restoration

    Rolled back to the last clean off-site backup (72 hours pre-compromise), then replayed legitimate content changes manually from the forensics snapshot. Clean state verified by file-hash comparison. Total: under four hours from detection to a fully restored site.

  • Vector analysis

    A known CVE in a third-party plugin that had not been updated by the previous developer before our care plan started. The CVE had been public for four months; an automated scanner almost certainly found the site rather than a targeted attacker. Boring vector, boring fix.

  • Hardening

    Removed three plugins that duplicated core functionality; enforced 2FA on all admin accounts; rotated database credentials and salts; added a file-integrity monitor to the daily checks. Nothing exotic — just the changes we'd recommend anywhere, now mandatory here.

  • Disclosure

    Worked with the client on their disclosure timeline to downstream partners; their schedule, not ours. That's why this write-up is anonymised — the technical details aren't sensitive, but the disclosure window with their partner network is still active. We'll name them later.

Outcomes

Under 4 hours

Full restoration

Zero

Customer data exposed

5 years

Client retention since

Common questions about the recovery

How was the attack detected?
Daily backup integrity checks and uptime monitoring flagged unexpected file changes inside the WordPress uploads directory within 24 hours of the compromise. No customer-facing symptoms had appeared yet — the malware was still staging. Monitoring caught it before anyone outside the team noticed anything was wrong.
What was the attack vector?
A known CVE in a third-party plugin that the previous developer had not updated before our Digital Care plan took over. The vulnerability had been publicly disclosed for four months. We have anonymised the specific plugin while the client's disclosure window with downstream partners remains open.
Why is this case study anonymised?
At the client's request. Their disclosure timeline with downstream partners is still active, and we are following their schedule rather than ours. The technical details here are not sensitive; the client identity is. We will name them in a future revision once their window closes.
Could you have prevented this?
Probably, yes — the vulnerable plugin had a publicly disclosed CVE for four months before the breach. If the previous developer had patched on the standard 48-hour cycle, the site would not have been exposed. The lesson is not "buy more security software." The lesson is "have someone watching."
What changed afterwards?
Site Care, Digital Care and Operational Care plans now include an explicit 48-hour CVE response window for known WordPress and plugin vulnerabilities. We also added a file-integrity monitor to the daily checks for this client. Both changes rolled out across all care-plan clients in early 2026.
How long was the site offline?
Roughly four hours from detection to a verified clean restoration. The client then chose to delay public reopening by another six hours as a precaution while they notified their partners — that was their call, not a technical constraint. Technically, the site was production-ready inside the four-hour window.

None of this was heroic. The backups, the monitoring, the "no admin login without 2FA" rule — those were already in place because they are what the monthly retainer pays for. The client has been with us for five years and counting; this incident is one day inside that relationship. The four-hour deadline came from the client's disclosure constraints, not from any technical limit on our end — clean state was verified before lunch. This is what Digital Care promises, written down once it actually happened.

Want this capability built into your care plan? See WordPress Care plans →

Want this kind of response on your stack?

Talk to us