Securing and running a WordPress publishing estate

The challenge

The publisher runs a large portfolio of WordPress sites on a fleet of Linode servers behind Cloudflare. There was no single, current picture of what each site was running, what was exposed to the public, or what each server cost.

Some sites were already compromised, and old backups and files were sitting where anyone could download them.

What we did

• Audited 33 sites against a written checklist: security headers, exposed files, WordPress hardening, plugin inventory and versions, open ports, and a read-only server review.
• Checked every plugin against vulnerability advisories, then confirmed whether each issue was actually reachable on that site and covered by the firewall. We read in-house plugins line by line, since no advisory database covers them.
• Contained 6 live compromises, 2 of them with zero downtime, and swept the estate for malware.
• Closed ~111 GB of publicly downloadable backups and hardened REST APIs and custom plugins across ~22 sites.
• Right-sized ~63 servers and identified ~$14.5k a year in hosting savings.

Key decisions

• Reachability before severity. A vulnerable plugin version becomes urgent only when the vulnerable code can actually be reached on that site. That kept the fix list short and in the right order.
• Verify from the outside. On sites behind a CDN, a fix isn’t done until the publicly served response confirms it, not just the origin server.
• Read-only first. We ran server reviews without changing anything, so every change went through its own approved step.

What this delivered

The audit gave the publisher a picture of what each of its 33 sites runs, exposes and costs. Fixes were ranked by reachability, ~111 GB of publicly downloadable backups were closed, and right-sizing ~63 servers identified the hosting savings.

Stack

• WordPress
• Linode
• Cloudflare
• nginx
• PHP-FPM
• Wordfence