PHP2Shell is the name used for two critical vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619. PHP’s security team rated both CVSS v4.0 9.2. An unauthenticated attacker who can send requests to an affected PHP web service may be able to execute code in the context of its PHP worker. The PHP project released fixes on October 21, 2026.
If your website, API, control panel, or internal application serves requests through PHP, inventory and update the PHP runtime that actually handles traffic. A framework update or a php -v check in the wrong environment does not establish that the web-facing runtime is patched.
PHP2Shell at a glance
| Question | Short answer |
|---|---|
| What is PHP2Shell? | A pair of PHP core memory-safety vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. |
| What is the impact? | The PHP team describes both as critical remote-code-execution vulnerabilities. Researchers also demonstrated process-memory disclosure. |
| Who should act? | Operators of PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. |
| What is the fix? | Install a patched PHP release or your OS/vendor’s fixed package, then restart all PHP workers and web-server processes that load PHP. |
| Is a WAF or configuration workaround enough? | No. Temporary controls can reduce exposure, but the PHP project says updating is the complete fix. |
What is the PHP2Shell vulnerability?
PHP2Shell is a nickname for two bugs in core PHP, rather than a vulnerability in WordPress, Drupal, or another individual content-management system. The flaws involve PHP mishandling internal state after fatal memory-allocation failures. Depending on the code path, this can lead to memory corruption and remote code execution, or expose data from a PHP worker’s memory.
The PHP security advisory lists CVE-2026-109618 as remote code execution through out-of-memory corruption, and CVE-2026-109619 as remote code execution through stale global state. The official advisory assigns CVSS v4.0 9.2 to each. Researchers demonstrated unauthenticated RCE against WordPress, Drupal, and Joomla, but those applications were demonstration targets: the defect is in the PHP engine, so changing CMS does not remove the underlying exposure. (PHP security advisory, Wiz technical analysis)
Why this PHP RCE is serious
An attacker does not need a valid application account for the demonstrated attack paths. Successful code execution runs with the permissions and access available to the PHP service account, which may include application files, database credentials, API tokens, session secrets, or cloud credentials exposed to that process. The exact impact depends on the host’s permissions and network access.
The separate memory-disclosure behavior may expose secrets held in a worker’s memory. Treat a confirmed compromise as a potential credential-exposure incident: investigate access, rotate affected secrets from a clean system, and look for persistence or lateral movement.
Which PHP versions and deployments are affected?
The PHP project says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It notes that mod_php has the highest demonstrated risk because a request can reach the vulnerable path before application code runs. Check every PHP runtime that serves a public or internal web request, including runtimes inside containers and control-panel-managed stacks.
The upstream fixed releases are:
| PHP branch | Fixed upstream version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP 8.1 and older no longer receive updates from the PHP project. The PHP team published limited source backports for some older branches, and Linux distributions or long-term-support vendors may provide patched packages for their own supported releases. Confirm the fixed package status in your distribution or hosting vendor’s advisory; a vendor backport may be secure without changing the upstream version string. PHP 8.2 is scheduled to reach end of life on December 31, 2026, so plan a supported-version upgrade as well as applying the current fix. (PHP release advisory, Ubuntu package guidance)
How to check whether your server is patched
First identify all installed PHP versions and how each is run. A server can have one CLI binary, a different PHP-FPM pool per site, and additional versions managed by cPanel, Plesk, a container image, or a cloud platform.
Check the command-line PHP version
php -vThis reports the PHP CLI executable found in the current shell’s PATH. It may not match the interpreter serving your website. Use it as an inventory clue, not as final proof of web-runtime patch status.
Find PHP-FPM services and package versions
On systemd-based Linux, inspect active PHP-FPM services and installed PHP packages:
systemctl list-units --type=service --all | grep -Ei 'php.*fpm'For Debian or Ubuntu, list installed PHP packages and check your release’s security notice for the patched package revision:
dpkg-query -W -f='${Package} ${Version}\n' 'php*' 2>/dev/nullFor RPM-based distributions:
rpm -qa 'php*' | sortDo not compare distro package versions only to the upstream table above. Distributions often backport security patches while retaining their own version suffixes. Review the vendor advisory or ask your hosting provider to confirm the exact PHP package build and service runtime for each site.
Check containers and managed hosting
For containers, inspect the image digest and PHP package state inside the running container, then deploy a rebuilt image based on a patched upstream or vendor-supported image. Recreating a container from an old pinned image tag can reintroduce the vulnerable runtime.
For cPanel, Plesk, managed WordPress, or shared hosting, confirm each selected PHP version is updated. Ask the provider to confirm the PHP-FPM or equivalent web runtime has been patched and restarted. Updating the operating system’s default php binary may not update separately managed PHP builds.
How to fix PHP2Shell safely
1. Patch the PHP runtime
Upgrade to the applicable fixed upstream release in the table, or install the fixed package supplied by your operating-system or hosting vendor. For Ubuntu, Canonical recommends updating system packages using its released security packages; package names and versions vary by Ubuntu release. (Ubuntu PHP2Shell fix guidance)
On a Debian or Ubuntu server where normal security updates are managed through APT, the general update flow is:
sudo apt update
sudo apt upgradeFor other distributions, use their documented security-update process. Do not compile an unverified patch or install a package from an unknown repository on a production server.
2. Restart every process that can keep the old PHP code loaded
After installation, restart the relevant PHP-FPM service, Apache, or other PHP-serving process according to the local deployment. For example, an Ubuntu host using Apache with mod_php may require:
sudo systemctl restart apache2For PHP-FPM, restart the exact versioned service used by the site, such as php8.3-fpm where applicable. In containerized deployments, roll out newly built and patched containers. Follow your change-control and availability procedures, especially on multi-node services.
3. Verify the web-facing runtime
Check the PHP-FPM pool, Apache module, container, or hosting-panel runtime that actually serves requests. Confirm the vendor’s patched package revision, check service health, and verify that old workers have exited. Record the package build, runtime, service restart, and verification evidence in your change log.
4. Investigate suspicious activity
Patching closes the known vulnerability path; it does not prove a server was never accessed. Review web, reverse-proxy, PHP, system, and endpoint telemetry around the exposure window. The researchers advise watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpected PHP session-cookie behavior, and unexplained PHP worker churn. These signals can support triage, but absence of a signal is not proof of no exploitation. (Wiz detection discussion)
If you find evidence of unauthorized code execution, preserve relevant logs, isolate the affected host where practical, inspect for new files, scheduled tasks, processes, and outbound connections, and rotate secrets that the PHP service could access. Follow your incident-response plan before restoring service.
Temporary PHP2Shell mitigations
If a patch cannot be applied immediately, the PHP advisory describes configuration and request-size controls that reduce exposure to specific attack paths. These should be treated as short-lived risk reduction while a patch is scheduled, not as a fix or a way to declare a server safe.
The official advisory includes controls such as limiting request body and multipart complexity, reviewing PHP memory-limit configuration, and disabling session upload-progress handling for the relevant stale-state paths. Some controls have operational trade-offs and are incomplete; apply them only after checking application upload requirements and your vendor’s guidance. Restart workers when a PHP configuration change requires it. Do not rely on an application-level setting that takes effect only after PHP has already parsed the request.
Keep any WAF or CDN rule as an additional layer. Network filters cannot reliably replace the runtime patch across all request paths and deployment configurations. (PHP interim guidance, Cloudflare protection overview)
PHP2Shell response checklist for server administrators
- Inventory every PHP runtime exposed to web requests: PHP-FPM,
mod_php, CGI/FastCGI, containers, and managed hosting versions. - Prioritize internet-facing systems and deployments with Apache
mod_phpfor immediate review. - Install the fixed PHP release or the operating system/vendor’s confirmed security package.
- Restart or redeploy every PHP worker and web process that could retain old code in memory.
- Verify the web-facing runtime, not only the CLI version, and document package-level evidence.
- Review telemetry for suspicious requests or unexpected worker behavior during the exposure window.
- Rotate secrets if compromise is suspected or confirmed, then investigate persistence and lateral movement.
- Put unsupported PHP branches on a vendor-supported patched build or plan an upgrade.
Frequently Asked Questions
What is PHP2Shell?
PHP2Shell is the common name for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619. They can allow unauthenticated remote code execution in vulnerable PHP web deployments; researchers also demonstrated process-memory disclosure.
Is WordPress vulnerable to PHP2Shell?
WordPress sites can be affected when their PHP runtime is vulnerable. The flaw is in core PHP rather than WordPress itself, so updating WordPress alone does not remediate it. Update the PHP runtime used by the site and restart its workers.
What is the PHP2Shell patch version?
The upstream fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For Linux distributions and managed hosting, confirm the vendor’s fixed package revision because security backports may use different version strings.
Does php -v tell me whether my website is patched?
Not by itself. php -v reports the CLI binary in the current shell. A site may use a different PHP-FPM service, Apache module, container, control-panel build, or provider-managed runtime. Verify the interpreter and package that handle the site’s web requests.
Can a WAF or disabling PHP uploads fix PHP2Shell?
No temporary control is a complete replacement for the PHP security update. The official PHP advisory lists mitigations for specific paths, but says they only reduce exposure. Patch the runtime as soon as possible.
Is PHP2Shell being exploited in the wild?
Exploit details and demonstrations have been published, which makes rapid patching prudent. Public reporting can change quickly; consult current advisories and your own telemetry for the latest verified exploitation status rather than assuming that a quiet log means the server was not targeted.
Keep PHP patch status visible
PHP2Shell is a reminder that application security depends on the runtime beneath the application. Maintain an inventory of PHP versions by host and site, track vendor security notices, and include worker restarts and web-runtime verification in emergency patch procedures. For this issue, prioritize patching the PHP service that handles requests, then investigate any evidence that the vulnerable runtime was accessed before the update. Teams that need help coordinating server-side patching can review our server security and hardening support.