Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution

Key Takeaways

  • CVE-2026-109618 and CVE-2026-109619 are critical vulnerabilities in PHP’s core runtime, each rated CVSS 9.2.
  • Both flaws can enable remote code execution without authentication. One can also expose sensitive data in PHP process memory.
  • The vulnerabilities affect PHP installations that serve web requests, including environments running WordPress, Drupal and Joomla.
  • Fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • Updating WordPress core, themes and plugins does not patch the PHP runtime.
  • Administrators must update the correct PHP service, restart or redeploy it, and verify that the running environment uses a fixed build.
  • Temporary configuration changes can reduce exposure to specific attack paths, but the PHP project confirms that updating is the only complete remediation.

Two critical vulnerabilities in the PHP runtime, disclosed on 21 October 2026, could allow attackers to execute code on vulnerable web servers without authentication. Identified as CVE-2026-109618 and CVE-2026-109619, both vulnerabilities have a CVSS v4.0 severity score of 9.2 out of 10. The PHP development team has released security updates for supported PHP branches. Website owners, hosting providers and development teams should prioritize verifying that every exposed PHP installation is patched.

The vulnerabilities affect the PHP execution environment itself. Consequently, updating WordPress, Joomla, Drupal, a plugin or a theme does not resolve the underlying problem. The PHP runtime serving the application must receive the security fix.

Security researchers demonstrated pre-authentication remote code execution against representative WordPress, Drupal and Joomla deployments. They also demonstrated that the flaws could expose sensitive data from PHP worker memory. The findings make this a server-level security issue that requires action from website owners and infrastructure administrators, not just application developers.

What Are the PHP2Shell Vulnerabilities?

PHP is a server-side programming language used to generate dynamic websites and operate web applications. It powers content management systems such as WordPress, Drupal and Joomla, as well as custom web applications and business platforms.

On 21 October 2026, the PHP project released security updates addressing two critical vulnerabilities in the language’s core runtime. The research and associated exploit chain have been described under the name PHP2Shell. The vulnerabilities themselves are tracked as separate Common Vulnerabilities and Exposures (CVE) entries.

VulnerabilityTechnical issuePrincipal security impact
CVE-2026-109618Out-of-memory handling and memory corruptionRemote code execution and disclosure of PHP process memory
CVE-2026-109619Use-after-free involving stale internal stateRemote code execution through corrupted runtime state

Both vulnerabilities arise from PHP’s handling of memory and internal state when request processing is interrupted or encounters certain error conditions. They are not confined to a specific content management system or vulnerable application component.

The PHP project identifies all installations serving web requests as potentially affected, including PHP-FPM, Apache with mod_php , php-cgi , FrankenPHP and LiteSpeed. Its advisory identifies mod_php as the highest-risk configuration among these environments.

This distinction matters because a vulnerability in the runtime can affect multiple websites hosted on the same infrastructure. Each application does not need to contain a separate programming error for the shared PHP environment to be exposed.

How Do CVE-2026-109618 and CVE-2026-109619 Work?

The vulnerabilities have different technical causes, although both involve unsafe memory handling.

CVE-2026-109618: Out-of-memory corruption

PHP uses an out-of-memory handling mechanism to interrupt request processing when certain memory allocation failures occur. During parts of this process, internal request data may be only partially initialized.

If an allocation fails at the wrong point, PHP may exit the operation without correctly maintaining or resetting that internal state. Subsequent cleanup can then process invalid memory as though it contained valid structures.

Under exploitable conditions, this can cause memory corruption and allow an attacker to execute code remotely. Researchers also demonstrated unauthenticated disclosure of data residing in PHP worker memory, potentially exposing credentials, tokens and API keys.

The important security implication is that an attacker may target the underlying PHP request-processing mechanism rather than a specific application feature.

CVE-2026-109619: Use-after-free and stale runtime state

The second vulnerability involves internal PHP state that survives after the memory associated with a request has been released.

A PHP worker can retain certain global state across requests. Normally, PHP must reset any state that references request-owned memory before that memory is freed or reused. Under affected conditions, an error or interrupted operation can leave a reference to memory that is no longer valid.

A subsequent request may access that stale reference before PHP completes normal initialization. The resulting use-after-free condition can lead to memory corruption and, under exploitable conditions, remote code execution.

The flaw illustrates why memory management in long-running server processes requires careful control of object lifetimes and state transitions. Releasing memory does not eliminate the risk if another part of the runtime continues to reference it.

Why can these vulnerabilities affect an application before it executes?

PHP processes HTTP requests through its runtime before the application necessarily begins executing its own code. If the vulnerable condition occurs during request parsing or early initialization, WordPress or another application may not yet have an opportunity to validate the request or apply its own security controls.

The PHP project has documented a demonstrated attack path that can be triggered before application code runs. This limits the effectiveness of application-level defenses when they are used without runtime patching.

Which PHP Versions Are Affected?

The fixes are available in four stable PHP releases published on 21 October 2026.

PHP branchFixed release
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Versions earlier than the corresponding fixed release are affected unless the software vendor has independently confirmed that its package includes the relevant security patches. Linux distributions and long-term-support vendors may backport fixes without changing the upstream PHP version number in the same way. Administrators must therefore check the actual package revision and vendor security notice, not rely exclusively on the displayed version number.

What about PHP 8.1 and older?

Older PHP branches require additional attention. Google Cloud reported that the vulnerabilities extend to PHP versions dating back to 5.4. The PHP project no longer provides routine security updates for PHP 8.1 and earlier, although it has published minimal source backports for PHP 7.4, 8.0 and 8.1 to help organizations that build from source or lack access to a suitable vendor package. Some distributions and commercial support providers may also supply backported fixes.

For an older installation, administrators should confirm whether a verified patch is available from their operating system vendor or support provider. If not, migrating to a supported PHP branch is the appropriate course of action.

Running an older version with no verified fix should not be treated as acceptable simply because the application appears to function normally.

What Do the Vulnerabilities Mean for WordPress and Other Websites?

WordPress sites deserve particular attention because the platform depends on PHP for application execution. However, the issue is not specific to WordPress.

Researchers demonstrated remote code execution against representative deployments of WordPress, Drupal and Joomla. The research also established that exploitation does not inherently depend on a flaw in any of those applications. A minimal PHP application can be vulnerable when it runs on an affected runtime.

The practical risk depends on the privileges and resources available to the compromised PHP process.

Potential consequences include:

  • Unauthorized access to application files and configuration data.
  • Exposure of database credentials, API tokens or other secrets available to the PHP worker.
  • Unauthorized changes to website content or application data.
  • Execution of malicious code within the permissions available to the affected process.
  • Service disruption or further compromise of infrastructure, depending on the server’s configuration and security boundaries.

The memory-disclosure component is also significant. Even when remote code execution is not achieved, sensitive information in process memory may be exposed. Consequently, response planning should account for both execution and confidentiality risks.

Why updating WordPress is not enough

WordPress core, themes and plugins are separate from the PHP runtime that executes them. Installing a WordPress security update changes application files. It does not necessarily change the PHP binary or package serving HTTP requests.

The same distinction applies to managed hosting. A website administrator may not have permission to change PHP directly because the provider manages the runtime. In that case, the administrator must obtain confirmation from the provider that the security patches have been installed and that the active PHP processes have been restarted.

For development agencies and hosting providers, this means reviewing the complete environment rather than treating each WordPress installation as an isolated application-level update task.

What Is Known About Exploitation?

The published research establishes that the vulnerabilities can be exploited under appropriate conditions. However, exploit behavior varies between PHP builds and deployment configurations.

Researchers reported successful unauthenticated remote code execution against WordPress, Drupal and Joomla test deployments. It also demonstrated memory disclosure.

Wordfence conducted additional testing and reported more qualified results:

  • For CVE-2026-109619, its researchers demonstrated code execution in a specially configured PHP 8.5.11 Apache laboratory environment. The same proof of concept crashed a normal optimized build rather than executing code.
  • For CVE-2026-109618, Wordfence observed failures or restarts in some vulnerable PHP and WordPress test environments, but did not independently achieve code execution in its testing of that CVE. 

These results do not contradict the critical severity ratings. They show that exploitability can depend on the runtime build, memory layout and configuration, and that a successful exploit against one environment may not work identically against another.

CERT-EU reported that proof-of-concept exploits had begun circulating following public disclosure and warned that this increased the likelihood of exploitation. The sources reviewed here do not establish the scale of any active exploitation campaign. Administrators should nevertheless act immediately rather than wait for a confirmed incident or a more portable exploit.

How Should Website Owners Respond?

The appropriate response is to identify exposed PHP installations, apply a verified fix and confirm that the patched runtime is actually handling requests.

1. Identify every affected PHP environment

Create an inventory of PHP installations used for production websites, staging environments, externally accessible development systems and application containers.

Do not assume that every site on a server uses the same PHP version. Different virtual hosts, PHP-FPM pools, containers or hosting plans may run separate environments.

For WordPress sites, the PHP version reported under Tools -> Site Health -> Info -> Server helps identify the runtime used by the site. A command-line check such as php -v may report a different PHP installation from the one serving HTTP requests.

2. Install the appropriate security update

For supported upstream branches, use the fixed release corresponding to the installed PHP branch:

  • PHP 8.5.12 or later within the appropriate branch.
  • PHP 8.4.27 or later within the appropriate branch.
  • PHP 8.3.36 or later within the appropriate branch.
  • PHP 8.2.35 or later within the appropriate branch.

If a hosting provider, Linux distribution or managed runtime supplies PHP, verify that its package includes fixes for both CVEs. A version string alone may not establish whether a vendor backport has been applied.

For older branches, contact the vendor or plan a migration to a supported version. Do not assume that a patch exists simply because the PHP installation continues to receive application updates.

3. Restart or redeploy the PHP runtime

Installing a patched package is not the end of remediation. Running worker processes must use the updated code.

Depending on the deployment, this may require restarting PHP-FPM, Apache or another PHP service. Containerized environments should be rebuilt from updated base images and redeployed. Custom runtime images need particular attention because they may not receive automatic base-image updates.

4. Verify the running version and application behavior

After the update, confirm that the PHP service handling website traffic uses the fixed package. Check the version and package revision through the hosting provider, operating system package tools or deployment image.

Then test the website’s critical functions, including authentication, forms, file uploads, integrations and other workflows that may be affected by runtime or configuration changes.

For managed hosting, request explicit confirmation that both CVE fixes have been installed and the relevant PHP workers restarted.

5. Review security logs where exposure persisted

If an installation remained unpatched after public disclosure, preserve relevant logs and investigate suspicious activity. This is particularly important for systems that process sensitive data or expose administrative functionality.

Potential warning signs include unusual request patterns, repeated PHP errors or HTTP 500 responses, unexplained worker restarts and abnormal application behavior. These indicators are not definitive evidence of exploitation, and attacks that occur before application code runs may leave limited application-level evidence.

If there are credible signs of compromise, investigate the affected host and application, determine which credentials and systems the PHP process could access, and rotate potentially exposed secrets as part of the incident response.

6. Coordinate updates across managed websites

Agencies and hosting providers should review all affected client environments, not only the primary public website. This includes staging instances, origin servers, older containers and any separately managed PHP services.

A centralized inventory and documented patch-verification process make it easier to establish which environments have been remediated and which still require action.

What If PHP Cannot Be Updated Immediately?

The PHP project has documented temporary measures that can reduce exposure to specific attack paths. These measures do not provide complete protection and must not be treated as substitutes for applying a security update.

Depending on the runtime and application requirements, interim steps can include:

  • Disabling PHP session upload progress before request parsing.
  • Applying additional request-size and multipart-request limits at the web server or reverse proxy.
  • Adjusting relevant memory-handling settings under controlled conditions.
  • On PHP 8.5, disabling fatal-error backtraces to block the documented fatal-backtrace attack path.

These options have limitations. Some can affect file uploads, application behavior or resource management, and blocking a documented attack path does not necessarily prevent other variants. For example, changing PHP memory-limit behavior does not eliminate all possible memory-allocation failures.

Where a patch cannot be deployed promptly, CERT-EU recommends considering isolation of internet-facing applications until remediation is complete and verified. The appropriate interim response depends on the application’s availability requirements and the infrastructure available to contain risk.

Administrators should consult the official PHP security advisory before modifying production configuration. Every temporary mitigation should have an owner, a documented reason and a plan for removal once the permanent fix has been applied.

Conclusion

CVE-2026-109618 and CVE-2026-109619 demonstrate the security implications of memory-management failures within widely deployed server-side runtimes. Both vulnerabilities can enable unauthenticated remote code execution, and one also permits disclosure of data held in PHP process memory.

The immediate priority is straightforward: identify every affected runtime, install a verified security update, restart or redeploy the service, and confirm that the patched environment is serving requests.

For WordPress owners, a fully updated CMS does not guarantee that its underlying PHP runtime is secure. Development teams, agencies and hosting providers must coordinate remediation at the infrastructure layer and review any period of exposure where compromise may have occurred.

Maintaining the security of a PHP-based website requires attention to application code, runtime dependencies, server configuration and operational patching. These responsibilities need to be managed together.

Resources

  1. PHP Security Advisory: Critical Remote Code Execution Vulnerabilities, Update Now. The upstream PHP project’s affected-version guidance, fixed releases and temporary mitigations. 
  2. Google Cloud: Responding to Core PHP Vulnerabilities CVE-2026-109618 and CVE-2026-109619. Security implications and cloud deployment remediation guidance.
  3. CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP. Risk assessment, affected products and recommended mitigations.
  4. Wordfence: Why It’s Urgent to Update PHP on Your WordPress Site. WordPress-specific guidance and independent laboratory testing.
  5. Wiz Research: PHP2Shell, AI Uncovers Critical RCE Vulnerabilities. Original research describing the vulnerability mechanisms, demonstrated impact and coordinated disclosure.
  6. PHP GitHub Advisory: CVE-2026-109618. Official technical advisory for out-of-memory corruption.
  7. PHP GitHub Advisory: CVE-2026-109619. Official technical advisory for stale global state.

Playful Sparkle has engineered digital products since 2004. Our Web Development services help businesses build and maintain reliable digital platforms. Contact Playful Sparkle to discuss your website’s technical requirements and ongoing maintenance needs.

Was this helpful - Post
Add playfulsparkle.com as a preferred source on Google
Zsolt Oroszlány

Zsolt Oroszlány

Founder & Chief Creative Officer of Playful Sparkle since 2004, combining business leadership, digital strategy, design, and software engineering to help organizations build effective digital solutions. Regularly publishes insights on web development, SEO, design, and emerging technologies.

More Insights