PHP security update · last updated 23 October 2026

PHP 8.5.12 security update: check your PHP version in 2 minutes and update it

The short version: your website probably runs on PHP, the software under WordPress, WooCommerce, Laravel, Magento, Drupal, Joomla, PrestaShop, OpenCart and most other sites. On 21 October 2026 PHP released a fix for two critical security problems. Updating your website or its plugins does not apply it: the PHP on the server has to be updated. On shared or managed hosting your host does that for you; on your own server or VPS, you (or someone you hire) do.

1. What happened on 21 October 2026

The PHP project shipped an out-of-cycle security release: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. They fix two vulnerabilities in the PHP runtime itself, below your application code: CVE-2026-109618 and CVE-2026-109619 . The PHP project rates both Critical (CVSS v4.0 9.2). Several security vendors nicknamed them "PHP2Shell".

The first allows remote code execution without logging in, with the highest practical risk on Apache with mod_php; PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too. Both are memory-handling bugs in the engine. Details leaked on 20 October, ahead of the planned disclosure. Exploit attempts have been reported and proof-of-concept code is public; no confirmed compromise had been published as of 23 October 2026. The advisories say it plainly: updating is the only complete mitigation.

2. Who is affected

  • PHP 8.5.x: fixed in 8.5.12.
  • PHP 8.4.x: fixed in 8.4.27.
  • PHP 8.3.x: fixed in 8.3.36.
  • PHP 8.2.x: fixed in 8.2.35.
  • PHP 8.1, 8.0 and 7.4: no new numbered release, but the PHP security team published official minimal source backports, and vendors ship packages (Ubuntu 22.04 php8.1 8.1.2-1ubuntu2.28; Ubuntu 20.04 through Ubuntu Pro; cPanel ea-php, CloudLinux alt-php, AlmaLinux, Clever Cloud).
  • PHP 7.3 and older: reported affected; only community patches exist.

Sites that only run PHP from the command line are lower priority, but update those too. Check your vendor's advisory (for Ubuntu: USN-8948-1 and USN-8948-2).

3. The 2-minute self-check

Ubuntu note first: Ubuntu keeps the old version number when it backports a fix. 8.3.6-0ubuntu0.24.04.13 is patched although the number looks old.

WordPress

Tools → Site Health → Info → Server → "PHP version".

WooCommerce

WooCommerce → Status → System status → Server environment → "PHP version".

Laravel

Run php artisan about on each server, and check the version your web requests run under (FPM or Octane can differ from the command line; a phpversion() route shows it). Workers and Docker image tags count too.

Magento

php -v on every web node and the cron host, against Magento's supported PHP versions.

PrestaShop

Advanced Parameters → Information.

Drupal

Reports → Status report.

Joomla

System → System Information (Joomla 3 usually runs on older PHP).

OpenCart

Your host's control panel, or php -v.

Your own server or VPS

php -v, then apt changelog php8.3-fpm | grep CVE-2026-109618 (Debian/Ubuntu) or rpm -q --changelog php-fpm | grep CVE-2026-109618 (RHEL-family); apache2ctl -M | grep php and systemctl status 'php*-fpm' show what runs.

cPanel, WHM and Plesk

cPanel: MultiPHP Manager. WHM: EasyApache 4 (fixed builds published 21 October). Plesk: Tools & Settings → Updates, or PHP Settings.

Managed hosting

Check your host's status page first.

On a managed host? Just ask them. Paste this into a support ticket:

Subject: PHP security update (CVE-2026-109618, CVE-2026-109619) Hello, PHP released security updates on 21 October 2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35, and backports for older versions). Has the PHP that runs my website been updated to a fixed build? If not, when will it be? Thank you.

4. How to update, by environment

  • Ubuntu/Debian packages: apt update && apt install --only-upgrade 'php8.3*' (your version), then restart PHP-FPM or Apache and every worker.
  • deb.sury.org: the same, from the Sury repository.
  • RHEL, AlmaLinux, Rocky with Remi: dnf upgrade 'php*', then restart php-fpm and httpd.
  • Docker: bump the image tag, rebuild with --pull, redeploy every replica and worker.
  • Laravel Forge: update PHP from the server's PHP tab, then restart Octane, Horizon and queue workers.
  • cPanel/WHM, Plesk: update through EasyApache 4 or the Plesk Installer; on shared hosting, ask your host.
  • Managed WordPress hosts: they update PHP for you; check their status page.
  • Windows/IIS: install the new PHP build from windows.php.net and restart the FastCGI pool.

5. What "fixed" looks like when the number doesn't change

A distribution or panel package whose changelog names CVE-2026-109618 and CVE-2026-109619 is fixed. Check the version your web server actually runs (a live request to a phpversion() page), not only php -v, and make sure every running PHP process was restarted.

6. Stopgaps while you wait

The PHP project's advisories list these. None of them makes a server safe; update as soon as you can.

  • For CVE-2026-109618: memory_limit=-1 set in php.ini or the pool (the advisory's "primary configuration mitigation", incomplete; use a cgroup or container memory limit, not RLIMIT_AS/RLIMIT_DATA); a conservative post_max_size (8M without uploads, 32M with, upload_max_filesize below it); a lower max_input_nesting_level; request limits at the web server or proxy.
  • For CVE-2026-109619: session.upload_progress.enabled=0 and, on 8.5, fatal_error_backtraces=0, then restart every worker (pm.max_requests=1 if you can afford it).
  • Put these in php.ini or the FPM pool, never ini_set or .user.ini. WAF rules (Cloud Armor, AWS WAF, Cloudflare, Imunify360) are compensating controls only.

7. Stuck on PHP 8.1 or older

For 8.1, 8.0 and 7.4 apply the official backport or your vendor's package (Ubuntu Pro, CloudLinux, TuxCare, cPanel ea-php). For 7.3 and older only community patches exist: plan an upgrade (PrestaShop 8 → 9, Joomla 3 → 5, OpenCart 3 → 4, Drupal 7 → a current Drupal).

8. If you want someone to do it

We sell one thing: the Website Security Patch, $400 per site, prepaid. The PHP security patch, on the PHP version line you already run, on your own server or VPS, services restarted, verified, written report, our access removed. You choose the number of sites. Written authorization first. If we don't bring a site onto a fixed PHP build within 24 hours of working access, or we find before starting that it can't be done, you get back what you paid for that site. We don't switch PHP versions, upgrade operating systems, migrate sites or clean malware under this service. No root access (shared or managed hosting)? Your host patches PHP: use the message in section 3, or we apply the security patch to the version you run, in your panel or by following the ticket with your host, at the same price per website. Switching PHP versions is a separate job, which we quote first and bill hourly.

9. Questions

Am I affected? If your PHP is below the fixed version for its branch, yes. Will it break plugins? A security patch on the version line you already run is unlikely to; a switch to a new version needs testing first. My host has no fixed build yet? Ask them when; use the stopgaps meanwhile. PHP 8.1 or older? See section 7. Many sites? Enter the number when you book. Refunds? As in section 8. Who are you? The Thrivee LLC, a Wyoming company; our engineers and contractors, who may be outside the UK and EEA, do the work; we updated our own servers on 22 October. Composer packages? They don't contain PHP itself. The command line too? Yes, update it with the same package.

10. Sources and change log