On the evening of October 21, I patched a news site that gets more than a million page views a year against one of the worst PHP vulnerabilities in years. It took about 90 minutes. The site was down for a few seconds. Nobody at the client noticed anything.
That last sentence is the whole story. It is also the reason most people never find out what good technical work looks like.
What Is PHP2Shell?
PHP is the software that runs WordPress, and with it a large share of the websites on the internet. If your site is on WordPress, it runs on PHP, whether or not anyone has ever told you.
On October 21, two critical flaws in PHP itself were made public (CVE-2026-109618 and CVE-2026-109619). Security researchers nicknamed them PHP2Shell, because they let an attacker take control of the server from the outside. No password, no login, no help from anyone inside. Security firms rated them 9.2 out of 10, and according to Patchstack, every PHP version since 5.4 is affected by at least one of the two.
The worst part was the timing. Details of the flaws leaked before the fix was ready, so the PHP team had to release an emergency update, and attack attempts were being reported almost right away. Google Cloud and several security companies published alerts the same day.
In plain terms: if you had a WordPress site that evening, someone could be trying to walk into it, and the only thing that would stop them was whether someone on your side had installed the fix.
How the Evening Actually Went
I read the alert, checked the client's server, and confirmed what I suspected. The site was running a vulnerable version, in one of the configurations security firms rated as highest risk. The fix was already available. It just was not installed yet.
The update itself is a single command. That is not where the 90 minutes went.
Before touching anything, I took a full backup of the server, a snapshot that could restore it to the exact state it was in before the change. I also saved the configuration and the list of every package version that was about to change. Then I installed the fix, restarted the web server, and checked that the homepage loaded, that editors could still log in, that the feeds worked, and that the error logs stayed clean.
Only then did I call it done.
A patch without a backup is a bet. Most of the time the bet pays off. But on a site that publishes every day, "most of the time" is not good enough, and the few minutes the backup takes are what let you move fast without being reckless.
Nobody Calls to Say the Website Is Working
Here is the uncomfortable part of this job. When backend work is done well, there is nothing to report. The site loads. The articles publish. The newsletter goes out. Nobody sends a message saying "the server was not hacked today, thank you."
When something breaks, it is the opposite. Everyone notices at once. The site is down, the phone rings, someone forwards a screenshot, and the technical team suddenly has everyone's attention, all of it negative.
That imbalance is not anyone's fault. It is just how attention works. We notice change, not stability. But it has a real cost: it makes good maintenance look unnecessary, and it makes the people who do it look idle.
The classic example is Y2K. Thousands of engineers spent years fixing old systems before January 1, 2000. The date came, almost nothing happened, and to this day a lot of people remember Y2K as a false alarm. It was not a false alarm. It was a problem solved so well that it disappeared.
If PHP2Shell had hit this client's site, it would have been news, possibly literally. Because it did not, the most dramatic thing that happened that evening was a three-second restart.
The Emergency Was the Easy Part
I want to be honest about something, because it is the more useful lesson.
Patching fast during an emergency is the visible, satisfying kind of maintenance. The harder kind is the routine work nobody asks for: applying updates every month when there is no alert, no headline, and no deadline. When I checked the server that evening, the fix for PHP2Shell was not the only update waiting. There were others that had piled up quietly, because nothing was on fire.
That is normal, and it is also how most sites end up exposed. Not through one dramatic mistake, but through months of "it works, let's not touch it." So the next step for this client is not another emergency. It is a short, scheduled maintenance window, so the next alert finds a server that is already up to date.
Making Invisible Work Visible, Without the Noise
If good maintenance is silent, how does anyone know it is happening?
The answer I use is simple: write it down. Every intervention gets a short note in plain language for someone who is not technical. What happened, why it mattered, what I did, and what comes next. For PHP2Shell, the client got exactly that the same night, before anyone had to ask.
It is not a dramatic report. It does not need to be. It just means that when someone eventually asks "what does the tech team actually do?", there is an answer that is not a guess.
Is Your Site Affected by PHP2Shell?
If you have a WordPress site, or any site built with PHP, you do not need to understand the details. You need to be able to get clear answers to three questions from whoever maintains it:
- What version of PHP is my site running, and does it include the PHP2Shell fix? The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those branches is exposed. Older branches that no longer receive support will not get a fix at all.
- Who would have found out about PHP2Shell, and when? If the honest answer is "nobody, until something broke", that is the real problem, not this particular flaw.
- Is there a backup before every update? Not "we have backups somewhere". A backup taken right before the change, that someone knows how to restore.
If you get vague answers, that does not mean your site has been compromised. It means nobody is watching, and that is worth fixing before the next alert, not after.
The best compliment backend work can get is silence. It is just worth knowing that the silence was earned.
