On 21 October 2026 the Czech National Cyber and Information Security Agency (NÚKIB) warned of two critical flaws in PHP, the programming language most of the world's websites run on. Experts call them php2shell (CVE-2026-109618 and CVE-2026-109619). They allow an attacker to run their own program on the server without any password. Details leaked before the fixes were released, and instructions for exploiting them are publicly available.

There is a solution, and only one: update PHP. Below we explain how to find out whether you are affected and what to do depending on where your website runs.

Am I affected?

Probably yes, if your website or application runs on:

  • WordPress, Joomla, Drupal or another content management system you log into via /wp-admin or /administrator,
  • an online shop on your own hosting (PrestaShop, WooCommerce, Magento),
  • an ordering or booking system, intranet, attendance system or other custom web application, if it is written in PHP.

You are not affected if your website or shop runs on a ready-made service where you do not look after the server (Shoptet, Webnode, Wix and similar). There the service operator handles the update.

Importantly, it does not matter how strong your admin password is. The flaw is in PHP itself, and the attacker exploits it before the website even gets to checking the login.

What to do depending on where the website runs

Website on shared hosting (Wedos, Websupport, Active24 and others)

Most large hosting providers update PHP themselves, and quickly. Check anyway:

  1. Log into your hosting control panel and find the PHP settings for your website.
  2. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and later. If you have an older branch selected (7.4, 8.0, 8.1), switch to a newer one. Back up the website before switching and click through it right afterwards.
  3. If you are not sure, ask your hosting provider. They should have a "fixed" answer ready.

Your own server or virtual server

Here the update is up to you or your administrator:

  • Update only the PHP packages, not the whole system at once. If something breaks, you know straight away what caused it.
  • Take a backup or snapshot of the server before updating. If the website does not run after the update, you can roll it back in a minute.
  • After updating, restart the web server (Apache, PHP-FPM). As long as the old processes are running, the fix does not apply.
  • Use the opportunity to install the system's other security patches as well. You will often find the server has not been touched for months.
A technician updates a server at night and in the morning checks the website on a tablet with the business owner
Backup, PHP update, restart and website check. For each server separately.

An old website that will not run on a new PHP

This is the hardest case. An application written years ago for PHP 7 or older often does not work on the new version, and the developers have not released a fix for the old PHP branches. You then have three options:

  1. Port the application to a new PHP version. This is the permanent solution, but it takes days to weeks depending on the size of the application.
  2. Restrict access in the meantime. If the application is used only by a few branches or employees, configure the server so that only their IP addresses can reach it. Everyone else gets "access denied" before the request reaches PHP. A server-level password, entered before the page itself, also works.
  3. Turn a simple website into a static one. A presentation website where only text or a menu changes now and then does not need PHP at all. A static copy runs without a content management system and is not affected by this flaw.

Note: PHP 8.2 stops receiving fixes on 31 December 2026. If you are updating within the 8.2 branch now, plan a move to 8.3 or later for next year.

How to tell whether someone has already got in

The flaw was being exploited before the fix was released. Updating closes the door, but it does not throw out anyone who is already inside. After updating, therefore, look for:

  • unknown processes running under the web server user, typically programs that load the processor (cryptocurrency mining),
  • new or modified .php files in the website folders, especially in directories for uploaded images,
  • unusually high load on the server or outgoing traffic with no obvious reason,
  • new users in the website administration.

If you find any of this, deleting the file is not enough. The whole server needs to be checked, all passwords changed (database, FTP, administration) and, in the worse case, the server restored from a backup that predates the attack.

How we handled it

NÚKIB sent the warning on the evening of 21 October, and that same evening we went through all the websites and servers we manage:

  • Most of our websites do not use PHP at all, so they were not affected.
  • Web servers running PHP were updated that same night, one after another and always with a backup first. We also installed the other pending security patches on them. Internal systems such as email follow in separate maintenance windows.
  • One older application that will not run on the new PHP has been restricted to the IP addresses of the branches that use it until it is ported.
  • A simple presentation website on a content management system is being converted to a static one, so that PHP and its updates are no longer needed.

The live websites were down for only a few seconds during the update, while the web server restarted. One thing surprised us, though: on a test server, the database did not start after the security patches because of a change in the new version. That is why we always update the test environment first and only then production.

Summary

  • Do you have a website on WordPress, Joomla or a custom PHP application? Check your PHP version today and update to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later.
  • On shared hosting, checking the settings is enough. On your own server, back up, update, restart and check the website.
  • Hide an old application that cannot be updated behind an IP restriction until it is ported.
  • If you are a regulated organisation under the Czech Cybersecurity Act, such an intervention also belongs in your records. More in the article Does NIS2 apply to you?

Not sure what your website runs on, or have no one to do the update? We will find out for you and within one day tell you whether the flaw affects you and what to do about it. Order a free check.