Level-headed AI

PHP2Shell - Fixing legacy WordPress websites with AI

24 October 2026 · Case studies · 6 min read

A PHP vulnerability is never something you want to see. People say it powers something like 70% of the internet. At our company it powers almost 100% of our clients' sites and every single web server runs it. A colleague first mentioned it when she read it on a cyber security forum. I rolled my eyes thinking that it was just another minor issue but she read on and said it was a CVSS 9.2. I'd never heard of PHP having that kind of severity in a security vulnerability - it's usually a theme or plugin, not PHP itself.

PHP2Shell

I did some digging and realised it wasn't going to be an easy patch for some of our sites. The PHP developers were realistically only going to release complete patches for supported versions like version 8.3, 8.4 and 8.5. Some sites still ran on PHP 7.4 which hadn't been supported in years. We offer security maintenance, but those clients had opted out to look after the updates themselves. I had tried to update the sites in the past but was met by the WordPress fatal error box when loading the home page. I always switched back to 7.4 and thought there's no way there would be anything severe enough in PHP to cause much of a problem.

On Wednesday at 14:00 UTC (15:00 my time) we received the patch. We run Plesk so I noticed at about 16:00 that the patch had been released via the Plesk updater. I updated all the PHP 8.3, 8.4 and 8.5 installs to their respective latest versions. Some of our clients are on retainers where we run WordPress updates for them, so luckily we had already updated almost all of those sites to PHP 8.5.

I didn't decide to update the 7.4 sites there and then. I knew this was bad but I didn't think hackers would manage to get bots out in time to get into our clients' sites. I actually waited until 8pm in the evening when I was reading more about the vulnerability and that some government websites, among loads of others, had also been taken down. That's when I saw it on the breaking news section on BBC news. I was shocked to see it right at the top on such a mainstream news website. I then realised this was huge and our company had work to do. Those sites weren't part of our security maintenance, but we took it upon ourselves to get them secured.

I ran through every site - 30 of them were still on 7.4 and 2 of them on 5.6 - and updated them to 8.5.12, knowing some of them would show the fatal error but not caring because I knew they'd be safe. I wasn't that shocked when the fatal errors popped up. 14 of the 32 sites I updated were showing the error. I left the errors showing (just the WordPress error box, not the actual PHP error!) for those sites until the morning when I started emailing clients with a plan to get them all fixed.

Thursday morning

First thing on Thursday, I sent out a bulk email to all clients reassuring them that we'd updated the servers and that the vulnerability was patched. The email mentioned that some sites were down and that they'd receive another email with info on what we could do to fix the problem with their broken site and how much it would cost. My recommendation was to update the plugins and themes, and I asked them what they wanted to do.

Most clients emailed back during the day and I started to determine what was causing the fatal errors on each site. Some errors were clearly plugins. Reading the error log and having it point to a plugin was a blessing. I had a collection of updated plugins ready to be swapped out, the usual culprits like Slider Revolution and WPBakery Page Builder, both of which usually break when PHP is updated and were heavily used when we built sites 5 years ago so most of the sites from that time have one or both of these installed. These are an easy fix, just update and hope the sliders still look roughly like they used to.

The theme problem

Looking through the errors closely, 10 of the websites pointed to the theme being the problem. The issue is that none of those themes had been updated in years, some of them were 10 years old or more, and swapping out the theme with a newer one would be a costly and time-consuming job. We'd usually charge a decent chunk of time for a theme swap and redesign for a modest size website. We needed a way of fixing the themes quickly while not altering any styling or functionality.

We'd recently started using Claude Code for developing some in-house tools. I never thought to unleash Claude on a WordPress website before but I thought now was the time to test it out. I downloaded a copy of one of the broken themes and asked Claude to have a look, I was going to give it the error log but it spotted the issue itself after I asked "What would be an issue in this theme if we updated to PHP 8.5". It claimed it fixed it and asked me to re-upload to the server. I did and was pleasantly shocked to see it had fixed the error.

I did have to give Claude the stack trace of the error a few times to help it out, but it eventually fixed each one in less than 10 minutes. The emails and file handling now seemed to take longer than the actual work to fix the problem.

Our clients were happy - their sites were up and we billed what looked like a small amount to fix a large issue in a short amount of time. I was happy - I'd spent a fraction of the time I'd expected fixing these sites.

Keeping up with updates

I was blind to using AI to help with WordPress before, but this experience opened my eyes. I loved tinkering with plugins and themes but my hands-on work was simply no longer necessary. Work like this would have taken me hours by hand, and an AI tool can now do much of it.

In the future we'll need a solution to deal with the PHP errors and warnings automatically as part of the update procedure. There are privacy and data concerns with this approach but there is definitely some potential to reduce the amount of man-hours required to keep these sites secure, even if we do have to lock some areas away from the AI. Tools like Imunify Patch already do this for security vulnerabilities - we need one for fixing legacy code easily.

The next time PHP sees a vulnerability, I'd rather have all sites already on the latest version to then patch easily.

Sources

Checked 24 and 25 October 2026.

I write every post myself. AI only helps fix typos and tidy repetition.