Skip to Content
← All articles
Security alerts

PHP2Shell vulnerability: does it affect your website and what to do

Two critical flaws in PHP let a stranger run code without a password. Fixes came out on 21 October 2026, and only a new version reliably helps.

Team Lumenax Oct 25, 2026 · 10 min read
PHP2Shell vulnerability: does it affect your website and what to do
October 25, 2026 by
PHP2Shell vulnerability: does it affect your website and what to do
Roman Jonas
PHP code on a dark screen
Photo: Pixabay, Pexels

If your website or online shop runs on a PHP version older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35, a stranger can run their own code on it, and no password is needed. The PHP team released fixed versions on 21 October 2026. Both flaws, CVE-2026-109618 and CVE-2026-109619, have a CVSS v4.0 score of 9.2 in the CVE record. Only a new PHP version reliably helps.

Key takeaways
  • The fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026.
  • Both flaws score 9.2 in the CVE record and allow running foreign code without a password.
  • On Debian and Ubuntu the version number is not enough, the full package number decides.
  • php.ini settings do not secure the server, the PHP team calls only a new version a complete fix.

WordPress, Joomla, Drupal and PrestaShop, for example, are built on PHP. If your company website runs on one of them, check your server. Programs written in another language are not affected. The media call the pair of flaws PHP2Shell, and NÚKIB uses the same name.

Who PHP2Shell affects

The PHP team wrote that every PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It sees the highest risk in mod_php. A demonstration exploit exists for it that a single unauthenticated request can trigger before the website's own code runs. A WordPress security plugin therefore does not help.

Technician's hands on a keyboard at a computer in a server room
Whoever manages the server has to deploy the fix: you, your host, or the platform operator. Photo: panumas nikhomkhai, Pexels

The 8.5, 8.4, 8.3 and 8.2 branches got the fix. PHP 8.1 and older receive no fixes from the PHP project. The PHP team did publish minimal source-code fixes for 7.4, 8.0 and 8.1, which you have to compile yourself. Ubuntu also fixes the old php5, php7.0, php7.2 and php7.4 packages, but only through the paid Ubuntu Pro.

Watch out for 8.1. The Drupal 10 and PrestaShop 9 pages still list it as supported, but the PHP project released no fixed version for it. A website on PHP 8.1 therefore waits for a package from your supplier, or for a move to a newer branch.

If your website runs on a hosted platform, you do not manage the server. The operator has to deploy the fix, so ask whether they have done it.

It affects youYour website or shop runs on PHP older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35, for example on WordPress, Joomla, Drupal or PrestaShop.
Ask your administratorYour website runs on hosting or a hosted platform. Write to them and ask for the exact package version and the deployment date.
It does not affect youThe program is not written in PHP, or the PHP on the server is already fixed. Check the full package number, not just the branch.

How to check whether you have a fixed version

There is one trap. Linux distributions carry fixes over into their own packages and leave the version number as it was. On Ubuntu 24.04 the command php -v shows 8.3.6, which looks old, yet the fixed package is 8.3.6-0ubuntu0.24.04.13. The full package number decides, not the first three digits.

The version number can mislead. Ubuntu 24.04 shows 8.3.6 even after the fix. The fixed package is 8.3.6-0ubuntu0.24.04.13.
  • Debian 12: php8.2 in version 8.2.35-1~deb12u1 or newer (DLA-4848-1). Version 8.2.32-1~deb12u1 is vulnerable.
  • Debian 13: php8.4 in version 8.4.27-1~deb13u1 or newer (DSA-6574-1). Version 8.4.24-1~deb13u1 is vulnerable.
  • Ubuntu 26.04 LTS: php8.5 in version 8.5.4-0ubuntu1.5 or newer.
  • Ubuntu 24.04 LTS: php8.3 in version 8.3.6-0ubuntu0.24.04.13 or newer.
  • Ubuntu 22.04 LTS: php8.1 in version 8.1.2-1ubuntu2.28 or newer.
  • PHP compiled from source or from official builds: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

On a server with Debian or Ubuntu you can find the version with the command apt list --installed 'php*'. After updating, restart PHP-FPM or Apache, because until the restart the old version keeps running in memory.

On shared hosting the admin panel shows only the PHP branch, say 8.3. Write to your host and ask for the exact package version and the date they deployed it.

What happened and how the flaws work

On 20 October 2026 the PHP team announced that it would release a fix for two flaws with CVSS 9.2 on 21 October at 14:00 UTC. It added that it would release earlier if the details leaked or attacks began. The CVE records were published on 21 October at 13:48 and 13:54 UTC.

CVE-2026-109618 arises when memory runs out. PHP interrupts the handling of a request at a moment when the request's internal data is only half set up, and the cleanup after the request then treats it as valid. CVE-2026-109619 concerns an internal state that outlives the moment PHP frees the memory it points to. The next request handled by the same process uses it before the state is reset.

The vector in the CVE record describes a network attack with no password and no user interaction, but with high complexity (AC:H) and conditions on the target's side (AT:P). The score is 9.2.

What to do if you cannot update right away

The PHP team is clear: these steps reduce the risk on specific attack paths, but they do not make the server safe.

  • Against CVE-2026-109618: set memory_limit=-1 so that the website cannot override it, for example through php_admin_value in the FPM pool or in the Apache configuration. Lower post_max_size to 8M if the website accepts no files, otherwise to 32M, and keep upload_max_filesize below it. Do not use RLIMIT_AS or RLIMIT_DATA, because they trigger the flaw.
  • Against CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or in the FPM pool and restart all processes. It does not work through ini_set() or a .user.ini file. On PHP 8.5 also add fatal_error_backtraces=0. The PHP team states explicitly that this closes only the confirmed paths, not the other variants.

A memory limit of -1 has a price, and this is our own judgement: one faulty script can then take the memory of the whole server. The PHP team therefore recommends guarding the limit one level higher, with a container or cgroup limit that kills only the affected process.

PHP2Shell in datesAccording to php.net, the CVE records, NÚKIB and watchTowr.
  1. 20 Oct 2026Advance noticeThe PHP team announced a fix for two flaws with CVSS 9.2.
  2. 21 Oct 2026CVE records and fixesThe records came out at 13:48 and 13:54 UTC, the fixes at 14:00 UTC.
  3. 21 Oct 2026NÚKIB noticeThe agency advised not to put off the fix.
  4. 21 Oct 2026First attacks according to watchTowrThe firm caught them in its honeypot network.
  5. 23 Oct 2026A third flawThe PHP team warned about CVE-2026-115560, an unlikely path.
  6. 31 Dec 2026End of support for PHP 8.2The 8.2 branch stops receiving security fixes.

Is PHP2Shell being exploited already?

Yes, according to the security firm watchTowr. It writes that it caught attacks in its network of decoy systems (honeypots) from 21 October 2026. Official sources do not confirm this yet. In the CVE record of 21 October, CISA gives the exploitation value as "none", and the CISA catalogue of actively exploited vulnerabilities (version 2026.10.23) lists neither flaw. How widespread the attacks are cannot be learned from public sources as of 25 October.

On 21 October 2026 NÚKIB urged companies not to put off the fix, and wrote that information that allows the flaws to be exploited is publicly available. According to the agency, unusual processes started by PHP services may point to an exploitation attempt.

On 23 October the PHP team also warned about a third flaw, CVE-2026-115560. It occurs only when a website's code sets the session handler to php_binary or php_serialize and, at run time, switches it to php through ini_set() before session_start(). The same step as for CVE-2026-109619 helps, so whoever has already taken it does not need to do anything. The PHP team promised the full description with the next regular version.

Companies that NIS2 targets

If your company falls under Act No. 264/2025 Coll., which transposes NIS2, and an attacker exploited the flaw on your server, the deadlines under section 16 are running. You file the initial report within 24 hours of the moment you detect the incident. For an incident with a significant impact, a notification is due within 72 hours and a final report within 30 days of it. Companies in the lower regime report to the National CERT only incidents with a significant impact on the service. Who falls under the act is explained in the article on NIS2 and the new act and on the NIS2 page. The act allows vulnerabilities to be reported voluntarily as well.

And one date for the calendar: PHP 8.2 stops receiving security fixes on 31 December 2026. Whoever installs 8.2.35 now faces another move in two months, so it pays to go straight to 8.4 or 8.5.

Common questions

Is it enough to update WordPress and plugins?

No. The flaw is in PHP itself, not in WordPress. With mod_php the attack runs before WordPress code starts to execute. You have to update PHP on the server.

My hosting shows PHP 8.3. Am I safe?

You cannot tell from the 8.3 branch. The fixed upstream version is 8.3.36, and on Ubuntu 24.04 the package 8.3.6-0ubuntu0.24.04.13. Ask your host for the exact package version.

We have PHP 7.4. What now?

For 7.4 the PHP project released only a minimal source-code fix, not a finished version. You can compile it yourself, use a supplier with extended support, such as Ubuntu Pro for php7.4, or move to a supported branch. In the long run only the last option makes sense.

Does it also affect scripts run from the command line?

The PHP team names PHP that serves web requests. Still, update all PHP packages on the server at once, so that no old version stays in any of them.

How do I know whether someone has already got into our server?

There is no simple test. Look in the web server log for unexpected crashes of PHP processes and out-of-memory errors, new PHP files in the web directory and unknown processes. If you find something, have the server examined by an expert and do not delete the logs. If you do not know what runs on your servers, a penetration test helps.

Sources

  • PHP: Security advisory: Critical remote code execution vulnerabilities, 21 Oct 2026, Upcoming Critical PHP Security Release, 20 Oct 2026, and Informational advisory: Session upload progress, 23 Oct 2026: https://www.php.net/archive/2026.php
  • PHP: Supported Versions, viewed 25 Oct 2026: https://www.php.net/supported-versions.php
  • CVE-2026-109618 and CVE-2026-109619, CVE records, published 21 Oct 2026, modified 23 Oct 2026: https://www.cve.org/CVERecord?id=CVE-2026-109618
  • NVD, CVE-2026-109618, modified 23 Oct 2026: https://nvd.nist.gov/vuln/detail/CVE-2026-109618
  • NÚKIB: NÚKIB upozorňuje na kritické zranitelnosti v PHP (NÚKIB warns of critical vulnerabilities in PHP), 21 Oct 2026: https://nukib.gov.cz/cs/infoservis/aktuality/2470-nukib-upozornuje-na-kriticke-zranitelnosti-v-php
  • CISA: Known Exploited Vulnerabilities Catalog, version 2026.10.23: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  • watchTowr: PHP2Shell FAQ, updated 23 Oct 2026: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
  • Debian Security Tracker, CVE-2026-109618, viewed 25 Oct 2026: https://security-tracker.debian.org/tracker/CVE-2026-109618
  • Ubuntu Security, CVE-2026-109618, viewed 25 Oct 2026: https://ubuntu.com/security/CVE-2026-109618
  • WordPress, Requirements, viewed 25 Oct 2026: https://wordpress.org/about/requirements/
  • Drupal, PHP requirements, viewed 25 Oct 2026: https://www.drupal.org/docs/getting-started/system-requirements/php-requirements
  • Joomla, Technical requirements, viewed 25 Oct 2026: https://manual.joomla.org/docs/get-started/technical-requirements/
  • PrestaShop 9, System requirements, viewed 25 Oct 2026: https://devdocs.prestashop-project.org/9/basics/installation/system-requirements/
  • Act No. 264/2025 Coll., sections 15 and 16: https://www.zakonyprolidi.cz/cs/2025-264
Team Lumenax

We write about security, AI and software for Czech companies with 10 to 100 people.

Penetration testing
You may also like
Free CRM: when it's enough and when it costs more than a paid one Free CRM: when it's enough and when it costs more than a paid one Ollama: how to run local AI over your own company data Ollama: how to run local AI over your own company data Jak se připravit na penetrační test Jak se připravit na penetrační test
Free CRM: when it's enough and when it costs more than a paid one
Where the limits of the free plans of HubSpot, Zoho and Odoo lie and what to check before you load history into a CRM. Figures of 25 October 2026.