PHP2Shell: validating the execution path

A convincing exploit result can still support the wrong conclusion. The investigation asked whether public exploit claims reproduced on real configurations, and whether the observed execution actually used the claimed vulnerability.

I designed the prompts driving multi-day PHP ecosystem research and ran a six-plus-hour agent analysis. I directed infrastructure deployment, live GDB inspection, script generation, code analysis, fuzzing, testing, and evidence collection. I caught an incorrect agent-generated exploit attribution and separately reproduced RCE on PHP 7.4.

The critical decision was to inspect the execution path rather than accept a shell as CVE confirmation. Lab-only weaknesses must remain distinct from default component behavior.

Build, process manager, extensions, worker reuse, and runtime configuration affect reproduction. Recording those prerequisites matters as much as retaining a successful payload.

The co-authored Tenable article documents the false attribution, PHP 7.4.33 RCE, and build-specific exploitation constraints. This contribution account combines the publication with my description of my role; team findings retain shared attribution.

This portfolio does not rerun exploitation or publish additional payloads. It uses the already published findings to explain research verification.

The investigation rejected an incorrect CVE attribution, reproduced a target-specific RCE path, and produced a co-authored public account of the conditions and limitations.

Published through Tenable, co-authored with Joshua Martinelle. ACS is my separate business; the article is not an ACS customer engagement or an employer endorsement.

Related out-of-memory findings reported to PHP remain disclosure-pending and are excluded from the technical detail here.