On October 21, 2026, PHP disclosed two critical security vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Severity rating: 9.2 out of 10; exploitable via standard web requests. PHP is the language on which WordPress and a large portion of the web run. All PHP versions were affected.
We operate 41 servers running 68 web applications for our clients, most of which are WordPress sites. Three days later, every single one of them was running a patched version of PHP. No site went offline, and an 11-year-old theme received its first patch in years. This post explains how we did it and what you can take away from it for your own project.
The hosting partner was faster than the fix
The fact that the week went relatively smoothly was primarily thanks to RunCloud, our hosting partner. On the very day of the release, RunCloud blocked the attack vector on all servers—14 hours before the patched PHP versions were even available. After that, RunCloud automatically applied the updates and sent us a short list of items that each administrator needs to check on their own.
| Time (CEST) | Who | What |
|---|---|---|
| Oct. 21, 10:00 a.m. | RunCloud | Attack vector blocked on all servers (session.upload_progress (disabled) |
| Oct. 22, 12:00 a.m. | RunCloud | Patch versions of PHP 8.2 through 8.5 are being rolled out automatically |
| Oct. 23, 11:04 a.m. | RunCloud | Fix for older versions 7.4 through 8.1 on containerized servers |
| Oct. 23, 11:30 p.m. to Oct. 24, 12:40 a.m. | we | Inventory of all servers and apps; patch status confirmed across the board |
| Oct. 24, 12:30 a.m. to 1:45 a.m. | we | Eleven outdated apps have been migrated to PHP 8.3, two of them with a theme patch |
| October 24, in the afternoon | we | Last app ported from PHP 5.6 to 8.3 |
Status Update: Where Is CVE-2026-109618 Still Unresolved?
After the automatic update, four questions remained: Were all servers accessible during the update? Is the operating system recent enough? Has the patch really been installed everywhere? And is there still an app running somewhere on a version of PHP for which there is no longer a fix available?
With 41 servers, you can’t just click through that in the dashboard. We retrieved the answers via RunCloud’s API and cross-checked them with a short verification script on each server. This quickly answered the first three questions: all servers were online, all operating systems were up to date, and the patch was installed everywhere.
The fourth issue remained unresolved: Twelve apps were still running on PHP 8.1 or older, a version without a fix. Each of them had to be upgraded to a newer version; otherwise, they would remain vulnerable. Until then, there was a second line of defense: Most of these sites were already running behind Cloudflare, which intercepts suspicious requests before they reach the website. This provided protection, but it was no substitute for the patch.
Switch over 12 apps without anyone noticing
Six of the twelve apps were WordPress sites. We migrated four of them right away: change the PHP version, load the most important pages—done. The switch takes just seconds and can be reversed in seconds.
Two sites were more challenging. Both use the same theme from 2014, including the website at Haus Moos, which still doesn’t look its age. An earlier attempt with PHP 8 had resulted in a blank page, and no one knew exactly why. This time, we ran an automated scan of the entire theme code to find sections that no longer work with the new version of PHP.
We found just five instances in four files. The critical one was a line that was never executed. PHP 8 still rejected the entire file—and thus every page on the website. Five lines of corrections, a backup, the switch—then 80 pages were automatically loaded and the error log was checked: not a single error. The same thing happened with the second site.
The twelfth app, which we developed in-house using PHP 5.6, required more than just a version update: it had to be ported. Before AI, we would have estimated that this would take one to two days; with AI, it took about an hour and a half.
Three factors that made the difference
1. A hosting partner that acts before the fix is released. RunCloud had mitigated the vulnerability on all servers before any patched versions were even available, and afterward clearly specified what still needed to be checked, rather than just saying, “Please update everything.” That’s the difference between one evening’s work and a week’s.
2. An API instead of a dashboard. Inventory, switching to PHP, rollback: Everything was handled through the same interface. If you have to click through 41 servers in a browser, it takes a whole day and you’re bound to make mistakes. The API takes just minutes and logs every step.
3. Claude as an analysis and tool accelerator. Anthropic’s AI assistant—which had already helped us speed up our forensic analysis during the BEC attack in April —wrote the scripts, evaluated the server data, analyzed the old theme, and suggested the five corrections. What used to take a full workday per theme was now a matter of minutes.
The truth is, there were things the AI wasn't allowed to do and couldn't do. It didn't have access to the production servers: Every command there was deliberately typed by us. And it made two mistakes of its own—a script that terminated after the fifth server, and an incorrect field name in an API call. Both were noticeable in the output and were corrected within minutes, but it wasn't error-free.
None of these three factors alone would have been enough. Without our partner, we would have applied patches instead of testing. Without the API, we would have clicked instead of counting. Without AI, we probably would have scrapped the 2014 theme and merely postponed the problem.
What This Means for Your Next Project
1. Operations is a decision you make during the development phase. The fact that the open questions were answered in minutes wasn’t due to that particular night, but to decisions made years earlier: a platform with an API, one server per customer, and no special cases in the configuration. When you plan a product or a website, your choice of infrastructure determines what an evening like that will look like later on.
2. The PHP version belongs in the project plan, not in the maintenance list. Nine of our twelve legacy sites were running on PHP 8.1, which reached end-of-life in December 2025. Each had a reason: a project under development, a theme that “will be replaced soon anyway.” The security vulnerability didn’t ask for permission. That’s why we start new projects on the current version, with a fixed date for the next upgrade. The next one is already set: five sites on PHP 8.2, whose support ends on December 31, 2026.
3. Existing code is rarely as broken as it seems. Five quick fixes saved an eleven-year-old theme. The previous attempt had failed only because the blank page gave nothing away. An automated code check finds such issues in minutes, and a rollback in seconds makes testing on the live site feasible. This applies to themes just as much as it does to the custom development you’ve been putting off for years.
If you want to build something that works like this
We develop web applications and websites and host them on the infrastructure discussed in this post. Our portfolio showcases a selection of these projects. Our customers were just as unaware of the critical vulnerability as anyone else: they didn’t notice a thing. If you’re a product owner or product developer planning a project where operations need to be considered from the very beginning, we’d be happy to discuss it with you before a single line of code is written.
All information regarding servers, versions, and dates is based on our records from October 21 through 24, 2026. RunCloud is our hosting partner; we do not receive any compensation for mentioning them.
