← All posts
Web security

PHP2Shell: what does this critical PHP flaw mean for your website?

The PHP team has released an update for two critical vulnerabilities in PHP. In news reports they are called PHP2Shell. PHP is the programming language behind a large part of the internet: WordPress, many web shops, customer portals and countless custom-built websites run on it. A critical flaw in PHP therefore doesn’t affect one product, but an enormous number of websites at once.

In this blog we explain what is going on, who is at risk and what you should do now.

What is going on?#

On 21 October the PHP team released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities, each scoring 9.2 on CVSS v4.0, which according to the PHP team can allow running code on the server without logging in. The PHP team urges everyone to update immediately (security advisory on php.net).

These are the two flaws:

  • CVE-2026-109618: running code through a memory error. When PHP unexpectedly runs out of memory, it can be interrupted halfway through a request. While cleaning up, PHP may then treat the half-built data as valid (technical advisory).
  • CVE-2026-109619: running code through leftover data. Data belonging to a request can survive after its memory has already been freed. A later request handled by the same process may then use that stale data (technical advisory).

Unusually, details about the flaws leaked online before the update. Security company watchTowr confirmed at the time that the flaws were real. On the morning of the release, watchTowr and Huntress had not yet seen any exploitation in the wild, but Sansec expected mass exploitation to start within fifteen minutes of the update (SecurityWeek). Now that the update is out, acting quickly matters.

Who is at risk?#

According to the PHP team, all PHP installations that serve web requests, whether through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. The risk is highest with mod_php: there, an attack has been demonstrated in which a request without logging in triggers the flaw, before a single line of the website itself runs.

That last point matters. The flaw is in PHP itself, not in your website. A fully up-to-date WordPress site with the latest plugins therefore offers no protection as long as PHP itself has not been updated.

Systems that run on PHP include:

  • WordPress websites, including all plugins and themes;
  • web shops built on PHP;
  • customer portals, intranets and admin environments from suppliers;
  • custom applications written in PHP;
  • old servers that were set up once and then forgotten.

That last one is a big risk. A forgotten test environment, an old subdomain or an admin page from a previous supplier often no longer gets updated, which makes it exactly what attackers look for.

Websites that don’t run PHP on the server, such as static websites, are not vulnerable to this flaw through their website. If such a website does have a back-end running on PHP behind it, that back-end needs to be updated just the same.

What risk do consumers run?#

The flaw is on the server of a website, not on the computer or phone of its visitors. Consumers therefore can’t update anything themselves. But if an attacker takes over the server of a web shop or website through this flaw, that can affect the customers of that website. An attacker with access to the server could, for example:

  • steal customer data stored on the server, such as names, addresses, email addresses, order history and encrypted passwords;
  • quietly change the website, for example by adding code to the payment page that sends entered payment details to the attacker;
  • redirect visitors to a fake website or serve them malware.

What can you do as a consumer?

  • Be alert to messages about an order or account. Stolen customer data is often used for convincing phishing. Be extra careful with emails, text messages or phone calls asking for details or a payment.
  • Use a different password for every website and turn on two-factor authentication wherever you can. A leaked password then gives no access to your other accounts.
  • Check the address bar when paying. If you are sent to your bank to pay, make sure you are really on your bank’s website before you log in.
  • Keep an eye on your bank statements and report unknown transactions to your bank straight away.

For organisations this also means a responsibility towards their customers. If personal data leaks, in most cases this must be reported to the data protection authority within 72 hours of discovery. In the Netherlands that is the Autoriteit Persoonsgegevens.

What should you do now?#

  1. Map out where PHP runs. Not just your main website, but also web shops, portals, test environments and supplier systems. Check with your hosting provider and web developer.
  2. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and long-term support vendors received the fix in advance, so check with them for updated packages. Have your hosting provider confirm the update has been applied, even if they manage it for you.
  3. Running PHP 8.1 or older? Those versions no longer receive updates from the PHP team. Some vendors provide their own fix, but upgrading to a supported version is the real solution. For those who build PHP from source, the PHP team has exceptionally made minimal fixes available for PHP 7.4, 8.0 and 8.1.
  4. Check whether something has already happened. Especially on systems that were updated late: look for unknown new files on the web server, new admin accounts and unusual activity in the logs.
  5. Switch off what you no longer use. Every system that is no longer needed but still running is an extra way in for attackers.

For administrators: can’t update right away?#

The PHP team is clear: only updating is a complete solution. The temporary measures in the security advisory only block specific attack paths and do not make an installation safe. A short explanation per flaw:

Flaw 1, CVE-2026-109618: a memory error

According to the advisory, PHP can be interrupted when it runs out of memory while it is still building up the data of a request. The measures make it harder to cause exactly that memory shortage:

  • memory_limit=-1 turns off PHP’s own memory limit, so an attacker can no longer deliberately push a request over it. Set it with php_admin_value in the FPM pool or Apache configuration, so applications can’t undo it. According to the advisory, a real out-of-memory situation on the server can still reach the vulnerable path, and it recommends a memory limit at the container or cgroup level. Without such a limit, a single heavy request can use a lot of the server’s memory.
  • Set post_max_size low, according to the advisory 8M if the application doesn’t need file uploads and otherwise 32M. This limits how much data PHP reads from a single request. Larger uploads will no longer work.

Flaw 2, CVE-2026-109619: leftover data

A web server keeps a number of PHP processes (“workers”) running that handle one request after another. According to the advisory, data from a request can linger in such a process and be used by a later request. The PHP team names two confirmed paths:

  • session.upload_progress.enabled=0 turns off the feature that tracks upload progress, for example for a progress bar. According to the advisory this setting must be active before PHP reads the request: set it in php.ini or the FPM pool, not through ini_set() or .user.ini. Progress bars that rely on this feature will stop working.
  • fatal_error_backtraces=0 (PHP 8.5 only) turns off the overview of active functions on a fatal error. Building that overview is, according to the advisory, the second confirmed path.

Restart all workers after these changes, as the advisory says. Otherwise running processes keep using the old settings.

Using remirepo?

rpms.remirepo.net is a volunteer-maintained repository that many administrators use to install newer PHP versions, for example on Red Hat and Fedora. According to the PHP team, it will not have updates on the day of the release. Switch to your distribution’s packages or build PHP from source.

Why this is about more than one update#

The update for PHP2Shell is out now, but the next critical flaw is guaranteed to come. The organisations that respond fastest and safest are the ones that know exactly which systems they have and how those are exposed to the internet.

That is where a pentest helps. We map out which systems are reachable from the outside, including the ones you have lost track of yourself, and test how far an attacker really gets. You receive a clear report with concrete improvements, so that with the next flaw you don’t have to go searching, but know straight away what to do.

Melis IT Solutions
Jeremy Melis21-10-2026