Critical vulnerability in your PHP version (PHP2Shell)

What it is

On 20 and 21 October 2026, two critical flaws in the core of the PHP language were disclosed, tracked as CVE-2026-109618 and CVE-2026-109619. The community has taken to calling them PHP2Shell. They let an attacker run their own code on the server, without logging in and without any interaction from an administrator. The severity is rated CVSS 9.2, the highest band.

Our scan noticed that your site’s server announces a PHP version in the X-Powered-By header that does not have the fix yet. Disclosing the version is a minor thing in itself; the critical part is the version underneath it.

Why it’s a problem

Unauthenticated remote code execution is the worst kind of flaw. The attacker needs no password and no valid account: it is enough that your site is reachable from the internet. After a successful exploit they have the same privileges on the server as the application itself, so they can read the database, plant malicious code for your visitors, send spam from your server or enlist it in a botnet.

According to available sources, exploitation is already happening in the wild, in bulk and automated. With severity this high, the time between disclosure and internet-wide scanning is measured in hours, not days.

Which versions are vulnerable

The fixed versions are 8.5.12, 8.4.27, 8.3.36, 8.2.35 and newer within their branch. So the following are vulnerable:

How do I find my version

From the server command line: php -v. On shared hosting usually in the control panel (cPanel “Select PHP Version”, Plesk “PHP Settings”, or the site settings at your host). From the outside, it is often revealed by the X-Powered-By header:

curl -sI https://example.cz | grep -i x-powered-by

How to fix it

Shared hosting

In most cases it is enough to switch the PHP version in the hosting control panel to the latest one in the given branch (e.g. from 8.2.x to the last 8.2) and click through the application to check that it works. If you do not see that option or are not sure, write to your hosting support that you need the patch for CVE-2026-109618.

Your own server (Debian / Ubuntu)

sudo apt update
sudo apt upgrade php8.3 php8.3-fpm   # use your own branch
sudo systemctl restart php8.3-fpm
php -v

Your own server (RHEL / AlmaLinux)

sudo dnf upgrade php php-fpm
sudo systemctl restart php-fpm
php -v

Docker

Change the tag in your Dockerfile to a fixed version (e.g. php:8.3.36-fpm), rebuild and redeploy the image. Do not rely on the floating tag 8.3-fpm without a fresh pull; you may have an old layer cached.

When you cannot update right away

Until you have the fixed version, limit the impact: turn on a WAF (Cloudflare has a rule for this family of vulnerabilities in its managed ruleset), restrict access to the admin area by IP, and check the logs for signs that an attack has already happened. This is only a temporary patch, not a solution.

How do I verify it’s done

After updating, run a new scan at vulscan.app or check the version with php -v on the server. The X-Powered-By header should no longer show a vulnerable version; ideally hide the header completely (expose_php = Off in php.ini).

What can go wrong

Moving within one branch (8.2.x to the latest 8.2) is practically risk-free; fixes inside a branch are backward compatible. Jumping to a higher branch (say from 8.1 to 8.3) can expose outdated libraries or deprecated functions, so test it on a copy of the site. Even so, going up a branch is better than staying on a version with an actively exploited hole.

References