Of course we cannot always share details about our work with customers, but nevertheless it is nice to show our technical achievements and share some of our implemented solutions.
Yesterday was a very interesting day - technically speaking.
Information about critical security vulnerabilities of the PHP programming language were leaked. Vulnerabilities with a CVSS score 9.2, remote code execution possibility without prior authentication. Yes, this is bad. PHP is used very widely across the Internet, including in our own managed infrastructure and servers. Most of our customers run some kind of PHP application, from WordPress to Magento to custom applications.
But in such situations one thing is very important: Do not panic!
The security vulnerabilities were known beforehand. As often with open source projects, whether this is about an application or (as in this case) a programming language, security issues are reported on a secure channel and these issues are handled professionally. This requires collaboration across multiple developers, freelancers and companies. In the case of PHP, which is shipped as package across many Operating Systems, even more third parties are involved.
Security issues happen all the time. Sometimes they are minor issues, sometimes critical (the higher the CVSS rating, the more critical the vulnerability is). The usual process is:
In the case of these PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) everything worked as planned. The public information of the vulnerabilities and the release of new (patched) PHP versions was scheduled for Thursday October 22nd 2026.
But then something happened: The so-called "security embargo" broke. Information about a critical PHP vulnerability was leaked, on Hacker News information about a CVSS score of 10/10 made the rounds:
A reliable source has indicated an announcement is scheduled for 22 October 2026 at 18:00 CEST regarding 2x PHP RCEs with a CVSS score of 10.0.
This was picked up quickly by social media and caused a lot of confusion across developers, security researchers and system administrators. What is this about, how critical is this?
Then one of the involved parties released the fixes earlier than scheduled. This gave security researchers and hackers the opportunity to have a closer look at the patched PHP code and therefore identify the weakness. It didn't take long and the first exploits were already created.
This created an enormous pressure on the folks working for the PHP project. All of a sudden the patch needed to be released ASAP, the scheduled release was moved one day earlier to Wednesday October 21st 16:00 CEST. All the people involved from PHP and the package maintainers from the different Linux distributions and other third parties had to rush to get the fix out.
By the time the patched PHP versions were released on October 21st 16:00 CEST, many web hosters and IT companies panicked and shut down their servers as a security precaution in fear of being hacked.
Without the information leak everything would have gone smoothly. New PHP packages released as planned on October 22nd along with an information about the vulnerabilities. But the leak ahead of time caused the worldwide panic - and some falsely blamed PHP for being insecure.
Thanks to our international partnership with Australian Web Hosting Company Veeps Hosting we were informed early in the morning at around 06:15 CEST about the upcoming PHP patches and information leak about a potential critical vulnerability.
We worked together to find out more about the vulnerabilities and found a mitigation by disabling the PHP option session.upload_progress (Off).
By 09:00 the first PHP web servers had the mitigation in place, after evaluating whether or not the customer's application would require this setting to be enabled.
To roll the change out across the whole infrastructure and across all managed web servers, we created an Ansible playbook that covers both PHP-FPM and OpenLiteSpeed PHP installations and apply the option session.upload_progress = Off.
We published the Ansible playbook on GitHub. During the next hours we pushed the mitigation across all managed web servers.
Although the mitigation somewhat helps, the real fix would be to install the patches, as soon as they're made available.
At 16:00 PHP released the public information of the vulnerabilities alongside the patched PHP versions, as announced.
At 16:15 the patched PHP packages (from the Sury repository) were available and were installed across our managed web servers using a custom Ansible playbook we had prepared earlier specifically for the PHP updates.
For OpenLiteSpeed it took a bit longer. The patched. lsphp packages were available and installed on all web servers using OpenLiteSpeed around 18:55.
All web servers remained online. Our customers did not face any downtime. Luckily none of the customer's PHP applications actually required the option session.upload_progress to be enabled.
Thanks to excellent collaboration and communication with partners (Veeps Hosting), our customers and third parties (package providers and security researchers) we had no reason to panic.
It was a busy and interesting day - again, from a technical point of view. ;-)