PHP patches two critical remote code execution flaws

The PHP project published a security advisory and four releases on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

21 Oct 2026 Security advisory: Critical remote code execution vulnerabilities, update now PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution.

The advisory is headed "Critical remote code execution vulnerabilities, update now" and covers CVE-2026-109618 and CVE-2026-109619.

Security advisory: Critical remote code execution vulnerabilities, update now ... RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) ... RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)

Each release announcement says it fixes two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619) that can allow unauthenticated remote code execution.

This is a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619) that can allow unauthenticated remote code execution.

PHP's pre-announcement of 20 October says both vulnerabilities were rated CVSS v4.0 9.2.

20 Oct 2026 Upcoming Critical PHP Security Release ... It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.

PHP describes CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp), as request-owned internal state that can survive after its backing memory has been freed, which a later request handled by the same worker may use before normal initialization resets it.

RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

The PHP advisory says the highest risk is for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

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 lists mitigations for both flaws (such as session.upload_progress.enabled=0 for CVE-2026-109619) and says they do not make an installation safe.

while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe. ... Set session.upload_progress.enabled=0 and restart every worker.

The PHP project’s advisory of 21 October 2026 says: "PHP 8.1 and older no longer receive updates from the PHP project."

PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.

The PHP project’s advisory of 21 October 2026 says that, "Given the severity of these vulnerabilities, 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."

Given the severity of these vulnerabilities, 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 PHP project’s advisory of 21 October 2026 says some distributions and LTS vendors provide backported fixes for PHP 8.1 and older: "contact your vendor for details, or upgrade to a supported version."

Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.

The PHP project’s advisory of 21 October 2026 lists those at risk as "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed".

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

GHSA-w8hw-w9fx-j79w, "RCE via OOM corruption" (CVE-2026-109618), was published on 21 October 2026 and rates the flaw Critical with a CVSS v4 base score of 9.2.

RCE via OOM corruption Critical bukka published GHSA-w8hw-w9fx-j79w Oct 21, 2026 ... Severity Critical 9.2 CVSS overall score ... CVSS v4 base metrics

The advisory for CVE-2026-109618 lists affected versions as those before 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with those four versions as the patched ones.

Affected versions < 8.2.35 < 8.3.36 < 8.4.27 < 8.5.12 Patched versions 8.2.35 8.3.36 8.4.27 8.5.12

The advisory says PHP uses longjmp() for out-of-memory errors to exit the current context and abort handling of the request.

PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request.

The advisory says a failed allocation can leave request memory invalid when memory is reachable before it is fully initialized, and request shutdown may then read or branch on it.

In some contexts, request memory is temporarily reachable before it is fully initialized. If any allocation fails at that point, PHP does not properly account for the early exit and leaves the request memory in an invalid state. ... The request shutdown procedure may then read or branch on it.

The advisory says this can lead to unauthenticated remote code execution as the web worker account, validated against mod_php with default settings.

The confirmed impact is unauthenticated remote code execution as the web worker account. Complete remote code execution was validated over HTTP against mod_php with default PHP input and memory limits and normal prefork configurations with multiple workers.

The advisory says the patch replaces the longjmp() out-of-memory handling with a delayed soft out-of-memory and an immediate hard out-of-memory through _exit().

The patch removes longjmp() for OOM ... It is replaced with a delayed, graceful soft OOM triggered at the next VM safe point, and an immediate hard OOM using _exit() if memory consumption reaches a second, higher threshold.

The advisory says updating is the only complete mitigation.

Updating to a PHP release containing the patch to this vulnerability is the only complete mitigation.

The advisory GHSA-w8hw-w9fx-j79w for CVE-2026-109618 gives four affected-version ranges for php-src, "< 8.2.35", "< 8.3.36", "< 8.4.27" and "< 8.5.12"; it names no range for PHP 8.1 or older.

vulnerable_version_range: < 8.2.35, < 8.3.36, < 8.4.27, < 8.5.12 (patched_versions 8.2.35, 8.3.36, 8.4.27, 8.5.12)

The advisory says of Apache mod_php: "Apache mod_php unconditionally invokes the request shutdown procedure, even when request startup has failed. During request startup, automatic body parsing can exhaust the configured memory limit and exit the request in a context where state is temporarily invalid. Shutdown then processes this invalid state. This happens entirely before any application-specific code begins execution."

Apache mod_php unconditionally invokes the request shutdown procedure, even when request startup has failed. During request startup, automatic body parsing can exhaust the configured memory limit and exit the request in a context where state is temporarily invalid. Shutdown then processes this invalid state. This happens entirely before any application-specific code begins execution.

The advisory says of FPM: "FPM exits the child when request startup fails. This prevents consumption of the invalid state and removes the child from the pool. After normal startup, OOM may still be reached in a context failing to account for an early exit, with the invalid state being processed during request shutdown. Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI."

FPM exits the child when request startup fails. This prevents consumption of the invalid state and removes the child from the pool. After normal startup, OOM may still be reached in a context failing to account for an early exit, with the invalid state being processed during request shutdown. Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI.

The advisory says of FrankenPHP and LSAPI: "Source analysis indicates that FrankenPHP, analogous to Apache mod_php, calls the request shutdown procedure unconditionally, making it likely susceptible to application-independent attacks. LSAPI models FPM, with application-specific exploits being likely but unvalidated."

Source analysis indicates that FrankenPHP, analogous to Apache mod_php, calls the request shutdown procedure unconditionally, making it likely susceptible to application-independent attacks. LSAPI models FPM, with application-specific exploits being likely but unvalidated.

The advisory lists three multipart-parsing ways for a request to reach out-of-memory while staying within its apparent PHP limits, the first being: "A multipart request without a usable declared content length may pass the initial `post_max_size` check and continue supplying decoded body data."

Several multipart parsing problems can let a request reach OOM while remaining within its apparent PHP limits: - A multipart request without a usable declared content length may pass the initial `post_max_size` check and continue supplying decoded body data.

The advisory's second multipart out-of-memory route is: "A multipart part can contain an unrestricted number of headers. Representing these headers inside PHP can use substantially more memory than their wire representation, allowing a request within `post_max_size` to exhaust the normal `memory_limit`."

A multipart part can contain an unrestricted number of headers. Representing these headers inside PHP can use substantially more memory than their wire representation, allowing a request within `post_max_size` to exhaust the normal `memory_limit`.

The advisory's third multipart out-of-memory route is: "Empty file controls do not count towards `max_file_uploads` but still create the normal file metadata arrays. Nested field names multiply the generated array work."

Empty file controls do not count towards `max_file_uploads` but still create the normal file metadata arrays. Nested field names multiply the generated array work.

The advisory says: "OOM can also be reached in application-specific ways when attacker-controlled input causes a sufficiently large allocation or repeated memory use."

OOM can also be reached in application-specific ways when attacker-controlled input causes a sufficiently large allocation or repeated memory use.

The advisory says of exploit reliability: "Additional workers and unrelated traffic can increase the required number of attempts but do not remove the condition. Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout."

Additional workers and unrelated traffic can increase the required number of attempts but do not remove the condition. Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.

The advisory's text on SAPIs names Apache mod_php, FPM, FrankenPHP and LSAPI; the words CLI and CGI do not appear in the advisory.

Apache mod_php unconditionally invokes ... FPM exits the child ... Source analysis indicates that FrankenPHP ... LSAPI models FPM

OpenAI says Calif identified a critical flaw using GPT-5.6 Sol as part of OpenAI's Patch the Planet initiative, and that Wiz independently discovered and reported both vulnerabilities.

Calif identified a critical flaw using GPT‑5.6 Sol as part of our Patch the Planet initiative, with Wiz also independently discovering and reporting both vulnerabilities.

OpenAI says PHP's maintainers led the fixes and release, with OpenAI's teams and partners including Wiz and Cloudflare contributing research, technical support and coordination.

PHP’s maintainers led the fixes and release, with our teams and partners like Wiz, Cloudflare, and others contributing research, technical support, and coordination to prepare protections ahead of disclosure.

OpenAI says it has committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, aimed at organizations with limited security resources protecting essential services.

we’ve committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, focused on organizations with limited security resources protecting essential services.

OpenAI says it is sharing a PHP version checker as a Codex skill to help operators identify potentially vulnerable PHP versions.

We’re sharing a PHP version checker as a Codex skill to help operators identify potentially vulnerable PHP versions

OpenAI says it engaged parts of the US government on the PHP response, including the Office of the National Cyber Director and CISA, as well as international partners.

we worked, in collaboration with our partners, to engage with multiple parts of the U.S. government, including the White House’s Super Intelligence Force, the Office of the National Cyber Director (ONCD), the Cybersecurity and Infrastructure Security Agency (CISA), as well as international partners

OpenAI says: "Given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory."

Given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory.

OpenAI says: "To our knowledge, frontier AI found these vulnerabilities before attackers did".

To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender’s Window for maintainers and security providers to prepare fixes and protections ahead of disclosure.

OpenAI’s Patch the Planet post of 21 October 2026 says Calif "identified a critical flaw using GPT‑5.6 Sol" and refers to it only as a critical flaw; the post gives no CVE number for it, and no CVE number appears anywhere on the page.

Calif identified a critical flaw using GPT‑5.6 Sol as part of our Patch the Planet initiative, with Wiz also independently discovering and reporting both vulnerabilities.

W3Techs reports on its PHP usage page, dated 23 October 2026, that PHP is used by 69.3% of all the websites whose server-side programming language it knows.

PHP is used by 69.3% of all the websites whose server-side programming language we know.

W3Techs reports on its PHP usage page, dated 23 October 2026, that PHP version 7 is used by 26.9% of all the websites that use PHP.

Version 7 26.9% ... W3Techs.com, 23 October 2026 Percentages of websites using various versions of PHP

W3Techs reports on its PHP usage page, dated 23 October 2026, that PHP version 5 is used by 7.7% of all the websites that use PHP.

Version 5 7.7% ... W3Techs.com, 23 October 2026 Percentages of websites using various versions of PHP

Cloudflare says in its post of 21 October 2026 that "PHP is used by almost 70% of websites".

PHP is used by almost 70% of websites.

Cloudflare says in its post of 21 October 2026 that the vulnerability was leaked before the official release date and that it "observed attack traffic targeting our customers".

Cloudflare successfully deployed multiple mitigations for all its customers while the vulnerability was leaked before the official release date and we observed attack traffic targeting our customers.

Cloudflare says in its post of 21 October 2026 that it observed "how attackers were mutating the attack payload to try to bypass our protections".

We observed how attackers were mutating the attack payload to try to bypass our protections by tracking the volume of matches and cross-referencing with the rule logic.

Cloudflare says that from 21 October 2026 at 3:02 am UTC its customers using the free or paid WAF were protected by default against php2shell, with protections "deployed about 9 hours ahead of public disclosure".

Cloudflare has developed and deployed web application firewall (WAF) protections since early October 2026, which were deployed about 9 hours ahead of public disclosure. Starting on October 21 3:02 am UTC, Cloudflare customers using our free or paid WAF were protected by default against php2shell.

Cloudflare says in its post of 21 October 2026: "The vulnerabilities affect all web servers running PHP 5.4 or later and they may allow an attacker to cause denial of service, remote code execution, and data exposure when an application processes specially crafted HTTP traffic." This differs from PHP's advisories, which give affected ranges only for the 8.2 to 8.5 branches and name no version floor; GHSA-6wmf-4rv5-p3rp gives the confirmed impact as heap use-after-free, memory disclosure and remote code execution. The 5.4 floor matches Calif and Wiz.

The vulnerabilities affect all web servers running PHP 5.4 or later and they may allow an attacker to cause denial of service, remote code execution, and data exposure when an application processes specially crafted HTTP traffic.

Cloudflare says: "Because PHP underpins widely used platforms such as WordPress and Magento, these flaws could potentially affect a large number of applications across the Internet." It gives no count.

Because PHP underpins widely used platforms such as WordPress and Magento, these flaws could potentially affect a large number of applications across the Internet.

Wiz says in its post of 21 October 2026 that core PHP "powers 70% of all websites in the world".

Wiz Research uncovered multiple critical vulnerabilities in core PHP, a popular general-purpose scripting language that powers 70% of all websites in the world.

Wiz says in its post of 21 October 2026: "Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4."

Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4.

Wiz says: "These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history."

These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history.

Wiz says: "With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work."

With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work.

Wiz says in its post of 21 October 2026: "Wiz Research uncovered multiple critical vulnerabilities in core PHP".

Wiz Research uncovered multiple critical vulnerabilities in core PHP

Wiz says: "We used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research."

We used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research.

Wiz’s disclosure timeline says that on 19 August 2026 "Wiz Research discovers the first PHP vulnerability using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol."

August 19, 2026: Wiz Research discovers the first PHP vulnerability using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol.

Wiz says: "Notably, Gemini 4 Argon made an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch."

Notably, Gemini 4 Argon made an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch.

Wiz’s disclosure timeline says Wiz Research reported the vulnerabilities to the PHP security team on 24 August 2026.

August 24, 2026: Wiz Research reports the vulnerabilities to the PHP security team.

Wiz’s table of the bugs it reported lists, against CVE-2026-109618, "Upload-progress unserializer use-after-free" and "Remote process-memory disclosure".

CVE-2026-109618 Upload-progress unserializer use-after-free Remote process-memory disclosure

Wiz’s table of the bugs it reported lists, against CVE-2026-109619, "Fatal-error backtrace use-after-free" and "OPcache type confusion".

CVE-2026-109619 Fatal-error backtrace use-after-free OPcache type confusion

Wiz says: "Wiz Research would like to thank the PHP team, Calif and OpenAI for their work on discovery, coordination and patch verification."

Wiz Research would like to thank the PHP team, Calif and OpenAI for their work on discovery, coordination and patch verification.

Wiz says: "These platforms illustrate the impact, but the vulnerabilities are in PHP itself. Exploitation does not depend on a flaw in the application's code: even a simple 'Hello World' application running on an affected PHP version can be vulnerable." This differs from or adds to other sources: Differs from PHP's advisories: GHSA-w8hw-w9fx-j79w reports no complete FPM exploit for CVE-2026-109618, and GHSA-6wmf-4rv5-p3rp says the validated FPM session path "depends on a suitable application operation".

These platforms illustrate the impact, but the vulnerabilities are in PHP itself. Exploitation does not depend on a flaw in the application’s code: even a simple “Hello World” application running on an affected PHP version can be vulnerable.

Wiz says of its remote process-memory disclosure bug: "The attack works even when the application never calls session_start(), making the issue application-agnostic."

The attack works even when the application never calls session_start() , making the issue application-agnostic.

Wiz's headline reads "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet", and its conclusion says "With 70% of the Internet affected, the impact of PHP2Shell cannot be overstated." The page gives no method for the 70% figure; its executive summary describes 70% as the share of all websites PHP "powers". This differs from or adds to other sources: Wiz equates PHP's share of websites with the share affected. PHP's advisories state conditions by version and SAPI and give no share of sites affected.

PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet ... With 70% of the Internet affected, the impact of PHP2Shell cannot be overstated. ... a popular general-purpose scripting language that powers 70% of all websites in the world.

Wiz says: "PHP runs across clouds, hosting providers, content-delivery networks and millions of independently managed servers." The sentence describes PHP's overall use; it is not a count of servers affected by these flaws.

PHP runs across clouds, hosting providers, content-delivery networks and millions of independently managed servers.

Wiz describes the OPcache bug this way: "OPcache persists compiled PHP structures in shared memory and assigns indices into per-worker runtime-pointer maps." It says it "used this primitive to build an unauthenticated RCE chain against WordPress".

OPcache persists compiled PHP structures in shared memory and assigns indices into per-worker runtime-pointer maps. ... We used this primitive to build an unauthenticated RCE chain against WordPress.

Wiz says: "There are other variants outside of these four bugs. While we initially reported these four to PHP, through this research we realized the vulnerability is deeply rooted in the PHP codebase and will require a comprehensive fix. Other variants should also fold under the same two CVEs."

There are other variants outside of these four bugs. While we initially reported these four to PHP, through this research we realized the vulnerability is deeply rooted in the PHP codebase and will require a comprehensive fix. Other variants should also fold under the same two CVEs.

watchTowr says on its PHP2Shell page (published 21 October 2026, last updated 22 October 2026) that its Attacker Eye honeypot network observed exploitation of CVE-2026-109618 and CVE-2026-109619 in the wild on 21 October 2026: "watchTowr’s Attacker Eye honeypot network observed exploitation of CVE-2026-109618 and CVE-2026-109619 in the wild." The page gives no count and does not say any real site was compromised.

October 21, 2026: watchTowr’s Attacker Eye honeypot network observed exploitation of CVE-2026-109618 and CVE-2026-109619 in the wild.

watchTowr’s PHP2Shell page lists "PHP 7.3 and older, including PHP 5" as all versions affected, with "No fix available. Upgrade to a supported branch".

PHP 7.3 and older, including PHP 5 All versions No fix available. Upgrade to a supported branch

watchTowr's table of affected versions lists "PHP 7.4, 8.0 and 8.1" as "All versions", with the fix "No official release. Use a distribution or LTS vendor package, or PHP's minimal source backports". This differs from or adds to other sources: Differs from PHP's advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, whose affected ranges name only the 8.2 to 8.5 branches.

PHP 7.4, 8.0 and 8.1 All versions No official release. Use a distribution or LTS vendor package, or PHP’s minimal source backports

watchTowr says: "PHP's Session Upload Progress feature, enabled by default, is one confirmed path to trigger CVE-2026-109619. It is not the only path to exploitation." Earlier on the page it adds: "so most default deployments meet that precondition". This differs from or adds to other sources: The `most default deployments` inference is watchTowr's own; PHP's advisory says exploitation through session upload progress still requires an interruption after state is published and a later request handled by the same worker.

Session Upload Progress, a feature turned on by default, offers one confirmed path to CVE-2026-109619, so most default deployments meet that precondition. ... PHP’s Session Upload Progress feature, enabled by default, is one confirmed path to trigger CVE-2026-109619. It is not the only path to exploitation.

watchTowr says: "Put simply: if you have not applied the update, your deployment of PHP is vulnerable." and "Every installation that serves PHP web requests is affected, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or FrankenPHP." This differs from or adds to other sources: Stated without the per-SAPI conditions in PHP's advisories, which describe FPM as susceptible with no complete FPM exploit for CVE-2026-109618, and as dependent on a suitable application operation for the CVE-2026-109619 session path.

Put simply: if you have not applied the update, your deployment of PHP is vulnerable. ... Every installation that serves PHP web requests is affected, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or FrankenPHP.

watchTowr says: "Mitigations that involve changes to .ini files should be understood to be ineffective and not suitable to prevent exploitation." This differs from or adds to other sources: Differs from PHP's advisory, which lists INI settings (memory_limit=-1, post_max_size, session.upload_progress.enabled=0) as measures that "reduce exposure to specific attack paths but do not make an installation safe".

Mitigations that involve changes to .ini files should be understood to be ineffective and not suitable to prevent exploitation.

watchTowr says: "Check the PHP version that actually serves web requests, using phpinfo() output or your package manager. The command-line php binary can be a different version from the one PHP-FPM or Apache runs."

Check the PHP version that actually serves web requests, using phpinfo() output or your package manager. The command-line php binary can be a different version from the one PHP-FPM or Apache runs.

watchTowr says on its PHP2Shell page: "As of mid-2026, PHP runs 70.8% of all websites whose server-side programming language is known, more than ten times the share of the next-closest language. That puts it on hundreds of millions of live systems worldwide." The sentence is about PHP's overall use, not a count of systems affected by these flaws, and the page gives no method or source for either figure.

As of mid-2026, PHP runs 70.8% of all websites whose server-side programming language is known, more than ten times the share of the next-closest language. That puts it on hundreds of millions of live systems worldwide.

Rapid7 says in its post (published 21 October 2026, last updated 22 October 2026): "Rapid7 has not observed exploitation in the wild, though there are multiple reports of exploitation attempts".

Rapid7 has not observed exploitation in the wild, though there are multiple reports of exploitation attempts, which is expected for a vulnerability of this profile.

Rapid7 says multiple public proof-of-concept exploits for CVE-2026-109618 and CVE-2026-109619 are available and that each "demonstrates RCE only against a specific combination of operating system, PHP version, and web server, and none appears to be broadly reliable".

Multiple public proof-of-concept (PoC) exploits for CVE-2026-109618 and CVE-2026-109619 are now available. Rapid7 researchers have reviewed these and observe that each demonstrates RCE only against a specific combination of operating system, PHP version, and web server, and none appears to be broadly reliable.

Rapid7 says, in its description of CVE-2026-109619, that session upload progress, PHP's upload-tracking feature, "is enabled by default and can act as an early consumer of stale session or decoder state before normal initialization".

Session upload progress, PHP's upload-tracking feature, is enabled by default and can act as an early consumer of stale session or decoder state before normal initialization; reaching this consumer does not itself require an application call to session_start().

Rapid7 says: "The PHP advisories list these affected and fixed versions", and lists PHP 8.2 releases before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12, each with its fixed release.

The PHP advisories list these affected and fixed versions: PHP 8.2 releases before 8.2.35: Update to 8.2.35 PHP 8.3 releases before 8.3.36: Update to 8.3.36 PHP 8.4 releases before 8.4.27: Update to 8.4.27 PHP 8.5 releases before 8.5.12: Update to 8.5.12

Rapid7 says the PHP 8.5 fatal-error backtrace path applies "when fatal_error_backtraces is enabled (the default)". This differs from or adds to other sources: Differs in detail from PHP's advisory GHSA-6wmf-4rv5-p3rp, which says "With `fatal_error_backtraces` enabled" and does not say it is the default.

The advisory confirms RCE against mod_php through PHP 8.5's fatal error backtrace feature, when fatal_error_backtraces is enabled (the default), where a later initialization diagnostic accesses stale backtrace state.

Rapid7 says of the validated FPM session path: "The validated FPM session path requires a suitable application operation to leave state behind after successful startup, followed by a fatal error and another request that consumes the stale state through session upload progress. Both requests must reach the same worker."

The validated FPM session path requires a suitable application operation to leave state behind after successful startup, followed by a fatal error and another request that consumes the stale state through session upload progress. Both requests must reach the same worker.

Rapid7 says of its own exploit attempts: "Our attempts so far have produced a working exploit only under narrow lab conditions, and exploitation depends on assumptions that are unlikely to hold on internet-facing instances." This differs from or adds to other sources: Differs in emphasis from PHP's advisory, which lists all PHP installations serving web requests as at risk, and from Wiz, which says even a simple Hello World application on an affected version can be vulnerable.

Rapid7’s own research supports this. Our attempts so far have produced a working exploit only under narrow lab conditions, and exploitation depends on assumptions that are unlikely to hold on internet-facing instances.

The Canadian Centre for Cyber Security, in alert AL26-026 dated 21 October 2026, says it "has observed open-source reporting indicating that a Proof of Concept (PoC) is available".

The Cyber Centre has observed open-source reporting indicating that a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.

The Canadian Centre for Cyber Security, in alert AL26-026 dated 21 October 2026, reports "no active exploitation being identified at this time, but that can change quickly".

The Cyber Centre has observed open-source reporting indicating that a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.

Alert AL26-026 of 21 October 2026 lists PHP 8.5.x "prior to 8.5.12" as affected, with 8.5.12 as the fixed version.

PHP 8.5.x prior to 8.5.12 | 8.5.12

Alert AL26-026 lists PHP 8.4.x "prior to 8.4.27" as affected, with 8.4.27 as the fixed version.

PHP 8.4.x prior to 8.4.27 | 8.4.27

Alert AL26-026 lists PHP 8.3.x "prior to 8.3.36" as affected, with 8.3.36 as the fixed version.

PHP 8.3.x prior to 8.3.36 | 8.3.36

Alert AL26-026 lists PHP 8.2.x "prior to 8.2.35" as affected, with 8.2.35 as the fixed version.

PHP 8.2.x prior to 8.2.35 | 8.2.35

Alert AL26-026 notes under its table: "versions 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version." Its table lists no 8.1 or older row.

Note: versions 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.

Alert AL26-026 says: "All PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are at risk."

All PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are at risk.

Alert AL26-026 says the two vulnerabilities are "Use After Free vulnerabilities (CWE-416)" "affecting multiple versions of PHP" and that "Internet-facing PHP servers and applications are at heightened risk."

these vulnerabilities are Use After Free vulnerabilities (CWE-416) Footnote 5 affecting multiple versions of PHP. ... Internet-facing PHP servers and applications are at heightened risk.

Alert AL26-026 describes PHP's scale in these words and gives no figure: "PHP remains a widely deployed technology and continues to support a substantial proportion of web applications worldwide."

PHP remains a widely deployed technology and continues to support a substantial proportion of web applications worldwide.

Alert AL26-026 recommends that organizations "Identify third-party products, appliances and containers that include vulnerable PHP components".

Identify third-party products, appliances and containers that include vulnerable PHP components

On how the Phoenix Security figure was counted, its page names only "One Shodan-based assessment" and does not say who ran it (its reference list cites a Mallory.ai item as "exposure telemetry, single-source"), gives no scan date, uses no definition of end-of-life beyond "a branch that will receive no fix", counts hosts and not websites, and says "These figures are single-sourced and should be treated as directional (VERIFY: single external source)."

One Shodan-based assessment counted roughly 2.23 million hosts advertising an X-Powered-By: PHP banner ... These figures are single-sourced and should be treated as directional (VERIFY: single external source).

Phoenix Security wrote its page before the PHP release: it calls the fixed versions "Rumored fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35" and says "all of these are single-source and unconfirmed".

Rumored fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, each the next point release above the current stable builds (8.5.11, 8.4.26, 8.3.35, 8.2.34); all of these are single-source and unconfirmed

The PHP project’s Supported Versions page lists PHP 8.2, 8.3, 8.4 and 8.5 as the currently supported branches.

Currently Supported Versions ... 8.2 ... 8.3 ... 8.4 ... 8.5

The PHP project’s Supported Versions page gives 31 Dec 2026 as the date security support for PHP 8.2 ends.

8.2 8 Dec 2022 ... 31 Dec 2024 ... 31 Dec 2026

The PHP project’s Supported Versions page defines end of life as "A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities."

End of life A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.

The PHP project’s Unsupported Branches page lists PHP 8.1 as reaching end of life on 31 Dec 2025, with 8.1.34 as its last release.

8.1 31 Dec 2025 (9 months ago) 8.1.34

The PHP project’s Unsupported Branches page lists PHP 8.0 as reaching end of life on 26 Nov 2023, with 8.0.30 as its last release.

8.0 26 Nov 2023 (2 years, 10 months ago) 8.0.30

The PHP project’s Unsupported Branches page lists PHP 7.4 as reaching end of life on 28 Nov 2022, with 7.4.33 as its last release.

7.4 28 Nov 2022 (3 years, 10 months ago) 7.4.33

Calif says in its write-up that "The earliest affected path we found dates to PHP 5.4.0".

The earliest affected path we found dates to PHP 5.4.0; the available exploitation paths depend on the PHP version and SAPI but are always exploitable under default configurations.

Calif says of the exploitation paths in its write-up that they "depend on the PHP version and SAPI but are always exploitable under default configurations".

the available exploitation paths depend on the PHP version and SAPI but are always exploitable under default configurations.

Calif says it confirmed pre-auth RCE on WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 and WHMCS ("We confirmed pre-auth RCE on the following PHP apps as well as arbitrary PHP scripts in some instances.").

We confirmed pre-auth RCE on the following PHP apps as well as arbitrary PHP scripts in some instances. - WordPress 7.1.2 - Drupal 11.4.3 - Joomla 6.1.4 - MediaWiki 1.46.2 - Roundcube 1.7.4 - Magento 2.4.9 - phpMyAdmin 5.2.3 - Nextcloud 35.0.1 - Laravel 13.11 - Symfony 8.1 - WHMCS

Calif says in its write-up that the two vulnerabilities (CVE-2026-109618, CVE-2026-109619) were "discovered by Calif, OpenAI and Wiz".

This story outlines the details of two PHP remote vulnerabilities (CVE-2026-109618, CVE-2026-109619) discovered by Calif, OpenAI and Wiz, and addressed in PHP October 2026 Security Release.

Calif says: "No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery."

No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery.

Calif’s write-up describes the AI it used as "my LLM companion" and "our audit buddy" and does not name a model: the strings GPT and Sol do not appear in it, and it does not say which of the two CVEs any AI-assisted finding became.

I asked my LLM companion for help. ... We asked our audit buddy to go over ZendMM allocation behavior, fatal reporting, and request shutdown

Calif says: "We were not expecting to find anything critical - everyone and every lab had already done extensive AI assisted audits of this target."

We were not expecting to find anything critical - everyone and every lab had already done extensive AI assisted audits of this target.

Calif says its PHP audit began after "OpenAI invited us to join its Patch the Planet initiative".

Finally, we arrive in 2026. OpenAI invited us to join its Patch the Planet initiative, and PHP stood out as a high-impact target.

Calif’s timeline gives 1 August 2026 as the day Calif "discovered multiple different paths independently leading to RCE".

2026 — August 1Calif discovered multiple different paths independently leading to RCE that resurfaced the 2024 issues and new trigger points.

Calif’s timeline gives 11 August 2026 as the day Calif reported the first bug to PHP and started coordinated disclosure, and 21 August 2026 as the day it reported the second bug.

2026 — August 11Calif reported the first bug to PHP and started coordinated disclosure process. ... 2026 — August 21Calif reported the second bug to PHP.

Calif says of the hash-table bucket path: "This is RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 7.3." This differs from or adds to other sources: A version floor of 7.3 for this path; PHP's advisories name no version floor.

Apache reaches HashTable teardown and interprets the stale bucket, while PHP-FPM discards it with the terminated worker. This is RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 7.3.

Calif says of the session upload-progress path: "This results in RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 5.4.0."

This results in RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 5.4.0.

Calif says of PHP-FPM: "This is application-dependent RCE under both Apache mod_php and PHP-FPM. An application exposes the vulnerable transaction through a reachable post-startup decoding operation such as session_start(), session_decode() or unserialize() - including wrappers such as WordPress's maybe_unserialize()." This differs from or adds to other sources: States the application condition for the FPM path as a decoding operation; PHP's advisory says only "a suitable application operation". Calif also says the exploitation paths are "always exploitable under default configurations".

This is application-dependent RCE under both Apache mod_php and PHP-FPM. An application exposes the vulnerable transaction through a reachable post-startup decoding operation such as session_start() , session_decode() or unserialize() - including wrappers such as WordPress’s maybe_unserialize() .

Calif says: "PHP-FPM terminates its worker when php_request_startup() fails. Once startup has succeeded, however, an ordinary fatal during script execution follows the normal request-shutdown path, and the worker can accept another request."

PHP-FPM terminates its worker when php_request_startup() fails. Once startup has succeeded, however, an ordinary fatal during script execution follows the normal request-shutdown path, and the worker can accept another request.

Calif recommends as partial mitigations: "For PHP-FPM, disable session upload progress with session.upload_progress.enabled=0 and set memory_limit=-1." and "For mod_php, set memory_limit=-1."

For PHP-FPM , disable session upload progress with session.upload_progress.enabled=0 and set memory_limit=-1 . For mod_php , set memory_limit=-1 . These changes do not replace a patch.

CISA's Known Exploited Vulnerabilities catalogue (JSON feed, catalogVersion 2026.10.21, dateReleased 2026-10-21T14:04:39Z, count 1754), opened on 23 October 2026 at 08:29 UTC, does not list CVE-2026-109618 or CVE-2026-109619. The search was for 109618 and 109619 in every cveID and for PHP entries added since 15 October 2026, and found none. The feed was last modified on 21 October 2026 at 14:04:39 GMT, so it holds nothing added after that.

The advisory GHSA-6wmf-4rv5-p3rp for CVE-2026-109619 gives the same four affected-version ranges, "< 8.2.35", "< 8.3.36", "< 8.4.27" and "< 8.5.12"; it names no range for PHP 8.1 or older.

vulnerable_version_range: < 8.2.35, < 8.3.36, < 8.4.27, < 8.5.12 (patched_versions 8.2.35, 8.3.36, 8.4.27, 8.5.12)

The advisory says: "The exact affected versions, configuration and mitigations depend on the internal state affected by the producing operation."

The exact affected versions, configuration and mitigations depend on the internal state affected by the producing operation.

The advisory says: "Successful exploitation of this vulnerability requires both a producer and a consumer. The producer is a PHP operation that stores state owned by one request in a location PHP can access later in a subsequent request. The consumer is a subsequent PHP operation that reads, frees, branches or otherwise acts on the stale state previously stored by the producer."

Successful exploitation of this vulnerability requires both a producer and a consumer. The producer is a PHP operation that stores state owned by one request in a location PHP can access later in a subsequent request. The consumer is a subsequent PHP operation that reads, frees, branches or otherwise acts on the stale state previously stored by the producer.

The advisory says: "The producer and consumer requests must reach the same worker. Multiple workers and recycling reduce success per request but do not remove the condition."

The producer and consumer requests must reach the same worker. Multiple workers and recycling reduce success per request but do not remove the condition.

The advisory says: "There are two confirmed consumers before normal initialization." They are headed "INI diagnostics before request initialization" and "Session upload progress before normal initialization".

There are two confirmed consumers before normal initialization. ... INI diagnostics before request initialization ... Session upload progress before normal initialization

The advisory's case headed "PHP 8.5 fatal error backtrace: confirmed" says: "With `fatal_error_backtraces` enabled, fatal error reporting stores backtrace state owned by the request. Resetting of this global state is always missed during shutdown." It adds: "This is the strongest demonstrated case and is the basis of the confirmed mod_php exploitation."

PHP 8.5 fatal error backtrace: confirmed ... With `fatal_error_backtraces` enabled, fatal error reporting stores backtrace state owned by the request. Resetting of this global state is always missed during shutdown. ... This is the strongest demonstrated case and is the basis of the confirmed mod_php exploitation.

The advisory says of session upload progress: "Session upload progress is enabled by default, and no application call to `session_start()` is required. It can supply a producer, consumer or both, but exploitation still requires an interruption after state is published and a subsequent request handled by the same worker."

Session upload progress is enabled by default, and no application call to `session_start()` is required. It can supply a producer, consumer or both, but exploitation still requires an interruption after state is published and a subsequent request handled by the same worker.

The advisory says of session upload progress under mod_php and FPM: "With mod_php, both the producing operation and fatal error can occur during multipart startup. FPM terminates a child when this startup fails, so that exact sequence does not survive. The validated FPM path instead publishes state during application execution after successful startup, reaches a fatal error, and then uses session upload progress as the early consumer. It works with a normal dynamic FPM pool, although it depends on a suitable application operation."

With mod_php, both the producing operation and fatal error can occur during multipart startup. FPM terminates a child when this startup fails, so that exact sequence does not survive. The validated FPM path instead publishes state during application execution after successful startup, reaches a fatal error, and then uses session upload progress as the early consumer. It works with a normal dynamic FPM pool, although it depends on a suitable application operation.

The advisory says: "The demonstrated application-independent trigger is OOM during input processing. Other fatal errors at this stage can cause the same state transition, but generally require additional application, extension or configuration conditions."

The demonstrated application-independent trigger is OOM during input processing. Other fatal errors at this stage can cause the same state transition, but generally require additional application, extension or configuration conditions.

The advisory says of the INI-diagnostic consumer under mod_php: "With Apache mod_php, `.htaccess` and Apache `php_value`/`php_flag`/`php_admin_*` directory configuration is applied before `php_request_startup()`. Normal `php.ini` is startup configuration and is not reapplied as a consumer across requests."

With Apache mod_php, `.htaccess` and Apache `php_value`/`php_flag`/`php_admin_*` directory configuration is applied before `php_request_startup()`. Normal `php.ini` is startup configuration and is not reapplied as a consumer across requests.

The advisory says of the INI-diagnostic consumer under FPM: "FPM is conditionally exposed when nginx, Apache `mod_proxy_fcgi` or another frontend sends `PHP_VALUE`/`PHP_ADMIN_VALUE` parameters that produce a diagnostic before request initialization. FPM pool values are applied when a worker starts, and `.user.ini` is applied after normal initialization. They do not provide the same early consumer."

FPM is conditionally exposed when nginx, Apache `mod_proxy_fcgi` or another frontend sends `PHP_VALUE`/`PHP_ADMIN_VALUE` parameters that produce a diagnostic before request initialization. FPM pool values are applied when a worker starts, and `.user.ini` is applied after normal initialization. They do not provide the same early consumer.

The advisory says of LSAPI and FrankenPHP: "LSAPI can apply special environment INI values early and is a conditional candidate. An equivalent early configuration consumer was not established in the default configuration of FrankenPHP. This does not make this environment immune."

LSAPI can apply special environment INI values early and is a conditional candidate. An equivalent early configuration consumer was not established in the default configuration of FrankenPHP. This does not make this environment immune.

The advisory's impact section says: "The fatal backtrace path has confirmed RCE against mod_php. Session lifecycle RCE was validated against mod_php and FPM. Other state families establish security impact only after a concrete producer and consumer are shown."

The fatal backtrace path has confirmed RCE against mod_php. Session lifecycle RCE was validated against mod_php and FPM. Other state families establish security impact only after a concrete producer and consumer are shown.

The advisory says of other request state: "Whether it is reachable depends on the application, extensions and the exact point where the state was published."

Whether it is reachable depends on the application, extensions and the exact point where the state was published.

The advisory lists five conditions for a concrete vulnerability, the third and fourth being: "PHP releases the request memory while the persistent worker retains the referring global state." and "The same worker handles another request."

3. PHP releases the request memory while the persistent worker retains the referring global state. 4. The same worker handles another request.

The advisory's text on SAPIs names mod_php, FPM, LSAPI and FrankenPHP; the words CLI and CGI do not appear in the advisory.

With Apache mod_php ... FPM is conditionally exposed ... LSAPI can apply special environment INI values early ... the default configuration of FrankenPHP

The Netherlands NCSC's repository page says: "The impact is not limited to websites: PHP is also embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly."

The impact is not limited to websites: PHP is also embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly.

The Netherlands NCSC's repository page says: "PHP is a widely used open-source server-side scripting language, so these vulnerabilities may affect a broad range of internet-facing web applications and products that embed or depend on PHP." It gives no count.

PHP is a widely used open-source server-side scripting language, so these vulnerabilities may affect a broad range of internet-facing web applications and products that embed or depend on PHP.

In its software status list (entry of 23 October 2026, 10:47 CEST), the Netherlands NCSC php2shell repository records that the publisher Server Side Up reports v5.0.2 Docker images for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 rebuilt and tested for both CVEs, that the assessment covers those image variants only, and, of the Server Side Up images, that "PHP 8.1.34 remains unpatched"; it notes that image digests and running deployments were not verified.

CVE assessment: The publisher reports v5.0.2 images for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 rebuilt and tested for CVE-2026-109618. This assessment covers those versioned image variants only. PHP 8.1.34 remains unpatched; image digests and running deployments were not verified.