PHP2Shell: Are You Affected? Here's How to Check and Fix It

1. Is my PHP version affected?

These are the first versions that fix both vulnerabilities:

Check your installed version:

php -v

There's a catch: that command checks your command-line PHP installation, which isn't necessarily the version serving your website.

If you use PHP-FPM, Docker, Plesk, or managed hosting, check the actual web-serving runtime. For containers, inspect the running image. For managed hosting, check your control panel or ask your provider to confirm the PHP2Shell patch status, including security backports.

You can find the official fixes in the PHP release archive.

2. What applications are affected?

The issue isn't limited to one CMS or framework.

Potentially affected: WordPress, WooCommerce, Laravel, Symfony, Drupal, Joomla, custom PHP APIs, hosting control panels, and products that embed PHP in a management interface.

The server configuration changes how an exploit might work.

Apache with mod_php has the most serious demonstrated attack path, including code execution before application code runs. PHP-FPM, php-cgi, LiteSpeed, and FrankenPHP are also in scope, though exploitation conditions differ.

If you run PHP inside a third-party product, the vendor may need to supply the fix.

The Netherlands' National Cyber Security Centre maintains a useful PHP2Shell software and vendor advisory tracker. It covers potentially affected products beyond ordinary web applications and is worth checking as vendors publish updates.

3. What should I do right now?

Patch the runtime. Upgrade to a fixed release, rebuild affected containers where necessary, and restart PHP workers or web servers. Verify the patched version is actually serving requests.

If you can't patch immediately, consult PHP's temporary mitigation guidance. Disabling session.upload_progress.enabled, tightening request limits, and using WAF protections can reduce particular attack paths. None is a complete substitute for patching. CISA recommends taking vulnerable services offline when they cannot be secured.

Check for earlier attempts. Amazon observed PHP2Shell exploitation attempts as early as October 17, four days before disclosure. Review logs from at least that date for:

• Unusual multipart POST requests correlated with PHP errors
• Unexpected PHP-FPM or Apache worker crashes
• PHP workers launching shells or making unexpected outbound connections

Don't rely on a single suspicious IP or request string. Fastly found that some publicly circulated detections were actually matching other attacks.

For more detailed investigation, see Fastly's PHP2Shell traffic analysis and Amazon's early exploitation report.

4. What about WAF protection?

If you're using a managed WAF, check its PHP2Shell-specific protections while you roll out patches.

• AWS: PHP2Shell WAF mitigation guide — covers managed rules, version pinning, and configuration.
• Cloudflare: PHP2Shell WAF protections — explains the managed detections and why response-aware inspection matters.

Neither replaces an updated PHP runtime.

5. Why does PHP2Shell matter beyond PHP?

This is where the story gets interesting.

PHP developers had identified the underlying out-of-memory problem in 2024, but couldn't demonstrate a practical exploit. In 2026, researchers working with frontier AI models helped turn that problem into working remote code execution.

The PHP Foundation's account explains what happened, including why the issue was difficult to fix.

Meanwhile, many public PHP2Shell proof-of-concept scripts turned out to demonstrate crashes rather than reliable code execution. CrowdStrike documented that distinction in its October 23 analysis.

The AI contribution to vulnerability research is documented. The extent of AI involvement in real-world attack traffic is not.

That's an important difference.

At Murk, we're working on the same problem of separating a possible vulnerability from one you can actually reproduce and verify.

For PHP2Shell, however, the response is straightforward: identify your PHP runtimes, patch them, and investigate suspicious activity if they were exposed.

You don't need to wait for a working public exploit to take action.

Resources worth bookmarking