PHP2Shell RCE

What Is PHP2Shell RCE?

A runtime flaw turns one unauthenticated web request into command execution on your server, and mass exploitation starts before the patch exists. You will see how the PHP2Shell flaws reach a shell on an unpatched Apache host, read the database password and plant a web shell, then run the response: update the runtime, restart it so the fixed build is actually serving, prove the exploit now fails, and clean up what the attacker already reached. You walk away able to triage and contain a public-facing RCE under live exploitation.

What You'll Learn in PHP2Shell RCE

• Explain how an unauthenticated runtime flaw like PHP2Shell reaches remote code execution without any login or vulnerable application feature
• Recognise why Apache with mod_php is the highest-risk deployment for a pre-authentication request-handling flaw
• Carry out the complete remediation: update the runtime to a fixed build and restart the service so the old build stops serving
• Distinguish patching from containment by cleaning up a planted web shell and rotating a credential the attacker already read
• Prioritise response to a public-facing RCE under active, widespread exploitation, including inventorying every copy of the affected runtime

PHP2Shell RCE — Training Steps

1. A server that answers

   On 21 October 2026 the PHP project shipped emergency fixes for two flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell. Together the two CVEs give remote code execution on a web server with no login at all. Within hours, honeypots recorded working exploitation and Cloudflare logged millions of attempts. Bob is not after any one company. He runs a mass scan for servers still on a vulnerable PHP build and works through whatever answers. Today one of them is Quillhaven's storefront.

2. Fingerprint the runtime

   Before firing anything, Bob checks what the server runs. A plain request to the storefront comes back with headers that name the web server and the exact PHP build behind it.

3. How PHP2Shell works

   Bob does not need an account, an upload form, or a vulnerable plugin. The flaw lives in how the PHP runtime sets up and tears down the data for each request. A single carefully malformed request can leave the runtime reusing memory from a half-finished request, and that is enough to steer execution. He opens his notes on the request shape. The working payload itself is withheld here; what matters is the structure and why it reaches code execution.

4. Why it reaches code execution

   The request targets any PHP endpoint on the site. It does not exploit the storefront's code at all. It exploits the runtime underneath every page.

5. Fire the request

   Bob sends the crafted request to a storefront page and gets back the output of a command he chose. The server ran it as the web user, with no authentication anywhere in the exchange.

6. What he takes

   Code execution is only the opening. Bob reuses the same request to read the storefront's database credentials, count the customer table ready to exfiltrate, and drop a small web shell at an innocuous path so he keeps access even after a restart. One unpatched flaw becomes the whole blast radius: a production password, a customer database, and a standing back door.

7. Knowledge check

8. The alert lands

   Quillhaven's edge provider flagged a surge of PHP2Shell probes, and one of them reached the storefront. The on-call lead pulls Alice in.

9. Open the runtime console

   The runtime console shows the live PHP build and flags anything on disk that it did not install.

10. Vulnerable, and already reached

    The console confirms both halves of the alert: the live build is vulnerable, and a file the platform never installed is sitting in the media cache.