PHP2Shell: what to do now with your WordPress or Laravel site

Status: 21 October 2026, 13:30 UTC. PHP publishes the fix today at 14:00 UTC (16:00 CEST, 21:00 Bangkok). We will update this post with the fixed version numbers and update commands as soon as they are out.

Two critical security bugs in PHP leaked on 20 October, before a fix was ready. They are called PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619. PHP's own security team rates them 9.2 out of 10. An attacker can send one crafted request to your website and run their own code on your server, without a password. Attacks have already started. In the Netherlands, the House of Representatives, the National Cyber Security Centre and Tweakers took their sites offline as a precaution.

If your website runs on PHP, this is about you. That includes almost every WordPress and WooCommerce site, every Laravel app, and Magento, Shopware and Drupal. Here is what to do, in order.

What is going on, in plain words

The bugs are in PHP itself: in how PHP reads file uploads (multipart/form-data requests) and the session upload progress feature, before your website's own code even runs. That is why updating WordPress or plugins does not help. Reports say every PHP version from 5.4 up may be affected. PHP officially supports only 8.2 and newer, so older versions will probably not get a fix.

Your situation	What to do	How urgent
Shared or managed hosting (most WordPress sites)	Check your host's status page; ask when they patch and which PHP version you run	Today
Your own server, VPS or cloud instance	Install the PHP update as soon as it is out; protect the server until then (see below)	Today
Docker or container setup	Rebuild the image on the patched PHP base image and redeploy	Today
PHP 8.1 or older	Upgrade to PHP 8.2 or newer; keep the site locked down until then	Today, and plan the upgrade
Webshop or site with customer data that you can't patch today	Put it in maintenance mode or allow only page views (GET requests)	Now

Step 1: make a backup now

Make a full backup of your files and database, and store it somewhere other than the server itself. If something goes wrong in the next hours, a clean backup from before is the fastest way back.

Step 2: protect the server until the fix is installed

None of these fix the bug, but they make an attack harder:

• Turn off upload progress. In php.ini set session.upload_progress.enabled = 0 and session.use_strict_mode = 1, then restart PHP-FPM or your web server.
• Close the back door. If you use Cloudflare or another CDN, let your server accept traffic only from that CDN's IP ranges. Their firewall rules only help when attackers can't reach your server directly.
• Block uploads where you don't need them. Rejecting multipart/form-data requests in nginx or Apache stops this attack, but also breaks file uploads and some forms and checkouts. Test first.
• Take high-risk sites offline. For a webshop or a site with customer data that you can't patch today, a maintenance page is safer than staying online. You can also allow only GET and HEAD requests so pages still load.

Don't install unofficial "fix" plugins or paste snippets from forums. They can make things worse.

Step 3: install the PHP update

PHP publishes the fixed versions today at 14:00 UTC. We will add the exact version numbers and update commands here as soon as they are out.

Step 4: check whether someone got in

The bugs were public from 20 October, so a server that was online and unpatched may already have been hit. After patching, check:

• New or changed .php files in upload folders: wp-content/uploads for WordPress, storage/ and public/ for Laravel.
• Admin users you don't recognise, in WordPress or in your hosting panel.
• New cron jobs or scheduled tasks.
• WordPress core files that changed recently, and redirects to sites you don't know.

Found something? Don't just delete the strange files. Restore a clean backup from before 20 October, patch, and change every password: admin, hosting, database, SFTP and API keys. If you use UpdraftCentral, also remove its dashboard keys: attackers are using leaked keys to plant backdoors, a separate problem that is active right now.

After this week

• Keep PHP on a supported version (8.2 or newer) and update it as part of normal maintenance, not only during a crisis.
• Make sure your server only accepts web traffic on ports 80 and 443. Databases and admin ports should never be open to the whole internet.
• Keep daily backups outside your hosting account, and test a restore once.
• Write down who hosts your site, which PHP version it runs and who can log in. This week showed how much time that saves.

Need help today?

We run this checklist for clients today. If you don't want to do it yourself, or your site runs on an old PHP version, our emergency help is made for this: a senior developer starts the same day, patches your server, closes what shouldn't be open, checks for a break-in and tells you what they found.

Sources: Sansec, Patchstack, CERT-EU via The Next Web, NL Times.