#PHP2Shell

• Vulnerability: Two critical flaws in the PHP runtime, both rated CVSS v4.0 9.2 in the php.net notice. The PHP2Shell name and the link to CVE-2026-109618 and CVE-2026-109619 come from researchers, not from PHP.
• Status: Details leaked online before the official release, as SecurityWeek reports. PHP has not published the affected versions or the fixed versions yet.
• Suspected path: Researchers suspect a memory-safety bug in session upload-progress handling during multipart/form-data parsing (DeXpose). PHP has not confirmed the root cause.
• Exploitation: watchTowr says it reproduced CVE-2026-109618 (SecurityWeek), and on 21 October its FAQ reported no exploitation in the wild. Other reports of active exploitation are not confirmed yet.
• What I track: I collect the IOCs that researchers post on X with the #PHP2Shell hashtag. New posts reach the feed within 15 minutes.
• References: php.net notice · Tenable CVE-2026-109619 · SecurityWeek · Syhunt mitigation kit.

1. Inventory: List every PHP runtime: web SAPI, FPM pools, CLI, containers and panel-managed PHP (DeXpose). The output of php -v shows only the CLI binary, and an inventory does not show if a host is vulnerable.
2. Prepare your package source: If you use the Remi repository, move to distro packages or a source build now. The PHP Foundation says Remi will not have updates on 21 October.
3. Patch: Install the fixed PHP release or your distro backport in every runtime when PHP publishes it at 2026-10-21 14:00 UTC (php.net). Confirm the CVE ID in the official advisory or the package changelog, not a version number from a blog.
4. Rebuild containers: After the fix ships, pull a fresh base image, rebuild, and replace the running containers, because a restart keeps the old PHP (Teramont). On Plesk and cPanel, update the panel-managed PHP runtimes too.
5. Mitigate until you patch: If you do not need upload progress, set session.upload_progress.enabled to Off in php.ini or the FPM pool, and check the value from the web SAPI (Teramont). This is not a fix, and one researcher says it stops at most one of the two bugs.
6. Block multipart at the edge: If a site does not need multipart forms, reject multipart/form-data POST requests before they reach PHP (Syhunt). This breaks file uploads and multipart APIs, and the Syhunt example covers only Apache and POST.
7. Hunt: Look for unusual multipart requests on JSON-only endpoints, PHP worker crashes and processes that PHP service accounts start (DeXpose). These are leads, not PHP2Shell signatures, and a quiet log does not prove that you are safe.
8. Treat PoCs as malware: No public PHP2Shell exploit is independently verified, and abgeo.dev warns that fake exploits target security staff (abgeo.dev). Review any PoC code first, and run it only in an isolated lab.
9. Share IOCs: If you see PHP2Shell exploitation, post the IOCs (IPs, URLs, domains, hashes) on X with the #PHP2Shell hashtag. I add them to this page and to the free CC0 feed for all defenders.

Advice changes as vendors publish. Check the linked sources before you act.

No IOCs tagged #PHP2Shell in the past 30 days. Year aggregate: 0. For longer-window data, download the full annual feed api.tweetfeed.live/v1/year (all tags) and filter for #PHP2Shell client-side.

Tags that frequently co-occur with #PHP2Shell.

• #malware
• #C2

See all tags on the Dashboard or browse the full IOC feed.