Skip to content
Journal

PHP2Shell: how to check your website

Two critical holes in PHP were closed on 21 October 2026. How to find out whether your website has the fix, what to ask your web host, and why updating plugins does not help.

4 min read#php#security#wordpress#maintenance

On 21 October 2026 the PHP project released emergency fixes for two critical security holes, nicknamed PHP2Shell. PHP is the language WordPress, WooCommerce, Joomla, Drupal, Magento and Laravel run on, so this concerns most small business websites in Denmark. This note explains what happened, how to see whether your site has the fix, and what to ask your web host. Updated 22 October 2026.

What is PHP2Shell?#

Two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. They sit in how PHP handles a request, before the website's own code runs, and an attacker needs no login to use them. According to PHP, every setup that serves web pages is affected: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed and FrankenPHP.

The details leaked before the planned release, and exploit code was public within hours. Amazon and watchTowr report attacks against their honeypots; CISA had not confirmed attacks when this was written.

Does my website use PHP?#

  • WordPress, WooCommerce, Joomla, Drupal, Magento, PrestaShop: yes.

  • A custom site or app built in Laravel or Symfony: yes.

  • Shopify, Wix, Squarespace and similar closed platforms: not your job. The platform runs its own servers and patches them.

If you are not sure what your site is built on, ask whoever built it, or your web host.

How do I see which PHP version my website runs?#

  • In WordPress: Tools → Site Health → the Info tab → Server. It shows the PHP version.

  • At your web host: most control panels show the PHP version per site, often under a setting called "PHP version" or "PHP settings".

  • From outside: some servers announce their PHP version to every visitor. The free website check reads it when they do.

One catch: Linux distributions and some hosts put the fix into the version they already run, without changing the number. A low number therefore does not prove the fix is missing, and only the host can confirm it.

Which versions have the fix?#

  • PHP 8.5.12

  • PHP 8.4.27

  • PHP 8.3.36

  • PHP 8.2.35

PHP 8.1 and older no longer get official fixes. A site on PHP 7.4, 8.0 or 8.1 should move to a supported version, whatever the host has done.

What to ask your web host#

Most web hotels patch PHP themselves, and many did on 21 October. Ask anyway, in writing, and keep the answer:

  • Is the PHP running my site patched against CVE-2026-109618 and CVE-2026-109619?

  • Which PHP version does my site run, and is it a supported version?

  • When were the PHP processes restarted after the update?

The last question matters because a fix only takes effect once PHP has been restarted.

Why updating plugins does not help#

Plugins, themes and WordPress itself are the website. PHP is the program on the server that runs it. PHP2Shell is a hole in that program, so pressing "update all" in WordPress changes nothing here. The fix has to be installed where the site is hosted.

Still on PHP 7.4 or 8.1?#

Then the upgrade is the real fix, and it is usually smaller than people fear. The order I use:

  1. Take a full backup of files and database.

  2. Update WordPress, the theme and the plugins while still on the old version.

  3. Switch a copy of the site, or the site itself at a quiet hour, to PHP 8.3 or 8.4.

  4. Click through the pages that earn money: the contact form, the booking, the checkout.

  5. Replace the plugins that break. They are usually the ones nobody has updated in years.

For most small sites that is an afternoon of testing, not a new website. A site built by an agency that has since gone quiet is harder; I wrote about taking over a WordPress site from a previous agency and about a Laravel app whose developer left.

If you run your own server#

Update PHP from your distribution's packages and restart PHP-FPM or Apache. If that cannot happen today, the PHP project lists stopgaps: memory_limit=-1, set so applications cannot change it, and session.upload_progress.enabled=0 (on PHP 8.5 also fatal_error_backtraces=0). They are not a fix, and they need a restart too.

If the site was exposed#

A server that ran an unpatched PHP after 21 October may have been attacked without anything looking wrong. Dansk Industri advises looking for unusual activity, many errors or unexpected restarts, and changing the passwords and keys the server had access to: the database, email sending, payment.

Sources#

I will update this note if the fixed versions or the reports of attacks change.

Was this useful?

More notes