PHP2Shell Vulnerability Gets a Public PoC Exploit for Security Testing

A public proof-of-concept repository shares verification tools and a lab setup to test two critical PHP vulnerabilities known as php2shell. The flaws, tracked by researchers as CVE-2026-109618 and CVE-2026-109619, are reported to affect PHP’s session.upload_progress feature and could lead to remote code execution under certain conditions.

The release adds technical detail to a fast-moving security issue. PHP’s security team announced that an emergency release would address two critical vulnerabilities, each rated 9.2 under CVSS v4.0, and urged users to prepare to upgrade.

Its notice scheduled the release for October 21 at 14:00 UTC. At the time of writing, that release time has not yet passed, so PHP’s official notice has not confirmed the technical details, affected versions or fixed builds described in the research repository.

The repository says the vulnerabilities affect PHP versions 5.4.0 through 8.5.11. It lists PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as planned fixed versions, but administrators should verify these against the PHP team’s release advisory before updating. The PHP project’s advance notice confirms the severity and planned release, but not those version details.

PHP2Shell Vulnerability PoC Exploit

The researcher’s write-up describes several paths to code execution, rather than one universal exploit that works against every PHP website. One chain combines session-file injection with a local file inclusion flaw in an application.

According to the repository, this path depends on upload progress being enabled and an application flaw that allows a local file to be included. A local file inclusion bug occurs when an application can be made to load a file from its server in an unintended way.

The repository says PHP’s upload-progress handler stores a supplied filename in session data without validating it. It also reports that a session identifier sent in a POST body can bypass the session.use_only_cookies setting, which is meant to restrict how session IDs are accepted.

These claims describe how a weakness in PHP’s session handling could combine with a separate application bug. They should not be taken to mean that every PHP site is immediately exploitable through this route.

A second reported issue involves a use-after-free, a memory error that can occur when software continues to use data after it has been released. The researcher says that re-entry into a var_destroy destructor can trigger this condition and reports confirming it with AddressSanitizer, a tool used to find memory errors.

The repository also describes a PHP-FPM serializer state that may persist across requests, and a handler mismatch that may cause a destructor to run after deserialization fails. The researchers say some of these paths need additional conditions, such as an application gadget or access to a local file.

These technical claims remain those of the independent research project until they can be compared with PHP’s full advisory and patches. Security teams should avoid treating every listed path as independently confirmed for all versions or configurations. The project’s verification repository provides the research overview and lab files. Its stated purpose is controlled testing, not use against systems without permission.

PHP runs a wide range of websites and applications, so a flaw in its core session handling could affect many types of deployments. The risk can be greater when an application already has a file inclusion weakness or unsafe deserialization behavior.

As previous PHP security coverage has shown, memory errors in PHP components can have a serious impact, though the technical causes differ. This report also covers another example of application-level risk on ScriptCase vulnerabilities.

The reported score of 9.2 signals a critical issue, but it does not tell administrators whether a particular server is exposed. That depends on the PHP version, configuration, application behavior, and whether the necessary conditions for a specific chain exist. The public repository includes a PHP-FPM and Nginx lab for testing. Organizations should use such environments only for authorized validation and should not run proof-of-concept code against production systems.

Administrators should inventory PHP installations across web servers, containers and managed hosting environments, then check the official PHP security release for confirmed affected and fixed versions. Once a suitable update is available, apply it promptly and restart PHP-FPM or the relevant web service so the new binaries take effect.

Systems running end-of-life PHP branches require special attention because they may not receive official fixes. The repository identifies PHP 5.x, 7.x, 8.0 and 8.1 as unsupported, but teams should confirm support status with the PHP project.

The researcher lists disabling session.upload_progress and setting session.use_only_cookies to On as temporary safeguards. These settings may reduce exposure to some reported paths, but the repository warns that they do not address every attack chain.

They are not a substitute for a security update. Review applications for local file inclusion and unsafe deserialization issues, and check server logs for unusual requests involving PHP session handling while the official advisory is being reviewed.

For now, the public proof-of-concept is best treated as a signal to prepare and validate safely. The key next step is to compare the research claims with PHP’s official release details, then patch affected systems as soon as the project publishes confirmed fixed versions.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.