> ## Content Index
> Fetch the complete content index at: https://www.cybrsecmedia.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# PHP2Shell Patches Released: Critical RCE Flaws Threaten 70% of the Web
- URL: https://www.cybrsecmedia.com/php2shell-patches-released-critical-rce-flaws-threaten-70-of-the-web/
- Published: 2026-10-21T16:18:08.000Z
- Updated: 2026-10-21T16:18:23.000Z
- Description: PHP has released emergency fixes for two critical remote code execution vulnerabilities affecting its widely deployed web engine. Wiz researchers warn that AI-assisted exploitation raises the stakes, leaving organizations racing to patch exposed servers.
- Author: Bill Brenner
- Tags: PHP2Shell, Critical PHP Vulnerabilities, Article

[PHP has released emergency fixes ](https://www.php.net/archive/2026.php?ref=cybrsecmedia.com#2026-10-21-5)for two critical remote code execution vulnerabilities affecting its widely deployed web engine. Wiz researchers warn that AI-assisted exploitation raises the stakes, leaving organizations racing to patch exposed servers.

The PHP development team released emergency security patches Wednesday for two critical remote code execution vulnerabilities that threaten one of the internet's most widely used software components. The flaws could allow unauthenticated attackers to execute malicious code, steal sensitive information and potentially take control of vulnerable servers.

The vulnerabilities, **CVE-2026-109618 and CVE-2026-109619**, carry CVSS 4.0 severity scores of 9.2\. The PHP project has released fixes in versions **8.5.12, 8.4.27, 8.3.36 and 8.2.35**, urging administrators to update immediately.

But the bigger story is the extraordinary reach of the vulnerable technology.

According to [research published Wednesday by Wiz](https://www.wiz.io/blog/php2shell-php-rce?ref=cybrsecmedia.com), PHP powers approximately 70% of websites worldwide, including applications built on WordPress, Drupal, Joomla and MediaWiki. Wiz researchers demonstrated that vulnerabilities in the PHP engine itself could be exploited to execute code remotely without authentication, regardless of whether the applications running on top of it contain their own vulnerabilities.

Wiz has dubbed the exploitation technique **PHP2Shell**, drawing comparisons to Heartbleed and Log4Shell because of the potential consequences for widely deployed internet infrastructure.

And there's another troubling dimension: Artificial intelligence helped researchers turn flaws that had lurked in PHP for years into working exploits.

## AI turns longstanding PHP flaws into practical attacks

The vulnerabilities involve memory-safety problems in PHP's handling of fatal errors and interrupted requests. Under certain conditions, the PHP engine can leave corrupted internal state behind, allowing subsequent operations to access memory that should no longer be available.

That can create opportunities for attackers to execute arbitrary code or extract sensitive information from server memory, including passwords, authentication tokens, API keys and certificates.

Wiz researchers demonstrated pre-authentication remote code execution against WordPress, Drupal and Joomla deployments, combining several memory-corruption techniques into a single exploit.

The research is particularly significant because the vulnerabilities reside in PHP itself, rather than in individual content management systems or plugins.

Updating WordPress, Drupal or Joomla alone will not necessarily eliminate the underlying risk. Organizations must update the PHP runtime or install vendor-supplied fixes.

Wiz also highlighted how frontier AI models changed the economics of vulnerability exploitation.

The researchers said developing reliable exploits required chaining multiple flaws, adapting to different memory layouts and repeatedly testing complex attack sequences. Historically, that level of difficulty might have discouraged all but the most sophisticated researchers.

AI dramatically reduced the work involved.

According to Wiz, frontier models helped researchers develop and adapt working exploits across multiple applications within hours.

The implications extend well beyond PHP. Vulnerabilities once considered impractical to exploit may become viable as AI reduces the time, expertise and resources required to turn theoretical weaknesses into functioning attacks.

Wiz argues that PHP2Shell could become a defining example of how AI changes the practical exploitability of longstanding software vulnerabilities.

## Emergency patches arrive after premature disclosure

The emergency release follows an unusually tense disclosure process.

On Tuesday, reports surfaced that information about the vulnerabilities had leaked ahead of a planned Thursday announcement. Security researchers and intelligence firms began warning organizations to prepare for emergency updates.

Matt Johansen of VulnerableU was among those sounding the alarm.

[Johansen described](https://www.youtube.com/shorts/MC2rRi7NSgk?ref=cybrsecmedia.com) encountering an initially unverified Hacker News post about two critical PHP vulnerabilities. His concern grew when established cybersecurity intelligence companies began acknowledging the impending disclosure.

His message to defenders was straightforward: Organizations running PHP in production needed to prepare for immediate updates, even before the technical details became public.

The PHP security team subsequently accelerated its release schedule, announcing that patches would arrive Wednesday instead of Thursday.

That decision gave defenders an earlier opportunity to remediate their systems, but it also started the familiar race between security teams deploying fixes and attackers studying the changes for clues about exploitation.

This time, AI threatens to accelerate that race.

## Five steps PHP users must take now

With the patches available, the priority has shifted from preparation to deployment. Based on the PHP project's official guidance and established vulnerability-response practices, security teams should take five immediate steps.

**1\. Identify every PHP installation.** Inventory PHP versions across production servers, cloud environments, containers, content management systems and third-party hosting infrastructure. Include embedded PHP runtimes and legacy systems that may not appear in standard asset inventories.

**2\. Prioritize internet-facing systems.** Focus first on publicly accessible PHP installations, particularly systems processing web requests or handling sensitive information. PHP identifies Apache mod\_php deployments as especially concerning because a demonstrated exploit can trigger before application code executes.

**3\. Install the emergency security updates.** Upgrade supported installations to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, as appropriate. Linux distributions and long-term support vendors may distribute backported fixes under different package version numbers, so verify the security status of installed packages rather than relying solely on upstream version strings.

**4\. Address unsupported PHP versions.** PHP 8.1 and older no longer receive routine security releases from the PHP project. Organizations running these versions should obtain verified vendor backports or migrate to supported releases. The PHP security team has also provided limited source-level backports for PHP 7.4, 8.0 and 8.1.

**5\. Hunt for suspicious activity and verify remediation.** Review web server and application logs, unexpected process execution, suspicious file modifications and unusual outbound connections. Confirm that updated runtimes are actually in use, restart affected workers and validate application functionality after patching. Investigate evidence of compromise rather than assuming that installing a patch reverses an earlier intrusion.

## What if you can't patch immediately?

The [PHP security team](https://www.php.net/archive/2026.php?ref=cybrsecmedia.com#2026-10-21-5) has published temporary risk-reduction measures for organizations unable to deploy updates immediately.

For CVE-2026-109618, these include reviewing PHP memory limits, restricting request sizes and enforcing resource boundaries at the container or operating-system level.

For CVE-2026-109619, administrators can disable session upload progress, address certain error-handling conditions and, for PHP 8.5, disable fatal-error backtraces. Worker restarts are required for some configuration changes to take effect.

These measures have limitations and must be implemented according to the official advisory. Some settings can reduce exposure to known exploitation paths while leaving other variants possible.

The PHP project makes clear that there are no complete mitigations. Updating is the only safe choice.

Organizations relying on hosting providers or managed application platforms should confirm when those providers have deployed the relevant fixes. A patched operating system or updated application does not automatically mean every embedded PHP runtime is protected.

## A new test for vulnerability management in the AI era

The PHP2Shell disclosure illustrates a problem that cybersecurity teams are increasingly confronting: The window between vulnerability disclosure and practical exploitation is shrinking.

For years, defenders could sometimes rely on the complexity of certain vulnerabilities to buy time. Even when a serious flaw was publicly documented, developing a reliable exploit might require extensive reverse engineering and specialized expertise.

AI is eroding that advantage.

PHP2Shell is particularly alarming because it combines three difficult realities: vulnerabilities buried deep in widely deployed software, enormous potential exposure and increasingly capable AI systems that can accelerate exploit development.

Wiz's findings do not mean every website running PHP can be compromised through the same attack sequence. Exploitability depends on the vulnerable version, deployment architecture and specific attack conditions.

But the demonstrated ability to compromise major PHP application deployments without authentication should eliminate any temptation to delay patching.

For security teams, the immediate job is to identify vulnerable PHP installations and deploy the appropriate fixes. 

[![](https://storage.ghost.io/c/ab/67/ab676516-71e3-473d-8f73-9e0692f5aaee/content/images/2026/10/2027-Events-Banner-50.png)](https://www.cybrsecmedia.com/conference/)