The WordPress security incident that changed how we build sites

We found out a client's site had been compromised when they called to tell us Google was showing a warning to visitors. The browser was displaying "This site may harm your computer." That is not a notification you want to receive on a Thursday afternoon.

The site was a services business, nothing that you would think of as a high-value target. But most WordPress compromises are not targeted attacks. They are automated. Bots scanning for known vulnerabilities in outdated plugins, then injecting code once they find one. This client had been running an SEO plugin that had not been updated in eight months. That was the door.

What the compromise looked like

The injected code was a redirect. Mobile visitors were being sent to a pharmaceutical spam site. Desktop visitors saw the normal site. This is why the client did not know for three weeks -- they were testing on a laptop.

The malware also created a hidden admin user and left a backdoor file in the uploads directory. Removing the malware without finding and closing all the entry points means you are cleaning up for a few days before the attacker just comes back in.

We cleaned the site. We changed all credentials. We removed the backdoor files. We updated everything. Then we spent two weeks building a security checklist we should have had from the beginning.

What is on the checklist now

Every site we deploy now ships with a few non-negotiable defaults. The WordPress admin login URL is changed from the default /wp-admin path. File editing from the WordPress dashboard is disabled. The uploads directory is configured to not execute PHP files.

We run plugin and theme updates on a weekly schedule. Plugins that have not been updated by their developers in over six months go on a watch list and get replaced if a better-maintained alternative exists.

We added a WAF in front of all client sites. Not expensive, but effective at filtering the automated scanning traffic before it reaches WordPress.

The honest version of this is that most of these protections are not complicated. We knew about them. We just had not made them default. One incident was enough to change that.