Two critical security vulnerabilities, millions of web servers potentially affected, and the risk that attackers could execute malicious code remotely. When the so-called php2shell vulnerabilities came to light on 21 October 2026, swift action was required. EGOTEC was able to release a security update that very same afternoon and begin updating its customers’ installations.
Two critical security vulnerabilities in PHP
On 21 October 2026, the security vulnerabilities CVE-2026-109618 and CVE-2026-109619 were published. Both were classified as critical with a CVSS score of 9.2.
Particularly problematic: under certain conditions, attackers can exploit the vulnerabilities without prior authentication and execute malicious code on affected web servers.
Security researchers demonstrated a successful attack on a PHP-based web server in just 38 seconds. This required numerous automated HTTP requests.
PHP versions released over the past 20 years or so were affected. This raised the question for operators of PHP-based applications worldwide as to how quickly they could secure their systems.
A security update within a few hours
For us at EGOTEC AG, the security of our customers’ installations was immediately our top priority.
Even whilst the technical details of the vulnerabilities were still being published, we analysed the impact on EGOCMS and assessed possible protective measures.
Our timeline on 21 October 2026:
-
14:15: We were informed of the security alert issued by the Federal Office for Information Security (BSI).
-
3.38 pm: The patched PHP versions are available. We check their integration into our EGOCMS environment.
-
4.09 pm: We document additional PHP configuration measures to temporarily reduce the risk.
-
4.31 pm: An updated Docker image containing the PHP security updates is already available with EGOCMS V26.3.4.2.
-
On the same day: We are updating our hosted customer installations as a matter of the highest priority and informing our customers of the necessary measures.
-
5.52 pm: As a precautionary measure, we take the Matomo instances we host offline until their PHP runtime environments can also be updated.
By the following morning, 22 October at 07:05, we were able to report:
All customer sites hosted by us are running smoothly.
Additional protection was already in place
For us, security does not begin only when a new vulnerability becomes known.
Our EGOCMS installations are operated in a container architecture using nginx and PHP-FPM. We rely on several protective mechanisms designed to make potential attacks more difficult.
To this end, the image has long included rate limiting. By default, the website traffic covered by this is limited to an average of five requests per second per IP address.
As the attacks demonstrated require thousands to tens of thousands of HTTP requests, this protective measure can make automated attacks considerably more difficult. However, it does not provide complete protection.
Please note: Rate limiting is an additional protective measure, but is never a substitute for the latest security updates.
That is why the immediate installation of the PHP security updates and the provision of an updated Docker image were our top priorities.
Precautionary shutdown of Matomo
In addition to EGOCMS, we also operate Matomo instances for web analytics on behalf of our clients. As Matomo is also based on PHP, we had to include these systems in our security measures.
We therefore decided on 21 October at 17:52 to take all Matomo instances hosted by us offline as a precautionary measure until the necessary PHP security updates could be applied.
No new tracking data could be collected during this shutdown. Existing statistical data was retained.
Our policy is clear: where there is any doubt, the security of our customers takes precedence over the temporary availability of an additional service.
Older customer installations also had to be taken into account
A particular challenge was posed by a small number of customer installations that were still running on older versions of PHP that were no longer regularly supported.
Regular security updates were no longer available for these outdated PHP versions. A migration to a current system environment was therefore necessary.
Fortunately, we had already begun migrating most of the affected customers to up-to-date systems.
Thanks to the extra efforts of our team, we were also able to drive these migrations forward at short notice. In some cases, this required work outside regular working hours.
We’ll be covering the specific challenges involved and why regular software updates are so important in a separate article.
Prompt and transparent customer communication
In addition to technical safeguards, communication was particularly important to us.
Even whilst the work was ongoing, we kept our customers informed about the security situation, available protective measures and the progress of the updates.
To this end, we continuously updated our blog post and also sent out newsletters containing specific recommendations for action.
It was particularly important to us to distinguish between customers using our latest EGOCMS Docker images and those who manage their own PHP runtime environment.
This is because, with self-managed PHP installations, PHP security updates must be applied independently of EGOCMS.
For us, security isn’t just about resolving technical issues quickly. We also want our customers to know what is happening, what measures we are taking and whether they need to take action themselves.
Our conclusion: preparation and a swift response pay off
Critical security vulnerabilities cannot be completely ruled out, even with established technologies.
What matters is how a software provider deals with them.
On 21 October, within a matter of hours, we were able to integrate the new PHP security updates into EGOCMS, provide an updated Docker image, initiate the update of our customers’ installations and take additional precautionary measures.
The stable operation of our clients’ websites the following morning was the result of sound technical preparation and the swift action of our team.
A big thank you to all staff members who contributed to this – even working beyond their regular hours.
We will continue to closely monitor security-related developments, implement necessary measures swiftly and keep our customers fully informed.
Further technical information and a full account of the security measures can be found in our blog post:
Critical PHP security vulnerabilities – information and security updates