PHP "php2shell" vulnerabilities: what happened and what to do now

In short: on 21 October 2026 PHP released emergency security updates for two critical flaws, now nicknamed "php2shell" (CVE-2026-109618 and CVE-2026-109619). Both are rated 9.2 out of 10 and can let an attacker run their own code on a server without logging in. If your website runs on PHP (that includes WordPress, WooCommerce, Laravel, Drupal, Magento and most shared hosting) the server needs to be on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. Updating WordPress or your plugins does not fix it; the PHP version on the server has to change.

This guide explains what happened in plain English, how to check whether your site is safe, and exactly what to do, whether you are on shared hosting, managed WordPress or your own server. It reflects what was public on 24 October 2026; we will update it as PHP publishes more details.

What happened, day by day

• 20 October: a post on a public forum claimed two "CVSS 10" remote code execution flaws in PHP would be disclosed on 22 October. Security firm watchTowr then confirmed the leak was real and the flaws were under embargo. The same evening PHP announced an out-of-cycle security release for the next day (The Hacker News, Drupal PSA-2026-10-20).
• 20 October: some hosts did not wait. SiteGround, for example, switched off the affected PHP functionality on all its servers before the fix was out (SiteGround).
• 21 October: PHP shipped the fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions had received the patches in advance (CERT-EU advisory 2026-018).
• 21–22 October: technical details started circulating publicly, along with early proof-of-concept code. watchTowr and Cloudflare reported early attack attempts (Tanium). At the time of writing, neither flaw had been added to CISA's list of confirmed exploited vulnerabilities, but security teams are treating it as urgent.
• 23 October: CERT-EU updated its advisory with a third, lower-risk flaw, CVE-2026-115560, which will be fixed in PHP's next regular release.

The flaws in plain English

You don't need to understand the internals to protect your site, but here is what is going on, based on CERT-EU's advisory:

The worrying part: a demonstrated attack needs just one request, sent before any of your website's own code runs. That means a perfectly written WordPress theme or Laravel app does not protect you. It is PHP itself that has to be fixed.

Is my website affected?

Almost certainly, if all three of these are true:

1. Your site runs on PHP. WordPress, WooCommerce, Laravel, Drupal, Joomla, Magento, PrestaShop, OpenCart, CodeIgniter, Symfony and most "cPanel" hosting all do.
2. It is reachable from the internet (any public website is).
3. Its PHP version is older than the fixed versions below.

Every common way of running PHP is affected: PHP-FPM, Apache mod_php (rated highest risk), php-cgi, LiteSpeed and FrankenPHP. Software that quietly bundles PHP, such as some control panels and appliances, may be affected too (CERT-EU).

The scale is big: in a scan on 20 October, around 884,000 internet-facing servers showed PHP 8.1 or older, versions that get no official fix (Mallory, via The Hacker News).

How to check your PHP version in two minutes

• WordPress: go to Tools → Site Health → Info → Server and look at "PHP version".
• cPanel / Plesk / hPanel: open "Select PHP Version" or "PHP Settings". Note that the panel often shows only 8.3, not the exact 8.3.36; ask your host if you can't see the full number.
• Your own server: run php -v, and check the version your web server actually uses (it can differ from the command line), for example with a temporary phpinfo() page that you delete straight after.

What to do now

1. On shared or managed hosting (most small businesses)

• Log in to your hosting panel or check your host's status page or email. Many hosts patched or mitigated on 20–21 October.
• If you are on PHP 8.1 or older, switch to 8.3 or 8.4 in the panel today. Test the site afterwards: open the home page, a contact form and checkout if you sell online.
• If you can't confirm the exact version, send your host a short message: "Is my server patched for CVE-2026-109618 and CVE-2026-109619 (PHP 8.x security release of 21 October)?"

2. On your own VPS or cloud server

• Update PHP from your Linux distribution's packages, then restart every PHP worker (for example php-fpm) and the web server. Old workers keep running the old code until restarted.
• Patch internet-facing servers first, then internal ones.
• If you use the Remi repository, PHP noted it would not have updates on release day; use your distribution's packages or build from source.
• Running in Docker? Rebuild your images on the new official PHP image tags and redeploy. An old image stays vulnerable even if the host is patched.

3. If you truly cannot update today (server admins only)

CERT-EU lists temporary measures that lower the risk. They do not make a server safe and should only buy you hours, not weeks:

; php.ini or FPM pool (php_admin_value), then restart all workers
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0
; keep uploads small if you can
post_max_size = 32M
upload_max_filesize = 20M

CERT-EU also suggests strict request-size and header limits at the web server or proxy, and isolating the application from the public internet until it is patched. Settings changed with ini_set() or .user.ini are not enough. A web application firewall in front of the site can help, but it is not a replacement for the update.

Could my site already be hacked?

If your server was on an old version and public between 20 October and the moment you patched, it is worth a quick look. Signs to check:

• New or changed .php files in your website folders, especially in uploads, cache or image folders, with odd names.
• New admin users in WordPress or your app that nobody created.
• New scheduled tasks (cron jobs) or unknown processes started by php-fpm, apache2 or httpd.
• Spam pages appearing in Google, redirects to strange sites, or your host warning about high CPU or outgoing email.

If you find any of these: take a copy of the logs, change all passwords and keys, restore from a clean backup made before 20 October, then patch PHP before putting the site back online.

The bigger lesson: old PHP is a business risk

The fix took minutes to apply for sites on a supported PHP version. The sites in real trouble are the ones nobody has looked after since launch: PHP 7.x or 8.0 that was never upgraded because "it still works". Those sites now have a known, critical hole and no official patch.

Two dates to put in your calendar now: PHP 8.2 stops getting security fixes on 31 December 2026, and 8.4 leaves active support the same day. If your site runs 8.2 or older, plan the move to 8.3 or newer before the new year rather than in a hurry during the next emergency.

This is exactly what ongoing website maintenance is for: keeping the server, PHP version, CMS and plugins updated, watching security advisories, testing updates before they go live and keeping clean backups ready. If you are not sure what version your site runs or who is responsible for updating it, talk to us and we'll check it for you.

Sources

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP (v1.2, 23 Oct 2026)
• The Hacker News: PHP2Shell, two critical PHP RCE flaws (21 Oct 2026)
• Drupal PSA-2026-10-20: critical PHP update
• SiteGround: protecting customers ahead of the PHP security release
• Help Net Security: critical PHP security release
• Tanium: responding to CVE-2026-109618 and CVE-2026-109619