This post explains the security measurements Weichie took for our customers.
On October 21, the PHP project released an emergency patch for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The security community calls them PHP2Shell. An attacker does not need an account, a login, or any knowledge of the site. Any server that runs PHP and answers web requests is in scope.
One thing to clear up first, this was not a WordPress problem. PHP is the language underneath WordPress, but also underneath Drupal, Craft, Laravel, Magento, and most of the web. The platform did not matter. The language did.
Within hours, Cloudflare was reporting attack traffic. CISA and the UK’s NCSC published alerts.
Hour by hour
We run 200+ websites for clients. Not all of them are the same age, and not all of them run the same PHP version. That matters, because the fix is a PHP update.
11:58. The first warning report came in through our toolings and we saw the sh*tstorm coming in for an issue of this size. The flaw sits in how PHP handles file uploads, so the first thing we do is roll out our own server-level block, an server rule that stops multipart uploads. No upload, no exploit. Sites on an older PHP version, where no patch would arrive soon, got that lock. A few with a higher risk profile go offline altogether.
14:00. The story hits the press. The first emails and calls from clients come in, and they keep coming all afternoon. We drafted a client mailing list so we can quickly reach all our clients at once if this would happen ever again.
14:30. Word from the PHP team that the mitigations circulating online are not sufficient. We extend the upload lock to every site under maintenance that needs it, and keep watching.
15:40. Our hosting partner Combell confirms what we expected: no official patch yet, proof-of-concepts in the wild, and mitigation measures going out across their whole infrastructure.
15:52. Everything below PHP 8.2 is locked on our side, offline, or disabled. Everything on 8.2 and up is alive, and a file check shows nothing has been touched.
16:00. The patch goes live on PHP.net. That is not the end, because a release still has to travel to every vendor that packages PHP before it reaches a server. We start rebuilding the servers we run ourselves right away, and finish over the following hours.
18:00. Combell rolls out the patches, including custom backports for PHP versions that PHP itself stopped supporting years ago. We lift our upload locks.
18:30. The offline sites are back up. We keep monitoring.
We found no signs of abuse on any site. A few clients host elsewhere, and their providers patched on their own schedule.
Why it stayed under control
The first is Combell. They run a custom PHP stack rather than a stock installation, which made their platform considerably less exposed than the average server. They had mitigations in place before the patch existed, patched the supported versions the same evening, and built their own patches for the unsupported older versions.
Read more about the Combell Patch Status
The second is that we were on top of it. Our monitoring for unauthorized changes and odd behavior was already running by default. It did not need to be switched on.
Most sites are built once and then left alone. They work, so nobody touches them. That used to be an acceptable risk, because exploiting a new flaw took skill and time, and most small sites were not worth the effort.
We would like to thank all our clients for their trust in our Weichie Studio.
