PHP2Shell Vulnerability: What It Is and How to Fix It

PHP2Shell Vulnerability: What It Is and How to Fix It

Last updated: 22 October 2026. This is a developing situation, and we will update this article as new information becomes available.

On 21 October 2026, the PHP project released emergency security updates for two critical vulnerabilities in the PHP engine. Known together as PHP2Shell, CVE-2026-109618 and CVE-2026-109619 can allow an attacker to execute code on a server without logging in, and can also expose data held in memory, such as passwords, API keys, and tokens. What makes PHP2Shell unusual is where the problem lives: not in a plugin or a framework, but in PHP itself. That means a well-written Laravel application, a carefully maintained WordPress site, and a custom PHP system can all be at risk if the server runs an unpatched PHP version. Exploitation attempts began even before the official disclosure, so every team running PHP should treat this as an emergency. Here is what you need to know and exactly what to do.

What Is PHP2Shell?

PHP2Shell is the collective name for two separate flaws in the PHP runtime. Both are rated 9.2 (Critical) on the CVSS v4 scale. An earlier score of 10.0 that circulated online before the official release was not PHP's rating.

• CVE-2026-109618 is a memory corruption flaw triggered when PHP runs out of memory while processing a request. During the cleanup that follows, PHP can treat partially prepared request data as if it were valid.
• CVE-2026-109619 is a use-after-free flaw. Data left over from one request can point to memory that has already been freed, and a later request handled by the same PHP worker can use it. PHP confirms that this flaw can also leak memory contents.

The vulnerable code has existed for more than a decade, with affected code traced back to PHP 5.4. The flaws were found and reported by Wiz Research, Calif, and OpenAI's Codex Security team.

Why PHP2Shell Is So Serious

Three factors make PHP2Shell more dangerous than a typical vulnerability. First, no authentication is required: an attacker only needs to send requests to a website. Second, the flaws sit in the engine, so secure application code does not protect you. In some configurations, the vulnerable path can even be reached before any application code runs. Third, the memory disclosure means that even an unsuccessful takeover attempt may leak sensitive information from the server.

The timing adds to the urgency. Amazon's threat intelligence team observed a first exploitation attempt on 17 October, four days before disclosure, and further attempts from multiple actors on 21 October. watchTowr and Cloudflare have also reported attacks, and Cloudflare observed attackers changing their payloads to bypass its firewall rules. CISA has issued an alert urging immediate patching. As of this update, no successful compromise has been publicly confirmed, but that can change quickly.

Who Is Affected?

According to the PHP project, every PHP installation that serves web requests is at risk. This includes all common ways of running PHP:

• Apache mod_php: rated the highest risk, because the demonstrated attack can succeed before application code runs.
• PHP-FPM: used with Nginx and most modern hosting, including typical Laravel deployments.
• php-cgi, FrankenPHP, and LiteSpeed.

Researchers have confirmed pre-authentication remote code execution against specific versions of WordPress, Drupal, Joomla, and Magento. Laravel has not been singled out, but because the flaws are in the PHP engine, Laravel applications are exposed to exactly the same degree as the PHP version they run on.

Fixed PHP Versions

The PHP project released fixes on 21 October 2026. Any earlier version in these branches is vulnerable:

• PHP 8.5: fixed in 8.5.12
• PHP 8.4: fixed in 8.4.27
• PHP 8.3: fixed in 8.3.36
• PHP 8.2: fixed in 8.2.35
• PHP 7.4, 8.0, and 8.1: no official release; the PHP project published limited source-code backports only
• PHP 7.3 and older: end of life, with no fix from the PHP project

Linux distributions and long-term support vendors received the patches in advance and often ship them under version numbers that look older. If you install PHP from your distribution, check the package changelog for the CVE identifiers rather than relying on the version number alone. Note also that PHP 8.2 reaches end of life on 31 December 2026, so this is a good moment to plan an upgrade.

How to Check If Your Server Is Affected

Start by building a complete list of every place PHP runs, including production, staging, internal tools, and forgotten legacy sites. Attackers scan the whole internet, so a small test server is as much of a target as your main application. Then check each one:

• Run php -v and, where PHP-FPM is used, php-fpm -v. The command-line and FPM versions are not always the same.
• For distribution packages, check the changelog of the installed PHP package for CVE-2026-109618 and CVE-2026-109619.
• For Docker and other containers, check the PHP version of each base image. Updating the image tag is not enough; images must be rebuilt and containers redeployed.
• For shared hosting, Plesk, cPanel, or managed platforms, check your provider's security notices and confirm which PHP versions have been patched.
• Remember that running composer update does not fix PHP2Shell. The fix is in the PHP runtime, not in your application's packages.

How to Fix PHP2Shell

The PHP project is clear that updating is the only complete fix. The general steps are:

• Update PHP to a fixed version, or install your distribution's patched package.
• Restart every PHP process: PHP-FPM pools, Apache, and any long-running workers. A server that is still running the old binary in memory is still vulnerable.
• Rebuild and redeploy all container images that include PHP.
• Verify the result by checking the running version again and confirming the patched package is active.
• Review memory_limit and post_max_size after patching. The fix introduces a hard memory limit that ends a process when it is reached, so unusually low limits may cause new errors in memory-heavy tasks.

If you run PHP 8.1 or older, the safest path is to upgrade to a supported branch. Applying unofficial source backports to an end-of-life version is possible, but it should be treated as a short-term measure.

Temporary Mitigations If You Cannot Patch Immediately

If an immediate update is not possible, the PHP project lists configuration changes that reduce exposure. They do not make a server safe and are no substitute for patching:

• For CVE-2026-109618, set memory_limit=-1 at the server or FPM pool level, in a way applications cannot override, and keep post_max_size as low as your application allows.
• For CVE-2026-109619, set session.upload_progress.enabled=0. On PHP 8.5, also set fatal_error_backtraces=0.
• Apply these settings in php.ini, the FPM pool, or the web server configuration. Changing them with ini_set() inside the application or in a .user.ini file is too late to help.
• Restart all PHP workers after making changes.
• Limit request sizes at the web server or reverse proxy, and block multipart requests before they reach PHP if your application does not need file uploads.
• Consider placing critical internet-facing PHP applications behind additional access controls, or taking them offline, until they are patched.

Web application firewall rules, such as those Cloudflare has deployed, help as a stopgap, but they only protect traffic routed through that service, and attackers are already adapting their payloads.

What PHP2Shell Means for Laravel Applications

Laravel itself does not need a code change to address PHP2Shell, but every Laravel application depends on the PHP version underneath it. For Laravel teams, the practical checklist is:

• Identify the PHP version on every server, queue worker, and container that runs your Laravel application, and patch all of them, not just the web servers.
• If you deploy through a managed platform, confirm with your provider that its PHP runtimes have been updated, and redeploy if required.
• Restart queue workers and long-running processes, such as Horizon or Octane, after patching so they load the new PHP binary.
• Because PHP2Shell can expose memory, consider rotating sensitive secrets if a server was internet-facing and unpatched: the APP_KEY, database passwords, and API keys for services such as Stripe, Xero, or QuickBooks. Rotating the APP_KEY requires care, since it affects encrypted data and sessions.

Signs Your Server May Have Been Targeted

Researchers have shared several patterns that may indicate exploitation attempts. None of them proves a compromise on its own, and a clean log does not prove a server is safe, but they are worth reviewing:

• Unusual multipart requests followed by memory-limit errors
• Repeated HTTP 500 responses without a clear cause
• Unusually large PHPSESSID cookies
• Unexplained PHP worker crashes or restarts
• Unexpected processes, files, or outbound network connections from the web server

If you find signs of compromise, isolate the affected server, preserve the logs for investigation, rotate credentials, and rebuild from a known clean state rather than trying to clean a possibly compromised system.

PHP2Shell Timeline

• 17 October 2026: Amazon observes a first exploitation attempt against its honeypot network.
• 20 October 2026: CVE identifiers leak publicly. PHP announces an emergency release, moved forward by one day.
• 21 October 2026: PHP releases fixed versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 at 14:00 UTC. watchTowr reports exploitation attempts against both CVEs shortly afterwards, and CISA urges immediate patching.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619. They can allow an unauthenticated attacker to execute code on a web server and to read data from server memory. Both are rated 9.2 on the CVSS v4 scale.

Is my website affected by PHP2Shell?

If your website runs on PHP and the server has not been updated to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a patched distribution package, it should be considered vulnerable. This applies to PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.

Is Laravel affected by PHP2Shell?

Laravel applications are affected through the PHP version they run on. The flaw is in PHP itself, so updating Laravel or Composer packages does not fix it. You need to update PHP on every server and container that runs your application.

Is WordPress affected by PHP2Shell?

Yes. Researchers have confirmed unauthenticated remote code execution against specific versions of WordPress, as well as Drupal, Joomla, and Magento. The fix is to update the PHP version on the server; updating WordPress alone is not sufficient.

Is PHP2Shell being exploited?

Exploitation attempts have been observed since 17 October 2026 and increased after the patches were released on 21 October. As of 22 October, no successful compromise had been publicly confirmed, but security firms describe the attempts as widespread.

I am using PHP 7.4 or 8.1. What should I do?

There is no official fixed release for these versions. The PHP project published limited source-code backports for PHP 7.4, 8.0, and 8.1, and some distributions and long-term support vendors provide patched packages. The safest solution is to upgrade to a supported PHP version, with temporary mitigations in place until the upgrade is complete.

Does Cloudflare or a WAF protect me from PHP2Shell?

A web application firewall can block known attack patterns and is a useful extra layer, but it is not a complete fix. It only protects traffic that passes through it, and attackers have already modified their payloads to bypass some rules. Patching PHP remains essential.

Do I need to change passwords and API keys after patching?

If a server was exposed to the internet and unpatched while attacks were active, rotating sensitive credentials is a sensible precaution, because PHP2Shell can expose data held in memory. Prioritize database passwords, application keys, and API keys for payment and accounting integrations.

How long does it take to patch PHP2Shell?

For a single server using distribution packages, updating PHP and restarting services usually takes minutes. Larger environments with many servers, containers, and legacy PHP versions need careful inventory and testing, which is why it is important to start immediately.

Conclusion

PHP2Shell is one of the most serious PHP vulnerabilities in years: it affects the engine itself, requires no authentication, can expose secrets from memory, and is already being targeted. The response is straightforward but urgent. Find every server and container that runs PHP, update to 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a patched distribution package, restart all PHP processes, and apply temporary mitigations wherever patching is delayed. If you run Laravel or other PHP applications and need help checking your servers, applying the patch safely, or upgrading from an end-of-life PHP version, our team can help you secure your systems quickly.