A PHP flaw lets attackers into your server without a password.Are you at risk?

Yesterday, 20 October 2026, two of the most serious security flaws ever found in PHP leaked onto the internet ahead of schedule. Today, 21 October, at 14:00 UTC, the PHP team released the fixes. Researchers have named them PHP2Shell.

PHP is the language behind WordPress, WooCommerce, Joomla, Drupal, Magento, OpenCart and countless hand-built websites. If your website or online shop runs on any of these, this article is for you. At the end you’ll find instructions for each setup: WordPress, hosting control panels, your own server and Docker.

9.2out of 10, the severity score (CVSS 4.0)

No password or account needed: one crafted request is enough. According to Wiz, every version since PHP 5.4 has at least one of the two flaws.

What was found, in plain words

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Both let an attacker run their own code on the server, with no password and no account, just by sending a specially crafted request to the website.

• The first (CVE-2026-109618) happens when PHP runs out of memory at the wrong moment, while it’s still setting up a request’s data. The data is left half-built, but at the end PHP handles it as if it were complete. That confusion in memory becomes a way in.
• The second (CVE-2026-109619) is like a restaurant table nobody cleared: an error leaves behind “leftovers” from one request, pointing to memory that has already been freed. The next request handled by the same process can use them before they’re cleaned up.

The most worrying part: on Apache servers with mod_php, the attack can happen before your website’s code even runs. No WordPress security plugin can stop it, because it hasn’t started yet.

The path of a request

1. The visitor (or the attacker)sends a request to the website
2. Cloudflare or another firewallblocks the known forms of the attack
   Only if proxied
3. Web serverApache, LiteSpeed or Nginx
4. PHPthis is where both flaws are
   Vulnerable
5. WordPress, plugins, your codewith mod_php, the attack happens before this layer
   Too late

How it came out early

The flaws had been reported to the PHP team back in August, and the fixes were being prepared for a joint, coordinated release on 22 October. The plan fell apart:

1. 11 August 2026First reportsCalif and OpenAI report the first flaw to the PHP team. Wiz follows on 24 August.
2. 20 October, 15:00The leakThe CVE IDs circulate on forums and social media, with the wrong release time and the wrong score (10/10).
3. 20 October, 19:30The fix moves forwardThe PHP team announces the release will ship a day early.
4. 20 October, 20:00A video of the attackA video showing the attack in action is published by mistake.
5. 21 October, morningFirst attemptsCloudflare and Patchstack report the first attack attempts.
6. 21 October, 14:00The fixes shipPHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Is my website at risk?

Most likely yes, unless it has been updated today. According to the advisory, every PHP installation that serves websites is at risk, however it runs (PHP-FPM, mod_php, php-cgi, LiteSpeed, FrankenPHP).

Series	Safe version
PHP 8.5	8.5.12 or later
PHP 8.4	8.4.27 or later
PHP 8.3	8.3.36 or later
PHP 8.2	8.2.35 or later (supported until 31 December 2026)
PHP 8.1 and older	no official fix

If your website still runs PHP 7.x or 8.1, and many do, no official update is coming. Some hosting companies and Linux distributions ship their own fixes, but the right answer is moving to a supported version.

Are attacks already happening?

The first signs came early: on the morning of 21 October, Cloudflare and Patchstack’s hosting partners reported the first attempts. By the time of the fix, the PHP team hadn’t identified a working public exploit, and most of what was logged was scanning for vulnerable servers. But early proof-of-concept versions of the attack are already circulating, so that picture could change within hours. Treat it as urgent.

How to fix it, depending on where your website runs

The fix always takes four steps: find which PHP version really runs, update it, restart, and check that the change took. How you do it depends on where the website is hosted.

WordPress (on any hosting)

1. Find the exact PHP version: in the WordPress dashboard, go to Tools → Site Health → Info → Server. It shows the full number, e.g. “8.3.36”. If you have WP-CLI, wp --info shows the same.
2. If it isn’t one of the safe versions, update it from your hosting panel (see below) or ask your hosting company to.
3. Before switching PHP series (e.g. from 7.4 to 8.3), take a backup and check that your plugins and theme support the new version. If you can, try it on staging first.
4. Don’t install plugins promising a “PHP2Shell fix”. The flaw is in PHP, not WordPress, and only updating PHP fixes it.
5. Check for new administrators under Users and for unknown plugins. Patchstack also advises removing any UpdraftCentral keys you don’t use, as attacks abusing them to install backdoors are being recorded.

Shared hosting (hPanel, cPanel, Plesk)

On shared hosting, your hosting company updates PHP. In the panel you choose the series (e.g. 8.3) and the host rolls out the fixed version (8.3.36).

• hPanel (Hostinger): Websites → Manage → Advanced → PHP Configuration.
• cPanel: Select PHP Version or MultiPHP Manager, depending on the provider.
• Plesk: Websites & Domains → PHP (PHP Settings) for the domain.

If you’re already on 8.2, 8.3, 8.4 or 8.5, confirm the full version in WordPress (see above) or ask your provider: “Have you rolled out the 21 October PHP releases for CVE-2026-109618 and CVE-2026-109619?” If you’re on 8.1 or older, switch to 8.3 or 8.4 after taking a backup.

Your own server with Ubuntu or Debian

# 1. Update packages
sudo apt update && sudo apt upgrade

# 2. Restart PHP (use your own version)
sudo systemctl restart php8.3-fpm
# or, if you run Apache with mod_php:
sudo systemctl restart apache2

# 3. Check: both must show the fixed version
php -v
php-fpm8.3 -v

If you get PHP from a third-party repository (e.g. ondrej/sury), check that it has already published the fixed version. If it hasn’t, wait or switch to another source for now.

Your own server with AlmaLinux, Rocky or RHEL

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd
php -v

If you use the Remi repository, check that the update is out: it wasn’t available yet on release day.

Docker

# Pull the new PHP image and rebuild the containers
docker compose build --pull
docker compose up -d

# Check inside the container
docker compose exec app php -v

If your Dockerfile pins a specific version (e.g. php:8.3.35-fpm), change it to the fixed one (php:8.3.36-fpm) before building.

Locally, on XAMPP, Laragon or Windows

A PHP that only runs on your computer and can’t be reached from the internet is at much lower risk. Update it anyway with the next release of your tool, or by downloading the new PHP from windows.php.net.

Cloudflare

Cloudflare has already switched on firewall rules for the known forms of the attack, including on the free plan. They only help, though, if traffic really goes through Cloudflare (the “orange cloud” in the DNS settings) and your server accepts traffic only from there. It’s an extra barrier, not a substitute for updating.

Hide your PHP version

Many servers tell anyone who asks which PHP version they run, which helps people looking for vulnerable targets. Check your own website:

curl -sI https://example.com | grep -i x-powered-by

If you see something like X-Powered-By: PHP/8.3.35, set expose_php = Off in php.ini and restart. It doesn’t fix the flaw, but it stops handing information to anyone scanning the internet.

How to tell if you’ve already been attacked

Researchers suggest checking your server logs for:

• unusual file-upload (multipart) requests followed by memory errors or repeated 500 errors,
• oversized or odd-looking PHPSESSID cookies,
• PHP processes restarting for no reason, or launching commands such as sh, bash, curl or wget,
• new, unknown files in the website folder, new scheduled tasks (cron) or new administrators in WordPress.

If you see any of these, assume the server has been compromised: isolate it, keep the logs and change every password stored on it (database, email, API keys). These flaws can also expose memory contents, and those passwords with them.

Forgotten websites are the real risk

An old WordPress site on PHP 7.4 that nobody updates will never get a fix. Sites already on a supported version needed one update today. The rest need a migration, and under pressure. Updating is maintenance, not a luxury.

There’s a second lesson too: less code on the server means fewer places to attack. That’s why, where it fits, I build websites as ready-made static pages, with no PHP or database running on every visit. This website is one of them, and today’s vulnerability doesn’t affect it.

---

Not sure which PHP version your website runs, or whether your hosting company has already updated it? Send me a message: the review of your website is free and I reply within one working day.

Written on the evening of 21 October 2026, with what was known at the time. Sources: php.net, PHP Foundation, Help Net Security, Huntress, Patchstack.