The Swarm developed a working exploit for php2shell (CVE-2026-109618 and CVE-2026-109619). It achieved unauthenticated remote code execution with address space layout randomization (ASLR) enabled and PHP error display disabled, in our tested AArch64 PHP 8.5.11 environment running Apache with mod_php.
The Swarm developed a working exploit for php2shell that achieved unauthenticated remote code execution as the web-server account. It worked with ASLR enabled and PHP error display disabled. That result comes from our tested AArch64 PHP 8.5.11 environment running Apache with mod_php.
Those two conditions are the important part. They are practical obstacles. Some publicly shared approaches we reviewed still relied on favorable conditions to get past them.
The exploit needed a sequence of HTTP requests, not a single request. In two fresh runs, it ran a benign command and wrote an exact test marker. We confirmed both through the target’s response and a separate marker check.
PHP’s advisories already describe these flaws as unauthenticated remote code execution (CVE-2026-109618: github.com/php/php-src/security/advisories, CVE-2026-109619: github.com/php/php-src/security/advisories). Our contribution is an end-to-end lab result documented by CovertSwarm.
Some public approaches we reviewed relied on memory addresses already known for a particular build. Our research addressed how to obtain the address information the exploit needs while ASLR stayed enabled. It also moved beyond the initial demo’s reliance on visible PHP error messages.
To be plain about scope: this is exploit research against vulnerabilities PHP had already disclosed. We are not claiming we found the original PHP flaws. We are not claiming the exploit works on every PHP deployment.
The ASLR-enabled, error-display-disabled result applies to the AArch64 Apache and mod_php environment described above.
We also ran the exploit in one local WordPress lab on matching AArch64 PHP 8.5.11 with Apache and mod_php. It produced execution evidence, the exact marker and a normal WordPress response. Not every route we tested in that lab produced the result. One WordPress lab does not mean every WordPress site is exposed.
Whether the exploit works depends on the PHP build and deployment. Server software, binary builds, frontend limits, request handling and worker behavior can change the outcome.
On patched releases, the evidence is narrow. Equivalent saved requests produced no execution evidence or marker in our PHP 8.5.12 controls. We did not run controls on 8.4.27, 8.3.36 or 8.2.35. The exploit did not reproduce on the patched builds we tested. That is not proof that every patched build is safe.
An unauthenticated attacker who succeeds runs code as the web-server account. Depending on the deployment, that can mean access to application data and credentials, modified content, or a foothold for further compromise.
It does not automatically mean root access or control of the network. What follows depends on what the web-server account can reach.
In our tested environment, the exploit worked with ASLR enabled and error display disabled. Neither setting is a substitute for patching.
Some of our attempts produced failed HTTP requests or worker exits. Unusual web traffic, repeated server errors, worker restarts and unexpected activity from web-server processes can all be leads. None of these is a unique or dependable signature, and their absence does not prove a system is safe.
That gap is where controlled validation helps. Run against a vulnerable build in a proper environment, the exploit shows what an attempt leaves in your logs and what your monitoring picks up. It also shows whether a detection fires at the point of execution or only on a suspicious request. Run again after remediation, it lets you compare behavior before and after the fix.
Any active validation needs agreed scope and a suitable test environment. This is not a production-safe scanning tool.
On October 23, PHP published a separate informational advisory about a session upload progress issue. Follow PHP’s guidance on that advisory. It does not change the negative 8.5.12 control for this exploit.
The exploit and our deeper findings are available only to CovertSwarm customers.
We are not releasing it publicly yet. Organizations are still patching, and we won’t give bad actors a step-by-step route in. For customers, we can use it to help develop or validate detections.
If you want to know more, get in touch: www.covertswarm.com/contact