PHP2Shell for Developers: The Technical Summary With Every Link

As of 23 October 2026, PHP2Shell is two memory-safety bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed upstream in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026. Exploitation attempts are widely reported. No confirmed successful compromise is publicly documented, and neither CVE is in CISA's KEV catalog (version 2026.10.23). A related informational issue, CVE-2026-115560, affects even patched builds until PHP's next regular release.

The short version for developers: ship a fixed PHP build to every runtime that serves web requests, restart or replace every worker, rebuild every image that carries its own PHP, and verify the build actually serving traffic. Until the next regular release, keep session.upload_progress.enabled=0. No application, framework or CMS update fixes it.

This page is a reference. Each section is a summary that links to the detailed guide. It leaves out exploit mechanics on purpose.

The CVEs at a Glance

The CWEs on both advisories are CWE-416, 755, 824, 1325 and 1419. Wiz's blog maps its four bug names to the CVEs differently from PHP. Use PHP's mapping. Both advisories credit researchers from Calif, Wiz and OpenAI, plus a fourth reporter (tomash-areion). Calif reported first, on 11 August 2026. Primary sources: GHSA-w8hw, GHSA-6wmf and the php.net announcements. For the plain-English version for clients, send them to what PHP2Shell is. Exploitation reports conflict, and our exploitation status tracker follows them.

Versions: Fixed, EOL and Backported

PHP's advisories list only 8.2 to 8.5 as affected, but NVD's range for CVE-2026-109619 starts at 5.4.0, and several researchers say older branches are affected too. Assume every branch is. Release-by-release detail is in our fixed versions guide. Planning a branch jump? Read upgrading old PHP safely. One known regression to watch for: php-src issue 24488 reports a SimpleXML double free in 8.4.27 and 8.5.12. It is a stability bug, not a bypass, and was closed on 22 October. php.net has not said which release ships the fix.

Exposure by Server API

php.net puts "all PHP installations serving web requests" in scope. The advisories differ on how exposed each server API is:

OPcache appears in Wiz's research only as one exploit path. No advisory asks for an OPcache step beyond the restart; see PHP2Shell and OPcache.

Verify the Build That Serves Traffic

The command-line php binary can differ from the one PHP-FPM or Apache runs, and distributions backport fixes without changing the version string. Check through the web server, then prove the fix with one of these. The commands are examples; replace package names and versions with your own:

apt-get changelog php8.3-fpm | grep -E 'CVE-2026-(109618|109619)' (Debian or Ubuntu)
rpm -q --changelog php-fpm | grep -E 'CVE-2026-(109618|109619)' (RHEL family)
ps -C php-fpm -o pid,lstart (worker start times; adjust the process name to your system)

On official 8.2.35 to 8.5.12 builds, the new memory_hard_limit_percent directive exists. Run through the web server, ini_get('memory_hard_limit_percent') returns an empty string when the directive exists and false when it doesn't. PHP's manual says an unrecognized directive means "the PHP version in use is affected." That holds only for official upstream builds. The 8.1 source backport doesn't add it, and distro backports may not either. If you use a temporary phpinfo() page, delete it afterwards. Our tools help here: the free exposure check and the PHP version lookup. The full method for each platform is in how to check your PHP version.

Restart, Rebuild, Redeploy

Installed but not loaded is not patched. PHP says to "restart every worker." Our restart guide has the commands for each setup. For pipelines and platforms:

• Docker official images: the 8.5.12, 8.4.27, 8.3.36 and 8.2.35 tags were pushed on 21 October. The 8.1, 8.0 and 7.4 tags have not been rebuilt, so there is no fixed official image for 8.1 or older. The wordpress, drupal and joomla latest images were rebuilt on 22 October.
• Your images: rebuild with a fresh base pull. FrankenPHP's docs warn that Docker "can have a cache layer" and suggest the --no-cache option. docker compose pull alone doesn't start new containers; docker compose up recreates containers whose image changed.
• Kubernetes: with imagePullPolicy IfNotPresent, an image is pulled "only if it is not already present locally." Kubernetes advises against :latest in production. Use a new tag or digest, then roll the deployment (for example, kubectl rollout restart deployment/my-app).
• Laravel: Laravel Cloud patched in place. Forge needs "Update PHP" on each server. Vapor needs a redeploy (custom or Docker runtimes need a new deployment). Octane's FrankenPHP binary bundles its own PHP and must be reinstalled. See PHP2Shell and Laravel.
• Clouds: Google Cloud says "Container images you build yourself are your responsibility." App Engine flexible must be redeployed, and Cloud Run services without automatic base image updates must be rebuilt. Azure App Service doesn't patch custom containers. AWS Lightsail needs new instances from updated blueprints.

Interim Mitigations, Where They Actually Apply

PHP's line: "There are no complete mitigations, updating is the only safe choice." If you must hold for a few hours, the options are below. Our interim mitigations guide covers side effects, and the php.ini generator drafts the settings.

Settings must load before request parsing: php.ini, the FPM pool or server configuration. PHP is explicit: "Do not rely on ini_set() or FPM .user.ini." A WAF is a layer, not a fix.

What to Fix in Your Own Code and Config

The engine fix is the remedy. GHSA-6wmf also points at things in application code and configuration that widen exposure:

• Remove invalid or deprecated settings applied per request, such as php_value lines in .htaccess or PHP_VALUE from nginx, that emit warnings before request initialization. Hiding diagnostics with error_reporting, display_errors or @ "does not help."
• Fix attacker-reachable fatal errors and execution timeouts, "including failures in callbacks, upload or import processing and cleanup."
• For CVE-2026-115560, check whether your code switches session.serialize_handler to php with ini_set() before session_start(). PHP says only that pattern is affected. If you don't need upload progress, turn it off anyway.
• If the application never takes multipart uploads, GHSA-w8hw suggests blocking multipart requests "at the frontend before they reach PHP."

Framework and app specifics live in the app guides: Symfony, CodeIgniter and CakePHP, custom PHP apps, WordPress, Drupal, Joomla, WooCommerce, Magento, Moodle, Nextcloud and WHMCS. The Dutch NCSC keeps a community software inventory. Most "Vulnerable" rows there mean "runs on PHP," not "vendor confirmed." Headless stacks still need their PHP backend patched; see our headless security guide. Our guide to plugin and package supply chain security covers the dependencies you inherit.

Detection and Response

• Look back to at least 17 October 2026, the earliest attempt Amazon reported.
• Signals named by Wiz, Beazley, Datadog and Sophos include unusual multipart requests (including to endpoints that don't take uploads), requests containing PHP_SESSION_UPLOAD_PROGRESS, memory-exhaustion errors logged "in Unknown on line 0," worker segfaults and churn, oversized PHPSESSID cookies, web workers spawning shells, and new PHP files in web roots.
• Clean logs prove nothing. GHSA-6wmf says "absence of an error in logs is not proof of safety," and Bitdefender notes a successful exploit "can return HTTP 200."
• Preserve logs before rebuilding. If compromise is suspected, rotate the secrets the PHP process could read, such as database credentials, API keys and cloud credentials.
• Don't rely on IOC lists. The few IP addresses AWS published include shared anonymization infrastructure, and AWS says to investigate them rather than block them. Treat public proof-of-concept repositories as untrusted code.

The step-by-step check is in "was my site hacked?", and our incident response plan covers the first hour. Hosting-side questions are in PHP2Shell on shared hosting and what to ask your host. For everything else, see the PHP2Shell FAQ.

Conclusion

For developers, PHP2Shell has one remedy and many places to apply it. Get a fixed engine on every web-serving runtime, load it with a restart or redeploy, prove it with a changelog or build check, keep upload progress off until the next release, and clean up per-request config that widens exposure. If you need another pair of hands on a fleet of servers or images, our emergency PHP patching team works with in-house developers. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions