The night before last, many WeChat groups were sharing a screenshot of a PHP vulnerability. It looked like an “epic-level” disaster scenario that could affect more than 70% of web servers worldwide. After seeing it, I immediately logged into each of my servers to check how big the impact really was.
In the end, fixing it took two nights. It wasn’t until after 1 a.m. last night that I finally got it done.
But in fact, the main problem in this repair process wasn’t PHP itself.
I Thought It Was Just a Patch
On October 21, 2026, the PHP team released two severe vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known in the industry as php2shell, with a CVSS score of 9.2. They allow remote code execution without logging in. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35; versions ≤ 8.1 have no patches at all.
I have a few VPSs running 1Panel and a bunch of Docker applications. My first reaction was to upgrade the PHP runtime environment according to the official guidance. But as soon as I started, I realized my 1Panel version was too old, and many components had been modified by me. It was truly painful to deal with. In the end, I made the decision to upgrade 1Panel to the latest version first.
That was the starting point of all the trouble.
The Painful Process of Upgrading 1Panel
Most machines upgraded fairly smoothly. Using the officially released 1panel-migrator took only a few minutes. But one VPS already had 80% of its storage used. A snapshot couldn’t be made, and migration required moving a large number of files around, so there simply wasn’t enough space. The upgrade process failed repeatedly, which directly caused more than 30 sites on this VPS to be reduced to only 7.
Later I discovered that one FreshRSS application alone was eating 50GB, all of it article cache and attachments that hadn’t been cleaned in years. There was also an old site with about 70GB of images, which was another reason the upgrade failed.
Then I checked the remote backup. Oh boy—it had failed a long time ago. It turned out that because my OneDrive membership expired a few months ago and I didn’t renew it, the capacity dropped from 1TB back to 15G, and new files could never be written.
This mess cost me an extra night dealing with the site recovery on that VPS. That’s why a simple “patch” took me two nights.
In fact, upgrading 1Panel or even fixing the PHP vulnerability isn’t complicated in itself. What’s complicated is all the stuff I’ve slowly piled up on my servers over the past few years.
After all, before fixing anything, I scanned all my machines. There were about 100 Docker containers in total, plus some system-level services, but only 14 were actually PHP projects—typically blogs, image hosting, RSS readers, and personal self-built PHP projects. Even the Node high-risk vulnerability that appeared the same day had a wider impact; I had Node installed on almost every VPS.
Those Unmaintained Containers
The PHP runtime environment bundled with 1Panel was relatively easy to handle—just create a new environment and switch the site over. The real trouble was the applications pulled from third-party app stores or from some personal developer project at some unknowable time. Many hadn’t been updated in years, and the old PHP versions were packaged directly inside the application’s own image, with no unified runtime environment to switch to.
Manually modifying these containers meant going into docker-compose.yml to change the image: tag, confirming that the PHP version in the new image reached the fix line, rebuilding the container, verifying the site worked properly, and also handling compatibility of data volumes and configurations. Doing this for a dozen containers one by one was impossible to finish in one night.
In the end, I used DeepSeek Harness to help complete this part of the repair. It helped me sort out each container’s image source, current PHP version, available fixed tags, and the mount and network configurations to pay attention to during rebuilding. Manual work went from “checking containers one by one” to “confirming the plan and then executing in batches,” saving a lot of time on trial and error.
This process itself also shows that the cost of fixing this vulnerability has become so high that AI tools are needed to finish it before attackers get to it. On the attacker side, mass scanning and automated exploitation have long been the norm. Tools on both sides are accelerating, and individual users caught in the middle will find it increasingly difficult to rely on manual server maintenance.
This Didn’t Get Built in a Day
To be honest, when I saw those 100-plus containers, I felt a bit dazed. They didn’t appear overnight; they accumulated step by step over twenty years.
Twenty years ago, I only needed a domain name and a shared hosting account. Later, I felt shared hosting was too limited in features and too restrictive, so I started using cheap VPSs.
Cheap VPSs, well, always have one shortcoming or another—either small disk, small bandwidth, bad routing, poor performance, or severe overselling. So I started researching how to combine them: big-disk machines for storage, good-route machines for traffic, high-performance machines for computing, using several machines together.
Using them together meant getting into CDN traffic splitting and multi-domain reverse proxying. As the number of VPSs grew, probe panels, cluster management, and distributed backups became necessary. Then the VPSs couldn’t sit idle either—if they could run one more service, they would.
Over the years, I didn’t build many serious businesses, but all kinds of weird pseudo-needs kept increasing.
And a person’s energy is always limited; you can’t remember everything forever. Just like this time when I discovered my OneDrive membership had expired. The reason was that I needed multiple OneDrive accounts to back up data, and the one I use daily is tied to my Windows system and has always worked fine, so I never thought about another account expiring—after all, the last renewal covered several years. And the email address that was supposed to receive scheduled reminder emails had been deleted by Google a year earlier.
Essentially, this is the process of a single system increasing in entropy as it becomes a complex system. Every additional machine, every additional reverse proxy, every additional container installed “just because the machine is idle anyway” makes the system a little more complex, adds a little more to maintain, and increases the cybersecurity risk a little more.
By the time this PHP vulnerability broke out, the entropy bill finally arrived at my door.
Maintaining the Business or Maintaining the Server?
After fixing this vulnerability, I thought about it: with all this hassle, am I maintaining the business or maintaining the server?
If most of what runs on a VPS consists of tools I use only occasionally, projects I never opened again after testing, and containers whose purpose I can’t even remember, then every time a vulnerability breaks out, I have to pay for all of it—inventory, shutdown, finding images, rebuilding, verification, dealing with insufficient storage, and handling migration failures.
And these things shouldn’t be occupying public ports in the first place, nor should they be entering my “emergency repair list.”
So for individual users, the direction is actually clear: if it can be handed to a platform, stop running your own server.
Serverless platforms like Cloudflare Workers and Vercel take over the runtime, patches, scaling, and availability. You don’t need to docker pull a new image on the day a vulnerability breaks out, and you don’t need to fail an upgrade because storage is at 80%. In recent years, a large number of independent developers have migrated from scattered VPSs to platforms like Vercel and Cloudflare Workers. The reasons aren’t just saving money, but also “no longer worrying about traffic spikes causing CPU limits” and “not wanting to clean up after infrastructure anymore.”
For example, the Cloudflare Workers + R2 + D1 full-stack solution I use most in daily life is indeed significantly more cost-effective in edge scenarios. Although there is a limit of 100,000 requests per day and I often receive daily usage alerts, it’s really just a matter of registering one more free account.
Of course, this doesn’t mean VPSs have no value. For things that need persistent processes, self-hosted databases, or specific kernel parameters, VPSs are still a reasonable choice. But the era of “installing everything on one VPS” is coming to an end for individuals.
Last night in a tech group, I suggested that as of 2026, for individual users, one home cloud host plus one good-route machine is actually enough. It struck a chord with quite a few people.
Next Steps
After this lesson, I’ve learned another one: rather than waiting for everything to spiral out of control and explode all at once, it’s better to “simplify” from the source. Especially for someone like me, a middle-aged person whose memory isn’t as good anymore—fewer things to deal with is better, and it’s also a way of preparing for the future. Here’s a summary of the directions.
First, clear out containers and DNS records that are “used once and never again.” Don’t rush to delete them; stop them, mark them, and observe for a while. One less attack surface means one less thing to evaluate the next time a vulnerability breaks out.
Second, gradually migrate static sites and light applications that can go Serverless. No SSH, no patches, no worrying about PHP versions. Personal blogs, documentation sites, and simple APIs all fall into this category.
Third, for what stays on the VPS, keep only what truly needs to be resident. And set retention policies for every data-heavy container. The 50GB FreshRSS lesson is enough once.
Fourth, accept the premise that “there will be more and more vulnerabilities.” The goal isn’t zero vulnerabilities; it’s not leaving high-risk entry points exposed and being able to stop the bleeding quickly when something happens. Containerization has already helped limit the impact scope; the next step is to make more things not require my fixing at all.
Fifth, make good use of AI agents. Security vulnerabilities are bizarre and varied—today the application layer, tomorrow the system layer. We never know where the next high-risk vulnerability will appear or how difficult it will be to fix. For the troublesome and difficult ones, let AI handle them as much as possible. Essentially, these are machine-to-machine matters; don’t make people spend too much energy on them.
Sixth, admit that entropy increase is the default direction, and subtraction requires deliberate effort. Systems don’t become simpler on their own. Before adding another machine or installing another service, ask yourself: does this thing really need to be resident? Or am I just thinking “the machine is idle anyway”?