PHP October 2026 security release: what to update

As of October 23, 2026, 02:55 JST (October 22, 17:55 UTC). Every fact that can change carries the time it was checked, in JST (UTC+9). Last changed: October 23, 02:55 JST, the PHP 8.1 answer.

If you run PHP that answers web requests, install PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, released on October 21, 2026, and restart every PHP worker. They fix CVE-2026-109618 and CVE-2026-109619, which PHP says "can allow unauthenticated remote code execution." PHP 8.1 and older get no release.

On shared or managed hosting, the host installs the fix: read its notice, and don't judge by the version number, because several hosts patch the version you already run and the number stays the same. A WordPress update doesn't fix this. WordPress.org says "No WordPress update is required or planned for these issues." Status at 02:51 JST on October 23 (17:51 UTC, October 22): PHP scores both CVEs 9.2 on CVSS v4.0, NVD scores both 9.8 on CVSS v3.1, CISA's Known Exploited Vulnerabilities catalog lists neither, and reports of attacks differ by source.

Below: the fixed versions, the two bugs in PHP's words, a table to see who has to act for your site, what each host, platform, and package channel has said or shipped, the update steps, and the attack reports side by side.

Which PHP versions are fixed

The versions and dates are from php.net's release announcements and its supported-versions page (checked 00:42 JST). For 8.1 and older, PHP's advisory says those branches "no longer receive updates from the PHP project", and adds that the PHP security team "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor." The CVE records list the affected versions as 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, and 8.5 before 8.5.12.

The two bugs, in PHP's words

PHP's advisory names who is at risk: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

PHP published both GitHub advisories on October 21 at 13:34 UTC (22:34 JST), and CVE.org published the records at 13:48 and 13:54 UTC, with PHP as the CNA. For PHP-FPM and CVE-2026-109618, the advisory says "Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI."

Other organizations score the same bugs differently (checked 00:42 to 00:45 JST):

• NVD scores both 9.8 on CVSS v3.1, beside PHP's 9.2 on CVSS v4.0.
• Red Hat rates both Important, with a CVSS v3.1 score of 8.1. For CVE-2026-109618 it says "Standard Red Hat Enterprise Linux deployments use PHP-FPM rather than mod_php."
• Ubuntu gives CVE-2026-109618 the priority "critical".

CISA calls the pair "php2shell" in its alert of October 21. PHP's advisory doesn't use that name.

Am I affected?

The bugs are in PHP itself, below WordPress, Laravel, Drupal, or any other application. Who has to install the fix depends on who runs PHP for your site.

Host and platform status

This table holds only what each company says on its own page, with the time this page read it. It is the part of this page that goes stale first. Quotes from Japanese pages are translated from Japanese.

Where you install PHP yourself, the channel decides when you get a fixed build:

Update PHP and restart

1. Find out who installs your PHP

If a host runs PHP for you (shared hosting, managed WordPress, a cPanel account), the host installs the fix, and your step is to read its notice in the status table. If you run the server, VM, or container yourself, the next steps are yours.

2. Find the version and how PHP serves your site

Run php -v for the version of command-line PHP. php.net's manual says php_sapi_name() returns "cli" there, so also check from a web request: WordPress shows the PHP version under Tools > Site Health > Info > Server, and a PHP page that prints php_sapi_name() shows the server API, such as apache2handler for mod_php or fpm-fcgi for PHP-FPM.

3. Install a fixed build

On Debian and Ubuntu, run sudo apt update && sudo apt upgrade. On AlmaLinux, AlmaLinux gives sudo dnf clean metadata && sudo dnf upgrade 'php*'. With Docker, rebuild with docker build --pull from a fixed tag such as php:8.4.27-fpm. With Homebrew, run brew upgrade php.

4. Restart every PHP worker

A PHP-FPM worker or Apache process that started before the update keeps running the old build until it restarts. AlmaLinux's instructions restart PHP right after the upgrade with sudo systemctl restart php-fpm, or sudo systemctl restart httpd for mod_php on AlmaLinux 8. On Debian and Ubuntu the FPM service carries the version in its name, such as php8.4-fpm. Then run step 2 again against the running site.

5. Check the fix by package version, not by php -v

Distributions and hosts often patch the version you already run, so the number doesn't move. AlmaLinux says "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change", and has you compare rpm -q php-common against its patched versions. On Debian and Ubuntu, compare the installed php8.x package version with the table above. On shared hosting, the host's notice is the proof: mixhost and ConoHa both say the number shown stays the same.

6. Move off PHP 8.1 and older, and plan for 8.2

PHP releases no fix for 8.1 and older. Some hosts and distributions patched them anyway: the Japanese hosts in the status table say they did, with Xserver's PHP 5.5 and older still in progress. Lolipop calls its fix for those versions a stopgap and warns that for future vulnerabilities an official fix may not come and it may not be able to make one (translated). PHP 8.2 gets security fixes until December 31, 2026.

If you can't update yet

These are the vendors' words. This page adds no advice of its own.

• PHP: "while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe." The measures for CVE-2026-109618 include memory_limit=-1, set where applications can't override it, and a low post_max_size. For CVE-2026-109619 they include session.upload_progress.enabled=0, then "restart every worker." The full list is in PHP's advisory.
• CISA: "Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated."
• WordPress.org, for sites on PHP older than 8.2 that run their own hosting, quotes the UK National Cyber Security Centre: "Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated."
• Cloudflare: limiting uploads and upload sizes "can also reduce exposure, but these measures do not replace the PHP fix."

Is it being exploited? Reports differ

The sources below don't agree, and this page doesn't pick one. Whichever is right, the fix is the same.

What this is not

Searches for "PHP vulnerability" and "WordPress vulnerability" this month also find these. Each has its own fix.

WordPress's latest release is 7.1.3, from October 6 (WordPress.org, checked 00:45 JST).

If your PHP server is there for one page and a form

Many small sites keep a PHP server only for one information page and a contact form. A page published on Convika is HTML that Convika serves at a convika.page address or your own domain, and its form submissions go to Convika, so there is no PHP of yours to patch (publish an HTML page, add a form without a backend). It can't run WordPress, a shopping cart, payments, member logins, or PHP scripts. Moving a site means rebuilding the page and adding DNS records, so it's no step for the middle of an incident or for while your host's control panel is down.

Tell your visitors while the site is down

While a host patches PHP or you update it yourself, your site may show an error, and a site that is down can't carry its own notice. Ask an AI chat to write one HTML page that says why the site is down, when you expect it back, and how to reach you, then send its link by email or post it on social media.

Convika turns that file into a link: sign up free, drop the file on the upload screen, check the private preview, and publish. The page runs on Convika, apart from your PHP server, so it stays up while your site is down. On the free plan the page is public, and search engines and Convika's gallery may list it.

Publish my notice page

Updates to this page

• October 23, 2026, 01:05 JST: first version. Sources read between 00:42 and 00:53 JST. The CVE records, NVD, CISA's catalog, WordPress.org, Red Hat, Debian, and the hosts' notices were read again at 01:04 JST, unchanged.
• October 23, 2026, 02:55 JST: the answer to "Is PHP 8.1 affected, and is there a fix?" opens with yes, quoting PHP and CISA; the first version read as if 8.1 were not at risk. The answer on affected versions says the same. The Docker row gives the first push of the plain tags (October 21), the Xserver row its notice date, and the ConoHa source its final notice. CISA's catalog, NVD, and the CVE records were read again at 02:49 to 02:51 JST, unchanged.

This page changes when CISA adds either CVE to its catalog, when NVD or PHP changes a score, when a host in the status table posts a new notice (Xserver's PHP 5.5 and older is still open), when Red Hat ships the RHEL 9 php:8.4 fix or Debian fixes forky, and when anything new about attacks is reported. The same week: Node.js October 2026 security release: what to update and Chrome's eMudhra root removal on October 27: what to do. The Japanese version of this story, written for shared-hosting users, is PHP の脆弱性で緊急メンテナンス：自分のサイトは何をすればいい？ (in Japanese).

Frequently asked questions

Which PHP versions are affected by CVE-2026-109618?

PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, and 8.5 before 8.5.12, per the CVE record and PHP's advisory of October 21, 2026. The record lists only the branches PHP still supports: PHP 8.1 and older are at risk too, by PHP's and CISA's accounts, and get no fix from PHP. CVE-2026-109619 covers the same versions.

Is PHP 8.1 affected, and is there a fix?

Yes, by PHP's and CISA's accounts: PHP's advisory names "all PHP installations serving web requests", and CISA says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." The CVE records list only the supported branches, 8.2 to 8.5, and PHP releases no fixed 8.1: its advisory says 8.1 and older "no longer receive updates from the PHP project". PHP published minimal source backports for 7.4, 8.0, and 8.1, and some vendors ship patched packages: Ubuntu 22.04's php8.1 8.1.2-1ubuntu2.28, cPanel's ea-php74 to ea-php81, and the Japanese hosts in the status table.

Do I need to update PHP if I use shared hosting?

No, not yourself. On shared hosting the host installs the fix. mixhost, Sakura, and ConoHa WING say customers have nothing to do, and Xserver says it may ask for more measures later (all checked October 23, 00:43 to 00:45 JST). Read your host's notice, and plan a move to PHP 8.2 or later if you run 8.1 or older.

Does updating WordPress fix the PHP vulnerability?

No. WordPress.org says the vulnerabilities "are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues." The fix is a PHP update, from you or your host.

How do I check my PHP version, and why does it show the old number after my host patched?

Check it in WordPress under Tools > Site Health > Info > Server, in your host's control panel, or with php -v. The old number can stay because hosts and distributions often patch the version you already run: mixhost and ConoHa WING both say the displayed number doesn't change. Your host's notice, or your package version on your own server, is the proof.

Is CVE-2026-109618 being exploited?

Sources disagree. CISA's alert of October 21 says it "has not observed exploitation", CISA's catalog doesn't list it (checked October 23, 02:49 JST), and the PHP Foundation saw no working exploit at release. Cloudflare says it "observed attack traffic targeting our customers", and watchTowr reports exploitation seen by its honeypots on October 21.

What is the CVSS score of CVE-2026-109618?

PHP, which issued the CVE, scores it 9.2 on CVSS v4.0. NVD scores it 9.8 on CVSS v3.1, and Red Hat gives 8.1 on CVSS v3.1 with the rating Important (all checked October 23, 00:42 to 00:45 JST). CVE-2026-109619 has the same scores from all three.

Do I need to restart PHP-FPM after updating?

Yes. A worker that started before the update keeps running the old build, and AlmaLinux's steps restart PHP-FPM, or Apache for mod_php, right after the upgrade. On Debian and Ubuntu the service name carries the version, such as php8.4-fpm.

Is Cloudflare's WAF enough?

No. Cloudflare turned on rules for all plans, Free included, but says "updating website code or a plugin(s) alone does not fix these vulnerabilities" and that its other measures "do not replace the PHP fix." CISA says a firewall "may provide some protection until systems are updated or patched."

When does PHP 8.2 stop getting security fixes?

December 31, 2026, per php.net's supported-versions page. PHP's 8.2.35 announcement adds that 8.2 "will receive no further security fixes after that date." PHP 8.3 has security support until December 31, 2027.

Sources

Times are October 23, 2026, in JST (UTC+9).

• PHP: Security advisory, Critical remote code execution vulnerabilities, update now, with the 8.5.12, 8.4.27, 8.3.36, and 8.2.35 announcements (00:42)
• PHP: Supported Versions and the releases feed (00:42)
• GitHub: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp (00:43)
• CVE.org: CVE-2026-109618 and CVE-2026-109619 (00:42, 02:51)
• NVD: CVE-2026-109618 and CVE-2026-109619 (00:42, 02:51)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (00:43)
• CISA Known Exploited Vulnerabilities catalog, version 2026.10.21 (00:42, 02:49)
• The PHP Foundation: Today's PHP security release (00:43)
• watchTowr: FAQ About PHP RCE (00:43)
• WordPress.org: Critical PHP Security Release and the WordPress news feed (00:42)
• WordPress 7.0.2 Release, WordPress 7.1.2 Release, and the version-check API (00:45, 00:46)
• IPA: WordPress alert of July 22, 2026 (wp2shell) (00:52)
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability (00:43)
• Google Cloud: Responding to core PHP vulnerabilities (00:43)
• Red Hat: CVE-2026-109618 and CVE-2026-109619 (00:43, 00:45)
• Ubuntu: CVE-2026-109618, USN-8948-1, and USN-8948-2 (00:43, 00:45)
• Debian security tracker: CVE-2026-109618 (00:43)
• AlmaLinux: php2shell, patched PHP packages released (00:43)
• Remi's RPM repository blog (00:43)
• Docker Hub: php (00:43, 02:49)
• Homebrew: php, php@8.4, php@8.3, and php@8.2 (00:43)
• cPanel news: EasyApache 4 25.91 and cPanel & WHM Security Update (00:45)
• Plesk knowledge base: CVE-2026-109618 and CVE-2026-109619, answered 403 (00:43)
• mixhost: PHP vulnerability response, completed (00:43)
• Xserver: notice on the precautionary suspension of its sites and control panels (00:44)
• Lolipop: maintenance completed, and what happened (00:44)
• Sakura Internet: status of the PHP vulnerability response (00:43)
• ConoHa WING: PHP vulnerability response completed (final report) (00:45)
• php.net manual: php_sapi_name (00:45)