claude-news
newsThe Register·23 Oct 2026·Jessica Lyons

PHP2Shell exploit bypasses protections designed to stop remote code execution

New PHP2Shell exploit defeats ASLR on x86-64 servers.

Extract

Researchers have developed a new exploit that shows how even Address Space Layout Randomization (ASLR) on an x86-64 server cannot stop the PHP2Shell vulnerability. VulnCheck, which made it available to only the company’s Initial Access Intelligence customers, also warned that threat actors are using AI to find even more ways to attack. The team told us that it’s a “significant advance” because up until now, ASLR has been a major barrier to exploiting PHP2Shell on real-world servers. They don't expect that to hold, though. “Adversaries are clearly spending time (and tokens) on this bug,” Spencer McIntyre, director of exploit development at VulnCheck, told The Register . The PHP2Shell mess grew even bigger on Thursday amid reports of attackers abusing the security flaws days before they were disclosed and UK government websites proactively going dark. Vulncheck's exploit targets CVE-2026-109618 , a critical, out-of-memory corruption bug that leads to remote code execution (RCE) in PHP, and part of the PHP2Shell pair alongside CVE-2026-109619 . The PHP Foundation officially disclosed and issued patches for both on Wednesday. Overnight, VulnCheck researchers developed what they believe is the first known exploit to achieve remote code execution on ASLR-enabled x86-64 systems with PHP's recommended production configuration. ASLR is a built-in defense against memory-corruption bugs – like PHP2Shell – that randomly arranges memory locations of a program's key data areas. By scrambling these components live, in memory every time a program runs, ASLR prevents an attacker trying to achieve RCE from correctly guessing the target memory address – and thus prevents them from executing malicious code. While VulnCheck has seen “hundreds” of PHP2Shell proof-of-concept repositories on GitHub, “very few contain legitimate, working exploits,” McIntyre told us, adding that this is largely due to ASLR. “There's a significant difference between demonstrating a vulnerability and developing an exploit that can overcome the security protections found in real-world environments,” McIntyre said. “One of the biggest obstacles has been ASLR, a protection designed to make memory corruption vulnerabilities much harder to exploit.” The threat hunters’ new technique, we’re told, bypasses ASLR. It uses a confirmed memory leak chained into RCE on PHP 8.4.26, and they claim it works on x86-64 platforms even with ASLR enabled and PHP’s recommended display_errors=off production configuration. …

Explained

What happened

PHP2Shell is a pair of critical PHP bugs (CVE-2026-109618 and CVE-2026-109619) patched by the PHP Foundation on Wednesday. VulnCheck built what it believes is the first exploit that gets remote code execution on x86-64 with ASLR on and PHP's recommended production config (display_errors=off), tested on PHP 8.4.26:

  1. Use a confirmed memory leak to learn real addresses in the process.
  2. Use those addresses to defeat ASLR.
  3. Chain into the memory-corruption bug to run attacker code.

Attackers were reportedly abusing the bugs days before disclosure, and some UK government sites went offline as a precaution. Of the "hundreds" of PoC repos on GitHub, very few actually work, mostly because of ASLR. The exploit is limited to VulnCheck customers, and the ARM64 variant does not yet reach RCE.

Why it works

ASLR randomizes where code and data live in memory, so a memory-corruption exploit can't guess the address to jump to. It is a probabilistic defense: it holds only as long as addresses stay secret. Any info leak (a bug that prints or returns a pointer) removes the randomness, and the corruption bug becomes exploitable again. That is why "leak plus corruption" is the standard chain.

The bigger pattern

Mitigations like ASLR, stack canaries and NX raise the cost of an exploit. They do not fix the bug. With attackers now spending "time and tokens" on AI-assisted exploit development, the gap between "a PoC crashes it" and "a reliable RCE exists" is shrinking fast. As VulnCheck puts it: difficulty of exploitation is not protection.

What it means in practice

  • Patch first, reason later. Inventory anything running PHP (WordPress, Laravel, internal admin tools, vendor appliances) and upgrade past the fixed versions.
  • Don't treat "hard to exploit" CVEs as low priority in your own triage. For internet-facing services, a critical RCE should be patched within days.
  • Defense in depth still helps: run app servers as unprivileged users, restrict outbound network access, so an RCE can't easily pull a second stage or join a botnet.