Work / A primary school

Recovering and hardening a school website after a historic compromise

Cleaned a WordPress site of years-old malware remnants, closed the exposure that caused it, modernised the platform and set up safe ongoing maintenance, all on the school's existing shared hosting.

Hardening and securityWebsite maintenanceTechnical consultancy

01 The problem

The school's WordPress site had been compromised with doorway-spam malware years earlier. Scanners had neutralised the backdoors, but thousands of infected files, a loader hook in the core configuration, publicly downloadable backups including a full database dump, and an obsolete PHP version were all still in place. A new security plugin's first scan produced an alarming report nobody could interpret.

02 What we built

A forensic clean-up over SSH: around 6,900 malware files quarantined, verified against the database and purged. The configuration hook was removed and secrets regenerated. Leaked backups and two abandoned installs were taken off the public web. Database credentials and hosting passwords were rotated, PHP moved from an end-of-life version to a current one, and an unused page-builder stack was stripped out. The site then gained a memory headroom fix, a safe update procedure and a monitoring routine.

03 The result

Security scans clean with zero malware. The site runs on current PHP with proper secrets, no public backups and a smaller attack surface. Teachers were onboarded to new editing roles without incident. When a critical PHP vulnerability was disclosed later in the year, the site was assessed, found unexposed and confirmed patched by the host within a day.

A busy primary school’s website is run by a staff volunteer and a co-admin, on shared hosting, with no IT department behind it. That is the normal case, not the exception, and it is where most hardening work is actually needed.

Finding what was really there. The security plugin’s report mixed historical remnants with real exposure. We went in over SSH and enumerated the actual state: a loader hook still wired into the core configuration file, about 6,900 malicious files, an eleven-gigabyte development archive and a database dump sitting in a public folder, two abandoned installs, and a backup directory with no access rule, meaning every future export would have been downloadable.

Cleaning without breaking. Files were quarantined rather than deleted, the database was checked for any reference to them, and only then were they purged. Fresh clean backups were taken before and after. Secrets were regenerated, the database password rotated, and the hosting account’s contact and access details tidied.

Modernising the platform. PHP went from 7.4 to 8.3 through the hosting’s handler configuration, which the control panel did not expose. A page-builder stack the site no longer used was removed along with thousands of orphaned records, leaving a smaller, faster, native-editor site. Inactive plugins and themes went too.

Maintenance that fits the people. Bulk plugin updates from the admin screen had been crashing the site on the host’s memory limit, so the limit was raised and updates now run over the command line. When sixteen teachers were given editing roles for new class pages, the site held. An incident in the autumn was traced to the host’s resource throttling rather than the site itself, and a critical PHP vulnerability disclosed weeks later was assessed the same day.

What the school got. A clean site, a documented account of what was there and what was done, and a short list of routine tasks that keep it that way.

More work

All work →

Discuss a similar project.

Tell us what you are facing. The first conversation is free.

Start a conversation