Stopped a theater’s hack-and-recover cycle, then rebuilt their site on hardened infrastructure.

A regional performing arts venue came to us in a hard spot. Their WordPress website had been compromised multiple times over a short period. Each time, their previous developer cleaned up the visible damage, but the same entry points were getting exploited again within weeks. The site was effectively in a loss spiral: every hack damaged trust with visitors during ticket-buying season, every recovery cost more in emergency hours, and the underlying vulnerabilities kept getting wider as more plugins fell behind on patches.

By the time they reached out, the cycle had been running long enough that they weren’t sure the site could be saved. The question on the table was whether there was a third option between “keep limping along through more compromises” and “scorched earth, abandon the existing site, start over from nothing.”

The situation.

The site was running on standard shared hosting with no real security layer, an aging WordPress installation, and a stack of plugins that had grown over years of patches and feature additions. Several of the plugins were known to have published CVEs that had never been addressed. The malicious code was finding any of half a dozen entry points and re-installing itself within days of cleanup.

This pattern is not unusual for sites that have been operating for years without an active security posture. Most WordPress compromises in the wild aren’t sophisticated zero-day attacks against WordPress core. They’re automated exploitation of known vulnerabilities in outdated plugins, weak login surfaces left unprotected, and uploaded files that get executed when the file system permissions aren’t locked down. The published CVEs and exploit kits give attackers a paint-by-numbers playbook against any site that hasn’t kept its component versions current and hasn’t hardened the surface area beyond WordPress defaults.

The theater’s operational priority was clear: stop the bleeding immediately, then rebuild on something that wouldn’t have this problem again. The site was central to ticket sales for a full performance season, so a multi-week outage wasn’t an option. The schedule pressure shaped the entire engagement: we couldn’t take the site down to fix it, and we couldn’t keep watching it get re-compromised every few weeks while we worked on a long-term solution.

How the breach cycle perpetuates itself.

When a site gets compromised and the recovery is just file-cleanup-and-password-rotation, the underlying conditions that allowed the compromise are still there the morning after. The same outdated plugins. The same exposed login surface. The same file system that lets uploaded files execute. The attacker (or the automated exploit kit running against millions of WordPress sites at any moment) doesn’t even need to find a new way in. The existing entry points are still open.

The “developer cleans it up, gets paid for emergency work, hack returns” cycle isn’t necessarily a sign that the developer is bad. It’s a sign that the work being paid for is reactive rather than structural. Cleaning up evidence of a compromise is dramatically less expensive than the architectural work of closing the vectors that let the compromise happen, but cleaning is the only thing that pays back hour-for-hour. That’s what gets done when there’s no budget or appetite for the bigger fix.

What we did first.

We started with triage and containment, not a rebuild. The site moved onto our secure managed hosting with hardened infrastructure: edge-layer WAF blocking known malicious traffic before it reached WordPress, brute-force protection on login, server-level malware scanning that catches suspicious activity before it spreads, and continuous patching of core, themes, and maintained plugins so newly-published CVEs don’t sit open for weeks.

We then did a vulnerability audit on the existing installation. Plugins with active known exploits got replaced, removed, or updated. Compromised admin accounts got rotated to strong unique passwords with two-factor authentication. The malicious code was removed and the file system was locked down so even an authenticated admin couldn’t write to system directories where the malware kept reinstalling itself. The audit also documented every plugin’s role and currency status, which gave the theater’s team, for the first time, a clear picture of what was actually running on their site.

The goal at this phase wasn’t to make the old site beautiful or modern. It was to stop the breach cycle long enough that we could build a real replacement without ransom-style pressure. Every architectural decision in the rebuild benefits from being made in a calm room rather than an emergency call.

The result of the holding phase.

The site stayed exploit-free for 8 months on hardened infrastructure with no further compromises. The theater’s operations team stopped getting emergency calls. The visitor-facing experience stayed online through the ticket-buying cycle. The same plugins, the same code, the same general site, but inside a hardened envelope that closed off the vectors the attackers had been using to reinstall themselves.

This is the part of the story most people don’t expect: dramatic security improvement is more often a matter of changing the environment a site runs in than rewriting the site itself. A vulnerable WordPress installation on hardened infrastructure performs dramatically better than a vulnerable WordPress installation on commodity shared hosting. The vulnerabilities are still there; the exploit paths are not.

What we built in parallel.

While the existing site was running clean on hardened hosting, we built the replacement: a fully custom WordPress platform designed around how the theater actually operates. The new site shipped with the security architecture built in from day one, not bolted on after a compromise. Defense-in-depth at every layer: edge protection, WordPress-level hardening, file system lockdown, monitoring that catches anomalies in minutes, and a backup strategy that survives a future compromise if one ever happens.

The rebuild also addressed the original problem that had let plugin sprawl accumulate in the first place. Many of the plugins on the old site existed because the original codebase couldn’t natively do what they did. The new platform absorbed those capabilities into custom code that we control and patch, rather than depending on a long tail of third-party plugins to deliver them. Fewer third-party components mean less surface area for future compromises. A platform that ships clean stays clean for longer because there’s less of it to keep clean.

The long-term operational shift.

The bigger change for the theater was operational, not just technical. They moved from a posture where every site change carried a risk of breaking something or exposing a vulnerability, to one where the underlying infrastructure handles the security work continuously in the background. Their team can publish content, run ticket-sales campaigns, and update show information without thinking about whether they’re about to trigger another security incident.

That shift in operational confidence is hard to put a dollar value on, but it’s the real outcome. The dollar value of “8 months exploit-free” is straightforward: no emergency cleanup hours, no lost ticket-sale windows, no reputational damage. The dollar value of “the team stopped fearing their own site” is harder to measure and ultimately more important.

What this case study illustrates.

The “we keep getting hacked and our developer can’t stop it” pattern is one of the most common reasons people come to us. The answer is almost never a single fix; it’s a combination of secure infrastructure, vulnerability auditing, and a real long-term security posture. The right hosting layer is part of the answer, not the whole answer. The right rebuild approach is to do the security architecture upfront so it’s not retrofitted later. And the right pacing is to stabilize first, then improve, not the reverse.