On 21 October 2026 the PHP team released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. This is not a routine update. The releases fix two critical vulnerabilities that, according to the official announcement, can allow unauthenticated remote code execution. The php.net advisory puts it plainly: there are no complete mitigations, and updating is the only safe choice.

If your website runs on WordPress, WooCommerce, PrestaShop, Laravel or any other PHP system, this applies to you. Below I explain what happened, why timing matters so much here, and how to update without taking your shop offline for half a day.

What happened

These are two flaws in the PHP engine itself, not in a single plugin or theme:

  • CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory while handling a request, some internal data is left only partly initialised. Request cleanup then treats it as valid. An attacker can trigger this with a crafted request, for example a form submission.
  • CVE-2026-109619, "RCE via stale global state". State belonging to one request can survive after its memory has been freed. A later request handled by the same worker may then use it. Besides server takeover, this can also leak data from memory.

Both are rated CVSS 4.0 score 9.2 out of 10, which is "critical". Some outlets have started calling them "PHP2Shell"; that name is unofficial.

Who is affected

According to the PHP team: all PHP installations serving web requests. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where the attack has been demonstrated in practice: a single unauthenticated request is enough, and the attack starts before any of your site's code runs.

That matters because it means up-to-date plugins, strong passwords and a WordPress security plugin do not protect you. The problem sits one level lower, in the engine that runs the whole site.

Safe versions:

  • PHP 8.5.12 or later
  • PHP 8.4.27 or later
  • PHP 8.3.36 or later
  • PHP 8.2.35 or later

PHP 8.1 and older will not get a fix from the PHP project. Those versions are end-of-life. Some Linux distributions and LTS vendors ship their own backported patches, but if your host does not, the only way out is moving to a newer version.

Why you should not wait even a week

I know how this looks from a business owner's side: the site works, customers are buying, it'll be fine. With this vulnerability that attitude is unusually risky, for three reasons.

1. The patch is a map for attackers. Once a fix is published, anyone can compare the old and new source code and see what was changed. For serious flaws, automated scanners usually start looking for vulnerable servers within days, sometimes hours. Some security firms already report exploit code circulating and first attack attempts. Those reports are not yet fully confirmed — but there is no point waiting until they are.

2. No login is required. The attacker does not need your admin password or a customer account. All it takes is a server that answers requests from the internet, and every website does.

3. The consequences are severe. Remote code execution is the worst case. An attacker can deface the site, inject a script that skims card details, send spam from your domain or download your customer database. In the EU that last one is no longer just a technical problem: GDPR requires you to report a personal data breach to the supervisory authority within 72 hours. I covered the clean-up process in what to do when your website is hacked.

By comparison, updating PHP on a well-prepared server usually takes a quarter of an hour.

The scale: many sites still run outdated PHP

According to W3Techs (as of 21 October 2026), around 35% of websites using PHP run version 7.x or older, which stopped receiving security fixes long ago. Sites on PHP 8.0 and 8.1, also unsupported, come on top of that.

If your site is in that group, a minor bump will not do. You need to move to a supported branch, and it pays to pick one that will last. PHP 8.2 loses security support on 31 December 2026, so for a bigger migration aim for 8.3, 8.4 or 8.5.

Step 1: Check which PHP version you use

The simplest ways:

  • Hosting control panel. In cPanel, Plesk, DirectAdmin and most hosting panels, the PHP version is shown in the domain settings.
  • WordPress. Dashboard → Tools → Site Health → Info → Server.
  • Server with SSH access. php -v shows the command-line version. Your site may use a different one through PHP-FPM, so also check systemctl status for the php-fpm service.

A note for Debian, Ubuntu and RHEL servers. Distributions often backport fixes into an older package version without changing the number. A server may report, say, PHP 8.3.6 and still be patched. In that case check the package changelog and look for CVE-2026-109618 and CVE-2026-109619:

  • Debian/Ubuntu: apt changelog php8.3-fpm | head -50
  • RHEL/AlmaLinux/Rocky: rpm -q --changelog php | head -50

Step 2: Prepare before you change anything

Urgency is no excuse for skipping care. Five minutes of preparation saves hours of stress:

  1. Take a full backup — site files and the database separately. On a VPS, a snapshot of the whole machine is best.
  2. Record the current state — PHP version and module list (php -m), so you can confirm nothing went missing afterwards.
  3. If you are changing branch (for example from 7.4 or 8.1 to 8.3+), test on a copy of the site first. Check that plugins, theme and modules support the new version. Recent WooCommerce releases require PHP 8.3, Laravel 13 supports PHP 8.3 to 8.5.
  4. Updating within the same branch (for example 8.4.26 → 8.4.27) carries minimal compatibility risk — these are fix-only releases.

Step 3: Update PHP

Shared hosting

On shared hosting you usually cannot update PHP yourself; the hosting company does it. You have two jobs:

  • Ask your host whether they have deployed 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or the fixes for CVE-2026-109618 and CVE-2026-109619. Major providers received the patches in advance, but not all of them roll out immediately.
  • If you are on PHP 8.1 or older, switch the domain to a supported version in your panel. In cPanel that is MultiPHP Manager, in Plesk the domain's PHP Settings, in OVHcloud the hosting tab's PHP version setting. In other panels look for a "PHP version" option in the domain settings or ask support.

VPS or dedicated server with Debian / Ubuntu

  1. Refresh the package list: sudo apt update
  2. See what can be upgraded: apt list --upgradable | grep php
  3. Install updates: sudo apt full-upgrade, or just the PHP packages, e.g. sudo apt install --only-upgrade php8.3-fpm php8.3-cli
  4. Restart PHP-FPM: sudo systemctl restart php8.3-fpm (change the number to your version)
  5. For Apache with mod_php: sudo apache2ctl -t, then sudo systemctl restart apache2

If you use Ondřej Surý's repository (a popular source of newer PHP versions on Debian and Ubuntu), the update works the same way — the packages simply come from that repository.

Server with RHEL, AlmaLinux or Rocky Linux

  1. List available security fixes: sudo dnf updateinfo list --security
  2. Update PHP within the enabled stream: sudo dnf update "php*"
  3. Restart the service: sudo systemctl restart php-fpm or sudo systemctl restart httpd

If you use the Remi repository, the update also goes through dnf update.

Docker

Pull the new image and rebuild the container: docker pull php:8.4-fpm, then docker build --pull -t my-app . and redeploy. If your Dockerfile pins an exact version (for example php:8.4.26-fpm), bump it to the patched release.

Step 4: Check everything works

  • php -v and the version your site sees (for example in WordPress Site Health) show the fixed version, or a package whose changelog lists the CVE fixes.
  • The module list matches the one you saved before the update.
  • The site, login, cart, payments and contact forms work.
  • No new errors in the PHP-FPM and web server logs: journalctl -u php8.3-fpm -n 50

Cannot update today? Reduce the risk

The PHP team lists several settings that reduce the risk but do not remove it. Treat them as a stopgap for a few hours, not a replacement for the update. Most of them need access to server configuration, so on shared hosting you usually cannot apply them.

  • Set session.upload_progress.enabled=0 in php.ini or the FPM pool config and restart every worker. Setting it with ini_set() or .user.ini is not enough.
  • Set a low post_max_size: 8M for sites without file uploads, 32M if uploads are needed.
  • Set memory_limit=-1 so applications cannot override it (for example via php_admin_value) — but only together with a container or cgroup memory limit, otherwise you risk the server hanging.
  • On PHP 8.5, set fatal_error_backtraces=0.

Sources

Vulnerability details come from the official PHP team announcement and advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. Support dates: php.net/supported-versions. Usage statistics: W3Techs. Checked on 21 October 2026. Reports of attacks in the wild come from third parties and are not confirmed in the official announcement.

Need help updating your server?

If you are not sure which PHP version your site runs, whether your host has deployed the fix, or you simply do not want to risk doing the update yourself — I can update your server for you. I will check your PHP version, take a backup, run the update and make sure your site, shop and forms work exactly as before. If your site is on an unsupported version, I will plan a safe move to a newer one.

Get in touch or call +48 791 509 560.