When I heard about the critical PHP vulnerabilities known as PHP2Shell, I decided to take my WordPress server offline until a security update was available.
The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, could allow attackers to execute code on a server without logging in. This was particularly worrying because the problem was in PHP itself, not in WordPress or one of its plugins. On October 21, 2026, the PHP project released security updates addressing both vulnerabilities.
I run a multisite WordPress installation on an AWS Lightsail instance. I maintain the server myself, although I’m certainly not a professional system administrator. For technical tasks, I’ve increasingly been using ChatGPT to help me work through the necessary steps.
This time, I wanted to do two things: update PHP as soon as a fix was available and find out whether somebody might already have broken into my server.
First, take the server offline
My first step when I learned about the security risk was to stop the entire instance in AWS Lightsail. I didn’t just stop Apache or switch WordPress into maintenance mode. I shut down the virtual server.
I also made sure I had a backup to return to if anything went wrong.
AWS Lightsail automatically creates daily snapshots of my instance and keeps them for seven days. I retained the latest snapshot so that it wouldn’t disappear when the normal retention period expired.
That gave me a fallback option. If the update went badly wrong, I could restore the previous state of the server.
Then I waited for the PHP security fix to become available.
Updating without exposing the server
When the patch became available, I wanted to update the server without immediately making it accessible again.
I therefore changed the AWS Lightsail firewall settings. I blocked incoming web traffic on ports 80 (HTTP) and 443 (HTTPS), leaving only SSH access through the Lightsail browser interface.
This allowed me to start the instance again and connect to it through SSH while keeping the websites inaccessible from the public internet.
The server could still connect to the internet to download updates.
With that setup, I could start updating the system without worrying about new incoming requests to my WordPress websites during the process.
Updating PHP with ChatGPT
I carried out the update in dialogue with ChatGPT.
The process was fairly straightforward: ChatGPT suggested a command, I ran it in the SSH terminal, copied the output into the chat, and then received an explanation of the results and suggestions for what to do next.
This was particularly helpful because I could check each step before moving on rather than blindly following a long list of commands.
I updated the relevant Linux packages, PHP, and WordPress components.
After the update, the server was running PHP 8.4.27 with Apache. This was the patched PHP 8.4 version released on October 21 to address the two critical vulnerabilities.
But installing the patch was only half the job.
If somebody had managed to exploit the vulnerability before the update, simply installing a new PHP version wouldn’t necessarily remove anything an attacker had left behind.
So the next step was to look for signs of an intrusion.
Had somebody broken into my WordPress installation?
Again, I used ChatGPT to guide the investigation.
I didn’t want to reinstall WordPress unnecessarily or delete anything that might turn out to be harmless. Instead, I wanted to check the existing installation as systematically as possible.
Checking WordPress and its plugins
Using WP-CLI, I verified the integrity of the WordPress core files against the official checksums.
The check passed.
I then checked the installed plugins. Twenty-three plugins passed checksum verification.
One plugin, Hello Dolly, showed a checksum discrepancy. On closer inspection, the PHP file contained recognizable legitimate plugin code, although the reason for the mismatch remained unexplained.
I also inspected a recently modified Jetpack language file. It turned out to contain ordinary German translations generated by GlotPress, the translation system used by WordPress.
There was no reason to change that file.
Looking for suspicious files and users
Another check looked for potentially malicious PHP files in the WordPress uploads directories.
Attackers sometimes try to place PHP scripts in directories where WordPress normally stores images and other uploaded files. Such scripts can potentially be used to gain continued access to a compromised website.
The scan did not identify any suspicious PHP files in those directories.
I also checked the WordPress administrator accounts. The accounts I examined dated back to 2022, and I found no indication that an attacker had recently created an additional administrator account.
The recently modified files in my custom WordPress theme were also inspected. They contained the expected code.
So far, nothing pointed to a successful intrusion.
What did the server logs show?
The Apache error logs were particularly interesting.
Among other things, they contained requests for files with names such as:
/wp-content/uploads/php.php
/wp-filemanager5.php
/wp-admin/kir.phpThese were not normal requests from people visiting my websites.
They looked like automated attempts to find vulnerable PHP scripts or files that attackers commonly use to control compromised WordPress installations.
Fortunately, Apache reported that these files did not exist.
This showed that the server had been probed, but it wasn’t evidence that the attempts had succeeded.
I also looked at other Apache messages, including redirect errors and SSL warnings. Nothing in the inspected logs established that somebody had successfully compromised the server.
Of course, that doesn’t prove that an intrusion never happened. But the checks provided no confirmed evidence of one.
Bringing the websites back online
After the security checks, I wanted to make sure that WordPress was still working properly.
I tested my two main websites, theonet.de and ralpe.eu, directly on the server while public access was still blocked.
Both returned HTTP 200, indicating a successful response, and completed the requests in approximately 50 milliseconds.
The WordPress installation was working.
I also confirmed that I still had a backup available.
It was time to make the server publicly accessible again.
In the AWS Lightsail firewall, I reopened ports 80 and 443 for incoming web traffic while leaving SSH access restricted to the Lightsail browser interface.
I then opened both websites in my browser.
They worked.
I also checked that a private WordPress blog still restricted access to registered users.
The update was complete, and my websites were back online.
What I learned
The main lesson for me was that updating PHP after a serious security warning involves more than installing a new package.
I wanted to have a backup, keep the server isolated during maintenance, check the WordPress installation for possible intrusions, and make sure everything worked before reopening the firewall.
ChatGPT was useful throughout this process. It suggested commands, helped interpret their output, and guided me through checks that I wouldn’t necessarily have known how to perform on my own.
At the same time, I had to decide what to do, which commands to execute, and when the checks were sufficient. Not every suggestion needed to be followed, and sometimes it made sense to keep the investigation focused rather than pursue every possible technical issue.
The result was a patched PHP installation, a WordPress multisite that was working again, and no confirmed evidence that the server had been compromised.
I can’t claim that this amounted to a complete forensic security audit. But it gave me a much better understanding of the state of my server and enough confidence to bring my blogs back online.
Featured image: PHP logo by Colin Viebrock, licensed under CC BY-SA 4.0.
I updated PHP and checked my WordPress installation with the help of ChatGPT. I wrote this article much the same way, using what I remember and parts of the chat.
Leave a Reply