PHP2Shell Vulnerability 2026: PHP Fixes & Server Security

A serious security threat has emerged for websites and applications powered by PHP. Two critical vulnerabilities, collectively known as PHP2Shell, could allow attackers to execute malicious code on vulnerable servers without knowing a password or logging into an application. Both vulnerabilities have a CVSS v4.0 severity score of 9.2 out of 10. 2 3

On October 21, 2026, the PHP development team released security updates addressing CVE-2026-109618 and CVE-2026-109619. The fixes are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. 1

The security flaws affect the underlying PHP runtime, rather than a particular website plugin. PHP-powered websites and applications may therefore be exposed when their hosting environments use vulnerable installations. The PHP team identifies web-serving configurations including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk. 1

Amazon Threat Intelligence has reported exploitation attempts, making this an urgent issue for developers, businesses and hosting administrators. An observed attempt does not, by itself, establish that a server was successfully compromised. 5

This guide explains what PHP2Shell is, how the vulnerabilities work, which PHP versions contain the fixes, and the steps to take to protect applications and servers.

Priority action: Install a patched PHP release or a verified vendor security backport, restart the affected workers, and confirm that the updated runtime is serving your applications. Temporary workarounds do not completely fix both vulnerabilities. 1 7

What Is the PHP2Shell Vulnerability?

PHP2Shell refers to two critical vulnerabilities affecting PHP's handling of memory and internal request state:

CVE-2026-109618: Memory corruption during out-of-memory handling can lead to remote code execution. 2
CVE-2026-109619: Stale internal state can cause use-after-free conditions, memory disclosure and remote code execution. 3

Remote code execution, or RCE, means an attacker can cause a remote system to execute attacker-controlled code. For these vulnerabilities, confirmed execution occurs with the permissions of the affected web worker account, not automatically with root or administrator privileges. 2 3

This distinction matters: the potential damage depends on which files, credentials, databases and other services that account can access. Application authentication alone is not sufficient protection for attack paths that run before application code. 2 8

PHP2Shell Vulnerability Overview

Key facts from the PHP security advisories. 1 2 3

Detail	Information
Vulnerability name	PHP2Shell
CVE identifiers	CVE-2026-109618 and CVE-2026-109619
Severity	Critical
CVSS v4.0 score	9.2/10 for each vulnerability
Security release date	October 21, 2026
Main risk	Unauthenticated remote code execution
Affected technology	Vulnerable PHP runtimes serving web requests
Patch availability	Fixed releases are available
Recommended action	Update PHP and verify the running services

How Do the PHP2Shell Vulnerabilities Work?

1. CVE-2026-109618: Out-of-Memory Corruption

When a memory allocation fails, PHP may interrupt an operation before its internal request data has been fully initialized. During cleanup, PHP can then process that incomplete data as though it were valid. Under the necessary conditions, an attacker can use this behavior to achieve remote code execution. 2

Multipart request parsing is among the relevant processing paths. The official advisory describes a demonstrated attack against Apache mod_php that occurs before application-specific code starts running. Exploit reliability varies with the PHP build, extensions, server behavior and memory layout. 2

2. CVE-2026-109619: Stale Global State

PHP workers can process multiple requests. Some internal state points to memory owned by a particular request and must be cleared before that memory is released. If the state survives, a later request handled by the same worker can access memory that is no longer valid. 3

This use-after-free condition can expose memory or enable code execution. The advisory reports validated session-lifecycle RCE against mod_php and PHP-FPM. Having multiple workers or recycling them does not eliminate the underlying vulnerability. 3

Which PHP Versions Are Affected?

The following table shows the affected supported branches and their first fixed upstream releases. 7

PHP branch	Affected upstream versions	First fixed release
PHP 8.5	8.5 releases before 8.5.12	8.5.12
PHP 8.4	8.4 releases before 8.4.27	8.4.27
PHP 8.3	8.3 releases before 8.3.36	8.3.36
PHP 8.2	8.2 releases before 8.2.35	8.2.35
PHP 8.1 and older	Legacy branches require assessment	Migrate or verify an appropriate security backport

Vendor backports matter. Linux distributions and long-term-support providers may deliver the fix without changing the package's upstream version to one shown above. Check the vendor advisory and full package revision rather than relying on a version number alone. 7

PHP 8.1 and older are outside normal upstream support. Because of the severity, the PHP security team also provided minimal source backports for PHP 7.4, 8.0 and 8.1. These exceptional patches do not restore normal support for those branches; use a verified vendor package or arrange a migration. 4

Is PHP2Shell Being Actively Exploited?

Exploitation attempts have been observed. Amazon Threat Intelligence reported an attempt in its MadPot telemetry on October 17, 2026, before public disclosure. It also reported additional attempts around the October 21 release and broader activity afterward. 5

Amazon noted that it was unclear whether the observed attempts would have succeeded against real-world systems. Keep the distinction between attempted exploitation and confirmed compromise clear. Its recommendation is to investigate relevant activity from at least October 17, rather than treating the public disclosure date as the beginning of possible exposure. 5

What Could Happen If a PHP Server Is Compromised?

The following are potential consequences of code execution with a web worker's permissions, not a claim that every exposed website has suffered these outcomes. 2 9

Unauthorized Access to Application Data

An attacker may read files and use credentials available to the application account. Review access to configuration, customer information and connected databases.

Website Modification and Malware

Writable application directories may permit unauthorized files, altered pages or malicious redirects. Keeping deployed code read-only to the web worker can reduce this particular risk.

Exposure of Application Secrets

Database passwords, API keys and service tokens accessible to the compromised process may need to be treated as exposed.

Persistence and Further Access

An attacker may attempt to maintain access or reach other services. The initial compromise does not automatically grant root access; permissions and isolation affect the resulting damage.

Business Disruption

Consider the operational impact of downtime, investigation and recovery. Prepare a response plan before making emergency production changes.

Are WordPress, Laravel, Drupal and Joomla Websites Affected?

They may be exposed when their PHP runtime is vulnerable. Assess the hosting environment, not just the application name. PHP-based products can be affected even when administrators do not directly manage the bundled runtime. 4

WordPress Websites

WordPress states that these issues are not specific to WordPress and do not require a WordPress update. Updating plugins, themes or WordPress core does not replace the PHP runtime fix. Check the PHP version under Tools > Site Health > Info > Server, then verify patch status with the host. 6

Laravel, Drupal, Joomla and Custom PHP Applications

For each application, identify the PHP service or container that executes its web requests. Updating application dependencies is a separate maintenance task; verify that the interpreter itself contains both security fixes. Include staging sites, administration panels and other PHP-based services in the assessment. 4 7

How to Check Whether Your PHP Website or Server Is Vulnerable

Step 1: Check the Command-Line PHP Version

On a server you administer, use:

php -v

This is an inventory starting point, not proof of the website's patch status. Check separately for multiple PHP installations and for packages maintained through security backports. 7

Step 2: Identify the Runtime Serving Each Website

Inspect the hosting panel, virtual-host settings, PHP-FPM pools and container definitions. Record which runtime serves each application instead of assuming that every site uses the command-line installation. 7

Recommended precaution: Use authenticated administration tools for inspection rather than leaving a publicly accessible diagnostic page on the website.

Step 3: Ask Your Hosting Provider to Confirm Both Fixes

For managed or shared hosting, ask for confirmation of the exact runtime and vendor package revision. WordPress also recommends checking your host's security updates. 6

Please confirm that the PHP runtime serving my website is patched for CVE-2026-109618 and CVE-2026-109619, including any vendor backports, and that all affected workers have been restarted.

Step 4: Check the Entire Deployment

Include separate servers, containers, PHP-FPM pools, staging environments and products that bundle PHP. Keep a record of the package or image version and the advisory establishing its fixed status. 7

How to Fix PHP2Shell and Secure Your PHP Server

Install a verified security update. The following deployment checklist separates installing the fix from confirming that it is actually in use. 7

Step 1: Prepare Backups and a Recovery Plan

Before changing production, prepare verified backups of the application, configuration and database. Record the current deployment and plan how to recover from compatibility problems without leaving a vulnerable service publicly exposed.

A backup is a recovery precaution, not a security patch.

Step 2: Select a Patched PHP Package or Release

Choose a maintained release containing the fixes, or an explicitly verified vendor backport. Use the fixed-version table above and the relevant vendor advisory; do not assume that selecting an arbitrary newer-looking package is sufficient. 4 7

Step 3: Apply Updates Through Your Supported Deployment Process

For distribution-managed servers, use your operating system's supported security-update process. For hosting panels and appliances, follow the product vendor's instructions. Confirm that your configured repositories actually provide the required fixes. 4

On Debian or Ubuntu systems, refreshing package metadata is commonly done with:

sudo apt update

This command alone does not install the PHP patch. Review the available security update and install the relevant packages using the distribution's instructions. Package names and required changes depend on your deployment.

Step 4: Restart the Affected Workers

Restart the relevant PHP-FPM or web-server services after updating. Ensure that every affected instance is running the patched binaries; installing a package is not the same as verifying the active processes. 7

Use your actual service names and deployment procedure rather than copying a restart command intended for a different PHP branch.

Step 5: Rebuild and Replace Affected Containers

For container deployments, verify the runtime inside the application image. Rebuild with a patched base, redeploy and replace affected running instances; also check the image used for future replicas and deployments. 8

As a deployment precaution, record the image digest and the runtime package details so remediation can be reproduced.

Step 6: Verify Security and Application Behavior

Confirm the running PHP version or vendor patch revision for each application. Then perform a focused smoke test:

Public pages and APIs: Confirm that key routes return expected responses.
Authentication and data: Test login, sessions and database operations.
Uploads and jobs: Test required uploads, scheduled tasks and background processing.
Logs and extensions: Investigate new errors or missing extension dependencies.

Keep the verification results with the deployment record. A successful installer message alone should not close the remediation task.

What If You Cannot Update PHP Immediately?

Temporary controls reduce exposure; they are not a complete fix. CERT-EU recommends considering isolation of internet-facing applications when immediate patching is not feasible. 4

Restrict Public Access

Consider taking the vulnerable service offline or restricting it to authorized private access while remediation is completed. Put restrictions in front of PHP, rather than relying only on application-level login checks. 4 8

Use WAF and Request-Filtering Controls

Check your provider's PHP2Shell protections, confirm that relevant rules are active, and test legitimate traffic. A WAF is an additional defensive layer, not evidence that the runtime has been patched. 6 9

Restrict Unnecessary Multipart Uploads

Amazon recommends considering a block on multipart uploads for unpatched deployments after assessing application impact. Apply filtering before requests reach PHP, and do not assume blocking one upload route removes every attack path. 5 8

Review the Official Configuration Workarounds Carefully

The official guidance includes disabling session upload progress for specific confirmed paths:

session.upload_progress.enabled=0

Apply it in configuration that takes effect before request parsing and restart all workers. Do not rely on an application-level ini_set() call. For PHP 8.5, the advisory also describes disabling fatal_error_backtraces for one confirmed path. Neither change is complete protection. 4

Do not casually change memory limits. The advisory's memory-management workarounds have availability trade-offs and do not eliminate every allocation-failure path. Have an experienced administrator evaluate the official guidance rather than treating a memory setting as a substitute for patching. 2

How to Detect Possible PHP2Shell Attacks

Amazon recommends reviewing web logs, unexpected process execution and file modifications. Investigate from at least October 17, 2026, or earlier where your evidence warrants it. 5

Review Requests and PHP Errors

Look for unusual multipart submissions, memory-exhaustion errors and unexpected worker behavior. Investigate suspicious requests containing PHP_SESSION_UPLOAD_PROGRESS, but do not treat that field alone as proof of compromise. A lack of matching logs is not proof of safety. 5 8

Check Processes and File Changes

Compare deployed files against trusted build or version-control records. Investigate unexpected executable files, unfamiliar commands launched by web workers and unusual outbound connections. 5 9

Respond to Suspected Compromise

Recommended response precautions include isolating the affected environment, preserving relevant logs and evidence, and assessing which secrets the application account could access. Rotate potentially exposed credentials from a trusted environment and rebuild from a known-clean deployment when compromise is established.

Patching a vulnerability and recovering from an intrusion are separate tasks. Do not assume that installing the fix removes unauthorized files or invalidates stolen credentials.

PHP Server Security Best Practices for Long-Term Protection

Use the following operational checklist as a starting point for reducing the impact of future vulnerabilities:

Maintain an inventory: Record PHP versions, extensions, services, containers and the people responsible for updates.
Use supported software: Track runtime and application security releases, and plan migrations before support ends.
Apply least privilege: Separate application accounts and limit their access to files, databases and other services.
Protect credentials: Keep production secrets out of repositories and separate development, staging and production access.
Limit administrative exposure: Restrict management interfaces and use strong administrator authentication.
Monitor and rehearse recovery: Centralize useful logs, investigate unexpected changes and test backup restoration.

Runtime updates and limiting worker privileges are particularly important for the PHP2Shell risk described in the advisories. 7 9

Frequently Asked Questions About PHP2Shell

What Is PHP2Shell?

PHP2Shell is the name used for CVE-2026-109618 and CVE-2026-109619, critical PHP memory-handling vulnerabilities that can permit unauthenticated remote code execution under the necessary conditions. 8

Which PHP Versions Fix PHP2Shell?

The first fixed upstream releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Vendor-maintained packages may contain equivalent backported fixes. 7

Can an Attacker Exploit It Without a Password?

Yes. The advisories describe unauthenticated attack paths. Successful exploitation still depends on the relevant deployment and execution conditions. 2 3

Does Updating WordPress Fix PHP2Shell?

No. The underlying PHP installation must be patched. WordPress states that no WordPress update is required or planned specifically for these runtime vulnerabilities. 6

Should Shared-Hosting Customers Take Action?

Yes. Ask the host to confirm that the runtime serving your site has both fixes. Do not assume the issue is resolved merely because the website still works. 6

Can a WAF Completely Replace the PHP Update?

No. Request filtering can reduce exposure to known patterns, but only an appropriate PHP security update completely addresses the vulnerabilities. 8

Are PHP 7.4 and PHP 8.1 Safe to Keep Using?

Do not assume so. These branches are outside normal upstream support. Verify an applicable vendor fix or exceptional source backport, and plan migration to a maintained branch. 4

How Can I Reduce Future PHP Security Risks?

Maintain an update process, minimize application permissions, protect secrets, monitor unusual behavior and test recovery procedures. Treat these as ongoing operational responsibilities, not a one-time checklist.

Final Thoughts: Patch PHP and Verify the Result

The key action is to patch the PHP runtime that actually serves your applications, restart or replace affected workers, and verify the deployment. Review suspicious activity separately rather than assuming a security update proves that no earlier intrusion occurred. 7 5

Identify the affected systems, apply verified fixes, confirm the running services, and investigate signs of compromise.

Official Sources and Further Reading

This article was reviewed against the following sources on October 23, 2026. Check the advisories for subsequent updates before making production changes.