Critical PHP vulnerabilities required a response even in ui42. In 200 projects, we first adjusted the PHP and Apache configuration, then deployed security patches. Where the deployment was hindered by the operating system version, we also updated the server environment. We did not have to preemptively shut down any of the websites we worked on.
On Wednesday, October 21, 2026, a security issue in PHP also affected the availability of Slovak and global websites. Preventive measures impacted the Ministry of the Interior, the Central Register of Contracts, and the Slovak Railway Company. The key word is preventive: shutting down these sites did not in itself mean that someone had successfully attacked them. Administrators turned them off to limit the risk.
At ui42, we addressed the same threat without the need for preventive shutdowns of websites. However, this result was not due to waiting. Our development team made interventions in 200 projects, from configuration adjustments to server updates.
What is PHP2Shell and why action was needed
PHP2Shell refers to a pair of critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. SK-CERT warned about them on October 21, 2026. Both received a severity rating of 9.2 out of 10 according to CVSS 4.0, and their successful exploitation could allow remote code execution without logging in.
It was not a flaw of a single plugin or a specific website. The problem was in PHP itself, which executes the application code on the server. Updating WordPress, another content management system, or its plugins did not remove this vulnerability. Intervention was needed at the server environment level.
PHP developers released security patches on October 21. They also emphasized that temporary measures can limit specific attack methods but do not replace the update.
This difference was also the basis of our response: first to reduce the risk with available measures, then to deploy patches.
First phase: PHP and Apache adjustments in 80 projects
Before deploying security updates, we made adjustments to the PHP and Apache web server configuration according to SK-CERT recommendations. This intervention was carried out across 200 projects.
“First, we adjusted the PHP and Apache settings across 200 projects. After 4:00 PM, we deployed PHP security patches. On servers where deployment was complicated by the Ubuntu version, we also updated the server environment,” describes Radoslav Kuchár, Head of Development at ui42.
The recommendations we followed included, for example, temporarily disabling the Session Upload Progress function by setting session.upload_progress.enabled=0. For services that do not require file uploads or multipart forms, it was recommended to consider blocking multipart/form-data requests before they are processed in PHP. For others, it was necessary to consider essential functionality.
We did not consider configuration interventions as the final solution. They were the first phase of the response, followed by the deployment of security patches.
Second phase: after 4:00 PM, we deployed PHP patches
After 4:00 PM, we proceeded to deploy PHP patches in the addressed environments.
This phase was crucial. While previous configuration measures limited exploitation possibilities, PHP updates addressed the two critical vulnerabilities themselves. The patched releases were PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35; for distribution packages, it was necessary to monitor the availability of patches from their provider. PHP
Our intervention did not end with changing settings. We continued with patch deployment and addressing obstacles that appeared on individual servers.
On some servers, it was necessary to update Ubuntu as well
Not all server environments allowed the same procedure. On some servers, it was not possible to deploy the necessary PHP patches due to the version of Ubuntu used.
In these cases, we also proceeded to update the operating system to enable PHP updates.
This is a significant part of the entire intervention: we did not only address the application or one package, but also the environment on which its update depended. When direct patch deployment was not possible, it was necessary to resolve this dependency.
For the website owner, such work takes place in the background. For the technical team, however, it determines whether the security patch can actually be deployed.
Another layer of protection: why it pays to use Cloudflare
The PHP2Shell case showed that hours matter in critical vulnerabilities. According to Cloudflare CEO Matthew Prince, their network recorded thousands of attempts to exploit vulnerabilities 10 hours before their public announcement. Within 45 minutes of publication, their number increased to tens of thousands, within two hours to hundreds of thousands, and then to millions.
Attackers are also aided by automated tools and artificial intelligence, which can speed up the search and exploitation of security weaknesses. The risk also increases when the website operator does not have an overview of the technologies they use and does not know that their PHP needs a security update.
Therefore, we recommend considering another layer of protection, such as Cloudflare. Its web application firewall (WAF) can block malicious requests before they reach the server with proper configuration. It can help reduce risk even when the security patch is not yet available.
However, Cloudflare does not replace PHP updates or server environment management. The best protection is a combination of preventive security measures, regular updates, and a quick response from the technical team.
Result: no preventively shut down website
In response to PHP2Shell, we at ui42 did not have to preventively shut down any of the addressed websites. The procedure included configuration interventions in 200 projects, PHP patch deployment, and, where necessary, server environment updates.
We did not stop at temporary measures. We followed up with patches and necessary server updates.
This result does not mean that preventive shutdown was the wrong decision in other organizations. CERT-EU recommended considering isolating publicly accessible applications until remediation and verification were completed if timely patch deployment was not possible. Each environment had its own conditions and intervention possibilities. CERT-EU
Our experience shows a specific course of resolution at ui42, not a universal guide that vulnerable websites should never be shut down.
What this case means for website and e-shop owners
When managing a website, it is worth asking not only about updates to its content and functions but also about the technologies that ensure its operation. Who is responsible for PHP updates? Who can intervene in the web server configuration? And what happens when a security patch cannot be deployed without updating the operating system?
The PHP2Shell case moved these questions from maintenance planning to real operation. At ui42, we addressed both related tasks: configuration measures and subsequent patches, including server environment updates.
The intervention involved 200 projects, but we did not have to preventively shut down any of the addressed websites. This is a result we can name along with the specific work that stood behind it.
