PHP 8.2 gets no security updates from 2027: your options

PHP2Shell: what happened in October

On 20 Oct 2026, details of two critical PHP vulnerabilities became public ahead of schedule: CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. They let an attacker run code on the server without logging in. On 21 Oct 2026 the PHP project released versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For PHP 7.4, 8.0 and 8.1 there are only source patches, no official releases.

According to watchTowr, attacks on the vulnerabilities began on the day the patches came out. PHP itself says no setting protects completely. Only the update is safe. Afterwards every PHP worker has to restart, or the old code keeps running.

How to check whether your server has the fixed version:

# Command line version, fixed from 8.2.35, 8.3.36, 8.4.27 or 8.5.12
php -v

# PHP FPM services on the server (Debian, Ubuntu)
systemctl list-units --type=service 'php*-fpm*'

# After the update: restart PHP FPM, here for PHP 8.2 on Debian
sudo systemctl restart php8.2-fpm

PHP 8.2 still got the fix because it has security updates until the end of the year. Had PHP2Shell become known in January 2027, there would have been no official patch for PHP 8.2.

Found with AI, and not for the last time

Researchers at Calif found the vulnerabilities in August, during an audit of the PHP source code funded by OpenAI. They worked with the GPT-5.6 Sol model. A few weeks later Wiz found the same vulnerabilities independently, also with AI models (The Next Web). Calif stresses that knowing PHP’s history mattered more than the model.

We expect cases like this to become more frequent. AI models read large amounts of code in a short time and relate it to known vulnerabilities and attack patterns. What used to take weeks of manual work now goes much faster, for researchers and attackers alike.

It is no surprise that PHP was hit first. PHP has been around since 1995, and it is very widely used and well documented, bugs included. Versions more than ten years old are affected too (Wikipedia). But this is not specific to PHP: Java, Node.js, Python and the libraries underneath have just as much old code that models now search through. For your systems this means two things. The time between a vulnerability becoming known and the first attack gets shorter. And a version without security updates gets no patch when it matters.

How long a PHP version gets updates

The PHP project maintains each version for two years with bug fixes and security updates. After that, it fixes only critical security issues for two more years. That is what the Supported Versions page on php.net says. For PHP 8.2 this second phase ends on 31 Dec 2026; for PHP 8.1 it has been over since 31 Dec 2025.

If you are on PHP 8.2 today, you have a little over two months. On 8.1 or older, you are already running without updates from the PHP project.

How to find your version

On the server, php -v shows the command line version. PHP FPM can use a different one, so check the PHP FPM services as shown above. A Plesk server often runs several versions side by side, and each domain can use a different one:

# Every PHP version Plesk knows on this server
plesk bin php_handler --list

In the application, the required version is in composer.json:

{
  "require": {
    "php": "^8.2"
  }
}

^8.2 also allows 8.3, 8.4 and 8.5. If it says ~8.2.0 or 8.2.*, the application is pinned to PHP 8.2, and the upgrade takes more than a new server. Composer itself shows whether the PHP version on the server meets the requirements of your dependencies:

composer check-platform-reqs

If your PHP comes from Plesk

Plesk ships its own PHP packages and updates them continuously. According to the Plesk change log, PHP 8.2 moved to version 8.2.35 on 21 Oct 2026. Which versions you can install through the Plesk Installer is listed in the Plesk knowledge base.

On the same day Plesk also shipped the PHP2Shell fix in PHP 8.1.34, although the PHP project no longer supports 8.1. We have not found a firm commitment in the documentation that Plesk always does this for unsupported versions. For those versions Plesk also offers an extension by TuxCare that keeps security updates coming for them. According to Plesk, as of March 2026 it covers PHP 5.6 to 8.1.

If your PHP comes from Debian

Debian 12 ships PHP 8.2 as its own package. Debian fixes vulnerabilities in it as long as Debian 12 itself gets updates: with Debian LTS until 30 Jun 2028. You can find those dates in our EOL calendar. This applies only to the PHP from Debian’s packages, not to PHP from Plesk or another source on the same server.

Three ways forward

1. Upgrade to a supported version

The direct way: PHP 8.4 gets security updates until 31 Dec 2028, PHP 8.5 until 31 Dec 2029. How much work the upgrade is depends on the framework, the libraries and the tests. We check composer.json and the dependencies first, run the tests against the new version and switch staging over before production follows.

2. Use the distribution’s packages

If your application runs on Debian 12, you can stay on Debian’s PHP 8.2 and plan the upgrade before Debian 12 ends. That buys time, but libraries and frameworks will still drop support for PHP 8.2 one by one.

3. Paid long term support

Vendors such as Zend or TuxCare provide security updates beyond the official end. That too buys time for the upgrade, but does not replace it.

If you do not know your versions

The Legacy Check starts with exactly this inventory: which PHP versions you run, where they come from and how long they get updates. It costs EUR 3,900 as a fixed price, and you have the report after ten days. All dates are in the EOL calendar.