Sophos, Palo Alto Networks retract early claims of PHP2Shell exploitation - but attacks are starting Sophos and Palo Alto Networks Unit 42 both retracted claims that the PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619 had been exploited, five days after the critical PHP bugs were disclosed, but researchers reported the first credible in-the-wild remote code execution on October 24. VulnCheck's Caitlin Condon said her team got code execution working on PHP 8.2 and 8.3, and Perplexity detection and response lead Adel Karimi said his honeypots showed RCE "with usable memory disclosure" against an Apache mod_php box running PHP 8.4.26, delivering an 800 KiB decoded cookie dump. Security researcher Marcus Hutchins called Karimi's write-up "by far the highest quality confirmation of in-the-wild php2shell exploitation I've seen so far," while noting most posted proofs of concept are "completely non-functional AI slop. The exploitation of PHP servers/applications OpenAI and the NSA warned about has been slow to start – five days after a pair of critical PHP bugs were disclosed. Indeed both Sophos and Palo Alto Networks have actively retracted claims of exploitation. With frontier models making it far easier to spin up exploits from patch diffs, this suggests that true pre-auth RCE exploits are proving far harder to identify and weaponise than many suspected – even as exploitation of other bugs continues. Sophos, on October 22, reported “exploitation of PHP2Shell in customer environments” but the next day said https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619?ref=thestack.technology it was “correcting that assessment.” Its telemetry showed “scanning and a small number of failed exploitation attempts.. there is no evidence of a successful compromise due to these vulnerabilities.” Palo Alto Networks’ Unit 42 said https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/?ref=thestack.technology on October 24 it was “unable to confirm that initial access is associated with the specific PHP2Shell CVEs” after spotting post-compromise activity “against a European government agency executed in the context of a vulnerable PHP application” — and also retracted its claim of PHP2Shell exploitation. VulnCheck’s Caitlin Condon however said on October 24 that her team had “ got code execution working in on PHP 8.2 and 8.3 today, which rounds out our testing across supported version streams. There won’t be a universal exploit, but exploitability for RCE with ASLR is definitely possible across the affected version range,” she added. And on Saturday October 24 Adel Karimi, who leads detection and response efforts at Perplexity, said his honeypots showed evidence http://github.com/0x4D31/honeypot-data/tree/main/reports/php2shell/2026-10-24-rce-evidence?ref=thestack.technology of RCE “with usable memory disclosure” against an Apache mod php box running PHP 8.4.26. “The response delivered an 800 KiB decoded cookie dump, and a function address derived from that dump using the public exploit's offsets appears in the subsequent execution payload," Karimi https://x.com/0x4D31/status/2114027420084752479?ref=thestack.technology said on X – later adding that he had “confirmed more from the same IP, plus a new IP with a different payload that might be a different actor… and this is showing up in multiple regions now.” Attacks appear to be meaningfully starting. Security researcher Marcus Hutchins described Karimi’s write-up as “by far the highest quality confirmation of in-the-wild php2shell exploitation I've seen so far…” He had earlier commented that “The RCEs requires the attacker to obtain memory addresses which are typically protected by ASLR. - I suspect the original author lcfr hax likely has a reliable exploit which leads to stable code execution. “Most of the PoCs being posted are completely non-functional AI slop.” Major Linux distributions like Ubuntu have pushed patches https://ubuntu.com/blog/php2shell-vulnerability-fixes-available?ref=thestack.technology but the potential blast radius if properly functioning pre-auth RCE exploits start circulating more widely is large. Getting attacks up and running thus-far seems to have been far more complex than many anticipated and certainly buys more patching time for the many many organisations that are still working out what’s exposed or what to prioritise.