devautomation

Posted on May 21

I inherited a WordPress site that had not been updated in 2 years. Here is what I found.

#wordpress #security #webdev #discuss

A client referred me a new project last year. Restaurant website, 50-60 pages of content, WooCommerce for gift cards and table bookings.

"How long has it been since the last update?" I asked.

The owner shrugged. "The developer who built it moved away two years ago. I've just been leaving it alone."

Here's what I found when I got access.

The audit

WordPress core: 2 major versions behind. Security patches from the past 14 months: not applied.

Plugins: 34 installed. 31 with available updates. 8 hadn't been updated in over 18 months (effectively abandoned). WooCommerce: 2 major versions behind.

Backups: None. Not a degraded backup system. None. The previous developer had installed a backup plugin during the build, but it was configured to back up to a folder on the same server -- and that folder was empty.

PHP: 7.4 -- EOL since December 2022. No longer receiving security updates.

Admin users: 4 accounts. One was "admin" with no email address. One was the previous developer's personal email. The restaurant owner had one account; he didn't know who the other two belonged to.

SSL certificate: Valid. (The one thing that was fine.)

Debug mode: Enabled. In production. Logging to a publicly accessible wp-content/debug.log file that contained 18 months of database credentials, API keys, and internal paths.

I stopped the audit and called the client.

The call

"Your site has been publicly exposing sensitive data for at least 18 months. There's a file anyone can read that contains your database credentials and payment gateway API keys."

Silence.

"I need to take it offline for a few hours while I secure it."

More silence. Then: "Is my customer data safe?"

I didn't know. That was the honest answer. The database credentials had been exposed. Whether anyone had found the log file and used them was unknowable without a full forensic audit.

The fix

Four hours of work:

Took the site offline
Changed all credentials (database, WP admin, hosting, payment gateway API keys)
Deleted the debug.log file, disabled debug mode
Removed unknown admin accounts, renamed "admin" to something harder to guess
Deleted 8 abandoned plugins (6 of which had known security vulnerabilities in their current versions)
Updated everything: core, all remaining plugins, PHP version
Set up real off-server backups (cloud storage, daily, 30-day retention)
Brought it back online
Verified WooCommerce checkout still worked

The site had been processing real payments through a payment gateway whose API keys were sitting in a publicly readable file.

What the previous developer did wrong

Nothing unusual, actually. This is standard setup for someone who built a site and walked away:

Debug mode gets enabled during development, forgotten in production
Backup plugin gets installed, not properly configured, never tested
No offboarding process ("just leave the admin credentials, they'll figure it out")
No documentation of who has access and why

None of this was malicious. It was just -- the handoff didn't happen. The site was abandoned, not handed off.

What I now do differently for every client

Before agreeing to maintain a site, I do a 30-40 minute audit. Not to find problems (though I do), but to know what I'm agreeing to be responsible for.

The audit checklist I use is in:
WordPress Monthly Maintenance Checklist -- free download, includes the security section.

For the service agreement that defines exactly what I'm and am not responsible for when I take over a site like this:
WordPress Agency Starter Kit -- use code DEVTO.

The honest coda

I never found out if the debug.log was exploited. The client didn't pursue a forensic audit (cost vs. benefit for a small restaurant). The payment gateway showed no unauthorized transactions in the window we could check.

The restaurant owner is now a monthly maintenance client. He pays for the service he was missing for two years -- the thing that would have prevented all of this.

The first conversation we had about maintenance: "I don't really need that, the site just runs itself."

The conversation after: "How do I make sure this never happens again?"

Free checklists and paid toolkits: devautomation.gumroad.com

Have you inherited a site like this? What did you find?

DEV Community