PHP2Shell RCE: Emergency PHP patches released and what to do

PHP warned administrators about two critical remote code execution flaws and scheduled emergency security updates after some information leaked, according to BleepingComputer. The PHP security team set a release time and urged admins to be prepared to install the updates as soon as they arrive. Researchers and vendors began sharing temporary defenses and observing early exploit attempts while the patch rollout proceeded.

What the reports say

According to BleepingComputer, the PHP security team announced it would publish the fixes at 14:00 UTC on the scheduled day and assigned a CVSS v4.0 score of 9.2 to each flaw. Security researchers at watchTowr told BleepingComputer that the flaws are remote code execution issues and shared two CVE identifiers that have circulated publicly. watchTowr and a now-deleted Hacker News post had said details leaked ahead of the planned disclosure.

The Hacker News reports that PHP published emergency updates that fix the flaws, and lists the fixed branches where the project shipped those updates. That report also says researchers at Wiz and OpenAI found and reported the vulnerabilities, and that the combined set of flaws has been referred to by some as PHP2Shell.

Who is at risk

The Hacker News notes that the vulnerabilities sit in the PHP runtime itself, which means any server that executes PHP to serve web requests can be exposed, even if the site application code is simple. The Hacker News singled out Apache mod_php as the highest-risk setup because one demonstrated exploit can trigger code execution before application code runs. PHP-FPM and other handlers can behave differently, and the Hacker News article explains that certain exploit paths affect PHP-FPM while others primarily affect mod_php.

The Hacker News also reports the researchers demonstrated the ability to read memory from PHP worker processes, which could expose secrets stored in memory such as tokens or keys, in addition to enabling code execution in other scenarios.

How to protect your site from PHP2Shell RCE

Apply the official PHP updates as the first and primary step. The Hacker News lists the emergency fixed releases that PHP published for the supported branches; updating the PHP runtime that serves web requests and then restarting web servers and any long-running PHP workers is the complete fix according to the advisory reported there. Remember that updating application code alone (for example WordPress or Laravel) does not change the PHP runtime on the server.

If you cannot update immediately, consider these temporary measures, drawn from the coverage of advisory guidance and vendor responses. Treat them as short-term mitigations, not replacements for the official patch:

• Install the official PHP updates for the runtime that serves web requests as soon as your environment allows, then restart Apache, PHP-FPM, and any long-running PHP processes, per The Hacker News.
• If you host behind a managed WAF, enable the vendor shields: BleepingComputer reports Cloudflare deployed WAF rules to block known exploitation methods and is updating those protections as new techniques appear.
• Follow suggested temporary server-side limits that researchers proposed, such as disabling PHP session upload progress and enforcing request-size limits, but only after testing because these changes can break form uploads and other functionality, according to BleepingComputer.
• Review which servers use mod_php, php-cgi, PHP-FPM, FrankenPHP, or LiteSpeed and prioritize updates on mod_php instances, since the highest-risk exploit path was shown against mod_php, as reported by The Hacker News.
• If you need a quick external check of exposure, start with a free external scan to see which web-facing hosts expose PHP, and plan patching order accordingly. Want to know how exposed your own site is? Start with a free external scan: /security.html

Temporary defenses vendors and researchers are using

BleepingComputer says Cloudflare has already pushed temporary WAF rule changes to block known exploitation patterns and that Cloudflare is observing early attacks while it adjusts protections. The same report notes researchers offered short-term workarounds, like disabling session.upload_progress and blocking multipart/form-data requests, but also cautioned these actions may disrupt normal site behavior and are not proven to fully stop exploitation.

PHP core developer commentary cited by BleepingComputer warned that there are no true mitigations that replace the official patches, and that installing the security updates is the only reliable solution.

Practical next steps for small sites and teams

• Inventory: Identify servers running PHP that serve web requests and rank them by exposure (public-facing first, internal second).
• Patch: Apply the official PHP runtime updates reported by The Hacker News for your branch as soon as vendor or package updates are available, then restart web services and workers.
• WAF and monitoring: If you use a managed WAF, confirm it has deployed protections for these PHP issues and monitor logs for unusual HTTP requests or exploitation indicators reported by your vendor.
• Backups and access: Ensure recent backups exist and confirm administrative credentials are protected with multi-factor authentication and least-privilege access.
• Test after changes: After applying mitigations or updates, test critical user flows like file uploads and form submissions to confirm no essential functionality was broken.

Treat the situation as urgent but focused: the fix is to update the PHP runtime and restart affected services, vendor WAFs can reduce immediate exposure, and temporary server tweaks can help in constrained cases but are not substitutes for the official patches. For many small sites, the practical path is inventory, update the runtime, restart services, and monitor for suspicious activity.