The October 2026 PHP Security Release: CVE-2026-109618 and CVE-2026-109619

Summary

PHP announced the release a day ahead and published it on October 21, 2026, urging every user to update immediately (php.net news archive). The PHP security team rates both vulnerabilities critical, CVSS v4.0 9.2. Linux distributions and long-term-support vendors received the patches in advance, so many hosts were able to ship fixed packages quickly. The PHP Foundation’s account of the release describes how the issues were found and coordinated, including an early leak of the CVE identifiers (PHP Foundation).

The pair is widely called PHP2Shell in security research and press coverage. The PHP project’s own advisories use the CVE and GHSA identifiers below.

The two vulnerabilities

Both are memory-safety problems in how PHP cleans up after a request. In plain terms:

Which PHP installations are affected?

Any PHP installation that serves web requests and lacks the fix is in scope, and the demonstrated risk is highest on Apache with mod_php. The advisories are about PHP serving web requests, and the details vary by how PHP is connected to the web server. In the advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp):

• Apache with mod_php is where full remote code execution was demonstrated, including with default settings.
• PHP-FPM, the common setup on managed hosting, is described as susceptible, with exploitation demonstrated through particular code paths and configurations.
• FrankenPHP and LiteSpeed (LSAPI) are described as likely or conditionally susceptible, without a validated exploit in the advisories.

That spread is why no one can say from the outside that every PHP site is equally exploitable. A site is in scope if its PHP build lacks the fix; whether a specific site can be attacked depends on its server setup and code. The advisories do not discuss command-line PHP, the version you see when you run php -v on a server, which is often a different build from the one serving the website. Our patch status guide explains how to tell them apart.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities. Vendor packages that keep an older version number can include the fix too. Upstream, the fix shipped in one release per supported branch:

PHP 8.1 and older no longer receive releases from the PHP project. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves; distributions and long-term-support vendors may ship their own backported packages. Support dates are from php.net.

Most hosted sites do not run PHP built from php.net source. They run a package from the operating system vendor or the control-panel vendor, and those vendors often fix the code without changing the main version number. Some real examples:

Control-panel and hosting vendors such as cPanel, Plesk and CloudLinux build their own PHP packages, and their status pages are the authority for those builds. On AWS, Amazon’s bulletin lists updated Elastic Beanstalk platforms and Amazon Linux packages, and notes that running Lightsail instances are not updated in place (AWS security bulletin).

Are the vulnerabilities being exploited?

Some security firms report attacks, while government advisories had not identified active exploitation at their last update. Reports differ by source and date, so here is what each one said:

• The PHP Foundation said the security team did not identify any functional exploits at the time of release, while noting that proof-of-concept work circulated after the leak (PHP Foundation).
• The Canadian Centre for Cyber Security, in its alert updated October 23, said a proof of concept is available and no active exploitation had been identified, and that this can change quickly (AL26-026).
• The security firm watchTowr reported observing exploitation of both vulnerabilities in the wild from October 21 (watchTowr).
• CISA’s Known Exploited Vulnerabilities catalog did not list either CVE in its October 23, 2026 edition (CISA KEV).

None of this tells you whether your own site was targeted. It does mean the update should not wait, and that unexplained behavior on an unpatched site deserves a closer look.

What should website owners do now?

Get a patched PHP build from your host or vendor, restart PHP, confirm the build that is running, and test what your business depends on. In order:

1. Get a patched PHP build. On managed or shared hosting, that is your host’s job; ask them to confirm it. On your own server, install your vendor’s fixed package, or one of the upstream releases above if you build PHP yourself.
2. Restart every PHP worker. PHP-FPM pools, Apache with mod_php, and any other process serving PHP keep running the old code until restarted.
3. Confirm the running build. Check that the build serving web requests is the patched one, not just the one installed on disk or shown on the command line.
4. Test what your business depends on. Forms, logins, checkout and scheduled jobs. A same-branch security update is usually low risk, but confirm it.
5. Plan off unsupported branches. If the site runs PHP 8.1 or older without a vendor backport, the real fix is a PHP upgrade.

If you cannot update right away, PHP lists interim settings that reduce exposure, including turning off session upload progress, turning off fatal error backtraces on PHP 8.5, and tightening memory and request-size limits, each followed by a worker restart. PHP is explicit that these block only some paths and do not replace the update. They also differ by setup, so your host or administrator should apply them where they belong for your server. Content delivery and firewall providers published rules too; AWS, for one, says its WAF configurations may reduce impact but are not a complete mitigation. For internet-facing systems that cannot be patched, the Cyber Centre suggests isolating them from public networks until a fix is applied, and WordPress suggested that self-hosted sites on versions older than PHP 8.2 consider going offline while they upgrade (WordPress.org).

Follow-up advisories

Two notices followed the main release. Neither replaces it.

Expect more. The October 23 notice already says a full advisory for CVE-2026-115560 will come with the next regular release. We re-check the sources and update this page when something material changes; the date at the top shows when that last happened.

What should you ask your hosting provider?

Ask for written confirmation of three things: the build serving your site, that it includes the fix, and that PHP was restarted. Copy these into a support ticket, without any passwords:

1. Which PHP version and package build serves my website’s web requests right now?
2. Does that build include the fixes for CVE-2026-109618 and CVE-2026-109619? If it is a vendor package, which advisory or package release covers it?
3. Were the PHP workers for my site restarted after the update, and when?
4. Are any of my sites or applications still on PHP 8.1 or older, and if so, is a backported fix available?
5. Did you apply any interim settings or firewall rules, and do they change anything my site relies on?
6. Do you keep web server and PHP logs for my account, and for how long?

Does patching show whether a site was compromised?

No. A patched PHP build closes the vulnerability from that point on. It does not remove anything an attacker may have added earlier, and it does not prove nothing happened. The Cyber Centre recommends reviewing web server, application, authentication and endpoint logs, and looking for unexpected processes, commands, files, accounts or outbound connections associated with PHP or web-server services.

If you see signs of that, or your host reports suspicious activity, keep the evidence: do not delete files or restore a backup over the site before logs and copies are preserved. Investigation and cleanup are a different job from routine patching, usually involving your host and an incident-response specialist. The comparison on our PHP security update service page sets out the difference.

Common questions