PHP2Shell, the most common questions: which PHP version to update to, how to check if you are at risk, and how serious it is

If your site runs on shared hosting, your host applies the PHP2Shell fix: check that you are on PHP 8.2 or later and email them for confirmation. If you run your own server, you have to update PHP yourself, today. The official fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, but on Ubuntu the version number never changes, even after the fix. That is why many people are checking the wrong number.

PHP2Shell is the PHP vulnerability found with the help of GPT-5.6 Sol, and PHP runs 70% of websites. After my first Short on the flaw, a lot of you sent me questions. Here I answer all of them, in the same order as the video:

1. Which PHP version to update to, and who has to do it.
2. How to check whether you are at risk, even when the version number seems to say otherwise.
3. How serious it really is: the three most common objections.
4. Why PHP announced the flaw before the fix.
5. Why we will see more and more flaws like this one, found with AI.

If you first want to understand what PHP2Shell is and what an attacker can do with it, I explained the flaw and the first steps to protect your site here.

Which PHP version should I update to for PHP2Shell?

In my first Short I said to update to at least 8.2. That is a good starting point, but it is not enough: the right number depends on who gave you PHP. There are three cases.

Case 1: the site is on shared hosting

On shared hosting, such as Aruba, Hostinger or SiteGround, you don’t install PHP: the host manages it, and the host has to apply the PHP2Shell fix. You can do two things:

• in your hosting control panel, check that you are on PHP 8.2 or a newer version;
• email your host and ask whether they have already applied the fix.

Many of you told me your host updated everything within a few hours, and that is very likely. Asking costs nothing, though, and a written answer removes any doubt. This is the email I prepared, ready to copy:

Subject: PHP2Shell fix

Hello,
my website is hosted on your service.
Can you confirm that the PHP version it uses already includes the fix
for PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?
If it doesn't, when will you apply it?

Case 2: your own server, PHP from php.net or Docker

If you have your own server, for example a VPS (Virtual Private Server), and you installed PHP from the official PHP website or run it in an official Docker container, the version number matters. The fixed versions PHP released on October 21, 2026 are:

• 8.2.35
• 8.3.36
• 8.4.27
• 8.5.12

or later. If you are on a version older than 8.2, there is no fixed version ready to install: you have to move to 8.2 or newer. For 7.4, 8.0 and 8.1 the PHP team only published minimal fixes to compile by hand, meant for people who build PHP themselves.

Will updating PHP break my site?

Updating PHP only breaks a site when you change major version. Going from 8.2.20 to 8.2.35 is like installing a security update on your phone: it only contains fixes and nothing breaks. Going from PHP 7 to PHP 8 is like moving from Windows 10 to Windows 11: some parts of the site can stop working.

In that case, run the update on a copy of the site first, check that everything works, and only then apply it to the live site. Alternatively, ask whoever built the site for you.

The CloudPanel exception

I have a VPS on Hostinger, and on the night of October 21 Hostinger sent me an email about the flaw. It says that if you installed CloudPanel on your VPS, the panel many people use to manage a VPS, the automatic updates do not include the PHP2Shell fix. With CloudPanel you have to install the patch by hand.

Case 3: your own server, PHP installed from Ubuntu packages

If your server runs Ubuntu and you installed PHP from Ubuntu’s packages (sudo apt-get install php), the version number never changes. Ubuntu takes the fix and puts it into the package you already have. On my VPS, before and after the update, PHP always reported 8.3.6. Only the last part of the package name changes.

So on Ubuntu, if you look for version 8.3.36, you will never find it, even though you are already protected. The fixed package versions, according to Ubuntu’s security page, are:

• Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13
• Ubuntu 22.04: 8.1.2-1ubuntu2.28
• Ubuntu 20.04, Ubuntu Pro only: 7.4.3-4ubuntu2.29+esm5

Debian behaves differently and moves to the new number: according to the Debian security tracker, the fixed package is 8.2.35-1~deb12u1 on Debian 12 and 8.4.27-1~deb13u1 on Debian 13.

How do I check whether my PHP is vulnerable to PHP2Shell?

On your own server, the simplest way is to ask Claude Code to check the installed package. OpenAI’s free tool on GitHub is useful, but it only looks at the version number, and on Ubuntu the number doesn’t change. I tested this on my VPS.

The test on my VPS

On my Ubuntu 24.04 VPS I deliberately installed the PHP version Ubuntu shipped before the fix. Then I ran these commands, in order:

php -v
node phpcheck.js --local
sudo apt-get install --only-upgrade php8.3-cli php8.3-common php8.3-opcache php8.3-readline
php -v
node phpcheck.js --local

Here is what happened:

1. php -v reports PHP 8.3.6, built on April 15, 2024.
2. OpenAI’s tool reports VULNERABLE: PHP 8.3.6. Correct.
3. I update the PHP packages: on Ubuntu one command is enough, and package 8.3.6-0ubuntu0.24.04.13 arrives.
4. php -v reports PHP 8.3.6 again, but the build date is now October 19, 2026.
5. OpenAI’s tool still reports VULNERABLE: PHP 8.3.6.

Same version number, different date. PHP was rebuilt with the fix, but OpenAI’s tool only looks at the number, so it doesn’t notice. The tool’s README states this limit too: HTTP headers cannot tell whether a version contains a fix backported by the distribution. And if the tool answers UNKNOWN, that doesn’t mean you are safe: it means it couldn’t tell.

The prompt I gave Claude Code

I also had Claude Code run all these checks, with Opus 5.5 at medium effort, using a single sentence (I wrote it in Italian; this is the translation):

Check whether the PHP installed on this server is vulnerable to PHP2Shell and, if it is, fix it.

Claude Code looked up on its own what PHP2Shell is and what the fix for Ubuntu 24.04 is. Then it analyzed the system, saw that the installed package was not the fixed one, and updated only the four php8.3 packages, without touching the rest of the server. At the end it explained on its own: “php -v still shows 8.3.6, and that’s normal: Ubuntu applies the fix without changing the version number.”

On your own server this is the simplest way to fix the problem, and it is the one I recommend. If you don’t want to type the commands yourself, ask Claude Code for them. On a server with a real site, after the update you also need to restart the process that runs PHP, for example PHP-FPM or Apache.

On shared hosting with WordPress

In WordPress, the PHP version is under Tools › Site Health › Info › Server. The same caveat as Ubuntu applies there: some hosts fix the flaw without changing the version number. That is why emailing your host remains the safest way to know whether your site is protected.

How serious is PHP2Shell really?

PHP2Shell is serious enough to update today. Under my videos someone accused me of fearmongering, and some of the objections were serious. I’ll take them one at a time.

“Passwords are encrypted”

Your site’s user passwords are usually stored in a way that can’t be read, even if someone gets into the database. But the site needs other passwords to work: the database password, the API keys for payments, the API keys for email. Those are written in plain text in the site’s files, because the site itself has to read them.

PHP’s official advisory describes the impact as unauthenticated remote code execution as the account that runs the site. Whoever exploits PHP2Shell gets the same permissions as the site, so they can read those keys.

“If the site runs in a container or with limited permissions, we’re fine”

A Docker container or a user with limited permissions stops the attacker from taking over the rest of the server. Both are excellent practices. Inside that container, though, sits your site, with its files and its keys. The container protects the other sites on the same server, while the site under attack stays exposed.

“It can only be exploited in a lab”

The answer is in PHP’s official advisory. On Apache with mod_php, in the default configuration, the full attack was demonstrated over the internet, without a password. On PHP-FPM, the setup of many servers running Nginx, source analysis says the flaw is there, but nobody has demonstrated a full attack yet. And Cloudflare said it had already seen the first attack attempts against the sites it protects.

The verdict

PHP says it in its official advisory: updating to a release with the fix is the only complete mitigation. Everything else reduces the risk without removing it.

Why did PHP announce the flaw before the fix?

PHP announced the flaw one day before the fix because it follows coordinated disclosure: a public heads-up, with no details, lets server administrators get ready and install the fix as soon as it ships. This is how it works:

1. whoever finds the flaw reports it privately to the software’s maintainers;
2. together they prepare the fix in secret;
3. meanwhile, Linux distributions such as Ubuntu and Debian are warned privately and prepare their packages;
4. a few days or one day before the release, a public heads-up arrives: “a critical fix is coming, get ready”, without saying where the flaw is;
5. the fix ships, together with the details.

For PHP2Shell, the timeline according to Wiz and php.net is:

• August 19, 2026: Wiz finds the first flaw;
• August 24: Wiz reports it to the PHP security team;
• September 21: PHP starts developing the coordinated fix;
• October 19: Ubuntu already has the fixed package ready, before the announcement (it is the build date I saw on my VPS);
• October 20: PHP’s public heads-up, with the release set for October 21 at 14:00 UTC, 4 pm in Italy;
• October 21: the fixed versions ship, about two months after the report.

The flip side is that as soon as people know a flaw this serious exists, many start hunting for it. PHP knew this: in the heads-up it reserved the right to release earlier if the details became public or attacks appeared.

This time, that is exactly what happened. The technical details leaked before the planned release, and from the reconstructions I have done so far, the first attack attempts had already started when the patches came out. In this case the heads-up came at a price, even though it limited the damage.

Once the fix was out, the distribution packages arrived quickly: someone told me that by 6 pm they had already updated all their packages on Debian.

Why will we see more flaws like PHP2Shell?

PHP2Shell was found with the help of artificial intelligence. Many analysts used GPT-5.6 Sol to find it, and Wiz says it also used Gemini. The flaw surfaced inside Patch the Planet, OpenAI’s program for open source software security: Greg Brockman, OpenAI’s president, wrote this.

Within Patch the Planet, according to Trail of Bits, which runs it with OpenAI, hundreds of vulnerabilities in other software had already been found in the first week. AI models can now find flaws in software we have used for years, and they do it more and more often.

That is why we will see many more flaws like PHP2Shell. If you run a site, knowing who updates your PHP and how to verify it will come in handy next time too.