PHP2Shell: Targeted Before the Patch

Two critical vulnerabilities in the PHP engine, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), allow unauthenticated remote code execution on servers running most PHP versions released in the last decade. PHP powers a large share of the web, including WordPress, Drupal, Joomla and Magento sites. Here is what happened, what Fenestra's own sensors recorded, and what organisations should do now.

What We Know

• The flaws are in PHP itself. They sit in how PHP handles multipart form uploads and session upload progress, before any application code runs. PHP's advisories cover its supported branches: every release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is affected, and those are the fixed versions. Older, end-of-life branches (8.1 and earlier, back to 5.4 according to Wiz) are also believed to be affected but won't receive an official fix.
• Details leaked before the fix. Technical details circulated on 20 October, ahead of PHP's scheduled release on 21 October.
• Attacks started before the patch. Amazon reported an attempt on 17 October, and Cloudflare saw thousands of attempts in the ten hours before the announcement, rising to millions within a day.
• Sites went offline. Government and public bodies in the UK, the Netherlands, France, Denmark and Finland took websites offline as a precaution, and the UK's National Cyber Security Centre advised doing the same where a fix can't be applied immediately.

Timeline (UK Time)

What Fenestra's Sensors Saw

Fenestra's sensor network recorded a PHP2Shell probe on the morning of 21 October, hours before PHP released the fix. The request was built to trigger the PHP2Shell flaw and came from a self-identified PHP2Shell scanning tool. Tools like this are also used by researchers measuring exposure, so we can't tell whether this was a researcher or a criminal actor. Either way, it shows PHP2Shell trigger attempts were hitting the internet before the fix. Our sensors can't tell whether this request would have worked against a vulnerable server. A second, lighter request that appears to check for the memory-disclosure flaw followed later that day from different infrastructure.

Indicators of Compromise

Both sources are scanning infrastructure that is likely to change, so treat them as context for log reviews rather than blocklist entries.

Trigger request. Preceded by GET /index.php and later followed by GET / with a browser User-Agent. Request structure, with the binary content summarised:

POST /index.php HTTP/1.1
User-Agent: php2shell-scan/109618
Cookie: PHPSESSID=a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6   (fixed value, appears hard-coded in the tool)
Content-Type: multipart/form-data; boundary=<random>
Content-Length: <~63 KB>

Content-Disposition: form-data; name="PHPSESSID"
  -> session ID matching the cookie
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"
  -> "x"
Content-Disposition: form-data; name="f"; filename="a"
  -> ~10 KB of "A" filler
Content-Disposition: form-data; name="t[]"   (x5)
  -> ~1 KB each, null-padded binary

Apparent memory-disclosure check.

POST / HTTP/1.1
User-Agent: Mozilla/5.0
Cookie: PHPSESSID=<16 hex characters>
Content-Type: multipart/form-data; boundary=<long random hex string>
Content-Length: <~400 bytes>

Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"
  -> "X" + the session ID
Content-Disposition: form-data; name="f"; filename="x.txt"
  -> a single null byte

What to Look For

• A User-Agent containing php2shell.
• Multipart POST requests with a PHP_SESSION_UPLOAD_PROGRESS field, sent to sites that don't use upload progress.
• Large or malformed multipart requests followed by memory-limit errors, HTTP 500 responses or PHP worker restarts.
• Oversized or malformed PHPSESSID cookies in responses.

What to Do Now

• Update PHP to a fixed release, including packages from your hosting provider or vendor. On PHP 8.1 or older there is no official fix: move to a supported branch, or confirm your vendor has backported the patch. Where neither is possible, take the service offline. Apache mod_php is the setup shown to be exploitable so far, but other setups may also be at risk.
• If a server was unpatched and internet-facing between 20 and 22 October, assume it was probed. Review logs for the indicators above and rotate secrets the PHP process could read.
• Check your suppliers. Much of the exposure sits in sites run for you by hosts, agencies and SaaS providers. Ask them to confirm they have patched.
• Don't run untested exploit code. Several PHP2Shell exploits published on GitHub have been reported as backdoored.

What We Don't Know Yet

• How many servers have been compromised. Attempt counts don't show successful intrusions.
• Whether the latest release fully fixes the issue. Claims that PHP 8.5.12 is still vulnerable are unconfirmed.
• Whether a reliable exploit is in criminal hands. Researchers report that most public exploits don't work and that the one reported to work needs a non-default setting. They still expect heavy exploitation in the coming weeks.

What to Watch

• Either CVE being added to CISA's Known Exploited Vulnerabilities catalogue.
• A reliable exploit that needs no special configuration, or one offered for sale on criminal forums.
• Breach claims that cite PHP2Shell as the way in.
• Web shells or cryptominers appearing on PHP servers, and any follow-up PHP releases.

Get in touch if you'd like help understanding your exposure to PHP2Shell, including in the sites and services your suppliers run for you.