PHP Core Vulnerabilities Patched That Could Allow Remote Code Execution

On October 21, 2026, the PHP team released an update fixing several memory-safety vulnerabilities in the language’s core. As Wiz Research reports, researchers demonstrated unauthenticated remote code execution and the ability to read PHP process memory. Website owners should check which PHP version serves their site and install the security update: the issue is in PHP itself, not just in applications built on it.

What Researchers Found in PHP

The researchers grouped the flaws under CVE-2026-109618 and CVE-2026-109619. The highest severity score is 9.2 under CVSS. According to Wiz, every PHP version released over the past decade is affected by at least one of the issues; affected versions go back as far as PHP 5.4. That does not mean the same attack will work against every site: the exploit chain depends on the version, configuration, and application behavior.

The flaws relate to how PHP handles fatal errors during a request, particularly out-of-memory errors. The request stops, but PHP may retain a reference to freed memory or be left in an invalid state. That data is then reused when subsequent requests are processed. In some cases, this makes it possible to read process memory; in others, it can be chained into code execution.

Wiz tested its php2shell exploit on WordPress, Drupal, and Joomla using their container images that were current at the time of testing. The demonstrated attacks did not require authentication. The CMS platforms are examples here: the vulnerable code is in PHP, so, as the researchers note, even a simple application running on a vulnerable version of the language may be affected.

The team also demonstrated the ability to read process memory without executing code. That memory may contain passwords, tokens, and API keys, including data unrelated to the attacker’s request. The risk therefore cannot be assessed solely in terms of whether an attacker can execute code on the server.

Why the Exploit Chains Became Practical

The flaws had remained in the codebase for more than ten years. To build a working exploit, the researchers had to combine several failures and account for how PHP allocates and reuses memory. A different version, configuration, or application behavior could break the chain and require further testing.

The team used AI models to find the flaws, develop and detect attacks, and verify the fix. Wiz says the models helped it create and adapt working exploits for different applications within hours. That describes the research results; it is not a claim that an attack will automatically work against every server.

Before publication, the team worked with PHP developers and others to verify the fix and prepare defensive measures. The report examines four exploitation cases in detail across the two CVEs; the researchers also mention other variations of the flaws. In their assessment, updating PHP addresses the common root cause of these issues in the patched release.

What Website Owners and Developers Should Check

The first step is to find out which PHP version actually handles the site’s requests and install the security update. Checking for CMS and plugin updates is not enough: the flaws described here sit below the application layer. The report does not list the patched version numbers, so the name of the CMS alone cannot tell you whether the risk has been addressed.

If an immediate update is not possible, watch for unusual multipart requests followed by out-of-memory errors or repeated HTTP 500 responses. Other possible signals include unexpectedly large or malformed PHPSESSID cookies and unexplained changes in PHP worker processes. These are leads for an investigation, not a substitute for updating: application logs may contain little useful information. The researchers identify installing the PHP fix as the complete remedy.

The risk includes server-side code execution and the disclosure of sensitive data from process memory. So even if the site’s own code has no known flaw, it is important to check the component it runs on. For the team responsible for a site, this is a separate task from updating the application and its add-ons.

My Take: Update the Foundation, Not Just the Site

As a junior backend developer, I see this as a clear illustration of where an application’s responsibility ends. You can write an API carefully, but fixing your own code will not resolve a flaw inside PHP’s request handling. I would start with a few simple questions: where is the project’s PHP running, who updates it, and is it clear when the fix will reach the production server?

The role of AI in the research also caught my attention. To me, the main takeaway is not that models were used, but that the difficulty of assembling an exploit chain no longer looks like a reliable barrier. It is a good reason to pay closer attention to updates for core components, even when the team’s focus is entirely on site features.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. PHP2Shell: AI uncovers critical RCE in PHP www.wiz.io

About the author

Bekzhan Khalelov

Aspiring backend developer

I’m building my first APIs and trying to connect them to the frontend in practice projects. I’m currently testing caching on a product catalog—it’s taken surprisingly long to get the data updates right.

All posts by the author