Critical PHP vulnerability: How we patched 500+ sites

When a security vulnerability becomes public, the only thing that counts is how fast you react. Two critical vulnerabilities in PHP were disclosed on 20 and 21 October 2026. We protected our clients' sites before the official patches were available. Over the next two days we updated more than 500 websites, web shops and applications and we moved them to new servers.

This article describes how the work went, which decisions we made and why.

What happened

On Tuesday, 20 October 2026, the community that develops PHP announced urgent patches for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both of them let an attacker run commands on a vulnerable server without a password. The fault sits in the core of the language, so it affects almost every website that runs on PHP. That includes WordPress, Drupal and Joomla, and it included the Kabi platform, the web platform we develop ourselves.

On 21 October the Slovenian government information security office, the national cyber security authority, raised the threat level to high. It ordered the organisations under its supervision to update their internet-facing systems within 48 hours at the latest. It later turned out that attackers had tried to exploit the vulnerability as early as 17 October, four days before the patches were available. That order applied in Slovenia. If you work in another market, look for the same kind of notice from your own national authority.

Day one: protection before the official patches

On 21 October, when we received the announcement, the technical details were not public yet. We only knew that the fault was critical and when the patches would be released. That day we did three things.

1. We mapped every server and every project. We listed which PHP version runs where, which projects already run on the new infrastructure and which ones are still on the older one. We host and maintain only the solutions we have built ourselves, so the list was ready within a few hours. A provider that hosts hundreds of systems built by other people would need considerably longer for the same overview.
2. We disabled file uploads. Our main measure was to switch off file uploads on client websites and in the back office of our applications. Security companies later confirmed that the attacks run through file upload requests. The restriction also applied to uploading images and documents in the CMS back office, in the CRM and in the PIM system, so our clients had to work with some limitations for a while. We judged that this was a far smaller risk than leaving the servers open.
3. We told our clients what was going on. We wrote to them about the situation, about the measures we had already taken and about what we were preparing. We wanted them to hear about the problem from us first, not from the news.

Newer projects were patched within an hour of the release

The patches came out on Wednesday, 21 October at 16:00 local time. About 100 projects built in the last year were already running on the new infrastructure. Installing the update there was quick, so those projects were protected within an hour of the official release.

Days two and three: patches and a migration for the older projects

Two days, a new infrastructure and more than 500 sites moved

The work on the remaining projects was much larger. Moving the older projects to the new infrastructure was already planned before this vulnerability appeared. The vulnerability left us with two options: patch the old environments and migrate them a few months later, or migrate at once. We chose to migrate at once. We first prepared the new server environment and the new infrastructure, and then we started moving the projects.

In two days we:

• protected more than 500 websites, web shops and applications, updated them to the latest officially supported version and moved them to new servers
• ran the migrations at night on Thursday and on Friday afternoon and evening, so that our clients noticed as little disruption as possible.

The work users never see

There is no single button for this, which is a pity. Every website has its own particularities and its own requirements. One site is connected to a different ERP system than the next, and it may run on a different PHP version. Older sites needed changes in their code before they could run on the new version. A move that goes smoothly needs a plan, careful execution and a check that everything works as it did before. With more than 500 projects, that is a challenge of its own. We have described what such a move involves when search rankings have to stay intact in our article about a web shop redesign without losing organic traffic.

The whole team took part: system administrators, developers and project managers. A fast response shows how well you know your own infrastructure. We know ours well, because we have built it ourselves over the years.

What we learned

1. Speed depends on preparation. Mapping the servers and the sites took only a few hours, because we knew what runs where. Without that list, we would have spent the first hours searching.
2. You can protect a site before the official patch. A temporary limit on file uploads closed the route for attackers while there was still no patch. Keeping backups in a separate environment matters just as much.
3. An outdated site costs you at the worst possible moment. Projects on the new infrastructure were protected within an hour. The older ones took two days of work. That is the reason to update websites as you go, and regular updates keep unexpected costs away. We have shown what a technical renewal brings over a longer period in one year of data after a website redesign.
4. Communication is part of protection. A client who knows what is happening accepts temporary limitations more easily and does not have to guess.
5. Investment in infrastructure pays off. The many hours we put into building our own infrastructure could have gone into paid projects instead. This event showed that the decision was the right one.

There are also measures that protect a website whoever hosts it, and they apply to every company.

Security is not a one-off task

Events like this show how much depends on regular maintenance of the infrastructure, on updating websites, web shops and applications, on following security notices and on reacting quickly. Website security is a basic business question today, not a technical detail.

We will keep making sure that our clients' sites stay safe, up to date and ready for what comes next. Regular website maintenance is part of the care we take of a project as a whole, from building the website to hosting it.

If we do not maintain your website and you are not sure whether it is protected, send us the address. We will check which PHP version it runs on and tell you whether anything needs to be done. It also helps to ask the right questions when you choose a hosting provider, and to follow our news.

For our clients, a website is above all a sales channel. Our job is to make sure they do not have to carry the worry about its security and its operation themselves.