Hackers began targeting critical PHP vulnerabilities before their public disclosure, raising concerns about the security of millions of websites. Amazon Threat Intelligence identified a suspected exploitation attempt dating back to October 17, while Cloudflare reported attack traffic against its customers before PHP officially released its security fixes.
The threat has grown further after researchers demonstrated a new exploit capable of achieving remote code execution on x86-64 systems even when Address Space Layout Randomization (ASLR), a widely used memory protection, is enabled, according to VulnCheck’s latest research.
The vulnerabilities, collectively known as PHP2Shell, affect the PHP programming language itself rather than a specific website, content management system or plugin. They could allow unauthenticated attackers to execute malicious code on vulnerable servers, potentially exposing sensitive data or giving attackers control over affected systems.
PHP powers a substantial share of the web, including websites built with WordPress, Drupal, Joomla and other PHP-based platforms. Its widespread use makes these vulnerabilities a serious concern for website owners, hosting providers and organizations running internet-facing applications.
Amazon Finds a Suspected Attack Before Public Disclosure
Amazon Threat Intelligence reported on October 22 that its MadPot honeypot system recorded a PHP2Shell exploitation attempt on October 17, four days before the vulnerabilities were publicly disclosed. The activity originated from an IP address associated with a commercial anonymization network, which can be used to conceal a user’s original IP address.
The discovery raises questions about whether someone obtained information about the vulnerabilities before the public announcement. However, Amazon said it remains unclear how the attacker learned about the flaws, and the available evidence does not establish that the attempt successfully compromised a real-world server. The company’s security investigation provides further details about the activity detected by its honeypot system.
Amazon also observed proof-of-concept exploits appearing around the time of the public disclosure. Further attempts reached its honeypots through different anonymized infrastructure, showing how quickly attackers began testing the flaws once technical details became available.
The activity highlights a growing challenge for website operators: the time between a vulnerability being disclosed and attackers attempting to exploit it can be extremely short.
New Exploit Works Even With ASLR Enabled
One of the most significant developments emerged on October 22, when VulnCheck reported developing an exploit for CVE-2026-109618 that chains a memory leak with remote code execution on PHP 8.4.26.
According to the company’s technical analysis, the exploit works on x86-64 systems with ASLR enabled and display_errors=off, a configuration commonly used in production environments. VulnCheck made the exploit available to its Initial Access Intelligence customers and said it was not aware of another public or commercial exploit achieving remote code execution under the same conditions at that time.
The finding matters because ASLR randomizes memory addresses to make certain exploitation techniques harder. Earlier testing had demonstrated remote code execution on ARM64 systems and x86 systems without ASLR. The newer result extends the demonstrated attack capability to x86-64 systems with that protection enabled.
VulnCheck also reported that hundreds of proof-of-concept repositories had appeared on GitHub. Its analysis found that only a small number contained legitimate exploits, and the company had not identified another public proof of concept independently bypassing ASLR on x86-64 systems.
Even when many samples are unreliable, the rapid publication of exploit code can help attackers test different techniques against unpatched servers.
Cloudflare Detects Attackers Modifying Their Payloads
Cloudflare confirmed that attackers started testing PHP2Shell before the official disclosure. The company had prepared web application firewall protections in advance and deployed mitigations before the public announcement.
Cloudflare said its security systems detected attackers modifying their payloads in attempts to bypass the protections. The company also developed detection logic that considers information from both incoming requests and server responses within the same HTTP transaction, helping it distinguish potential exploitation attempts from legitimate traffic. Its technical report on PHP2Shell protection explains how these defenses were deployed.
The protections provide another layer of defense for websites using Cloudflare’s web application firewall. However, firewall rules are not a substitute for installing the official PHP security updates. Administrators should not assume that a website is safe simply because a CDN or security plugin is blocking known attack patterns.
AI Could Accelerate Exploit Development
PHP2Shell has also drawn attention to the growing role of artificial intelligence in vulnerability research and exploitation.
Security researchers have described how advanced AI models can help analyze complex code, identify memory-safety problems and turn technical findings into working exploits. In this case, Wiz Research’s analysis of PHP2Shell examined how the vulnerabilities could be exploited and why they pose a significant risk to organizations running PHP.
The concern extends beyond discovering vulnerabilities. Once patches and technical details become public, attackers can analyze the changes to understand what was fixed and develop tools to target systems that have not yet been updated. The rapid appearance of proof-of-concept code following the PHP2Shell disclosure demonstrates how quickly the situation can change.
That does not mean every AI-generated exploit works or that every vulnerable website has been compromised. Researchers have found that many publicly shared proof-of-concept repositories do not contain functional exploits. However, a working technique can spread quickly while vulnerable systems remain online.
What Are the Two PHP2Shell Vulnerabilities?
PHP2Shell refers to two critical vulnerabilities in PHP’s underlying runtime. Both received a CVSS v4.0 severity score of 9.2 out of 10 and can potentially be triggered without authentication. The vulnerabilities and their affected versions are covered in the official PHP security announcements.
| Vulnerability | What it means |
|---|---|
| CVE-2026-109618 | An out-of-memory handling flaw can leave internal request data incompletely initialized. During cleanup, PHP may incorrectly use that data, creating a potential path to remote code execution. |
| CVE-2026-109619 | A stale global-state flaw can leave references to memory that has already been freed. A later request may reuse those references, potentially exposing memory or enabling remote code execution. |
These are vulnerabilities in the PHP runtime, not weaknesses limited to WordPress or a particular plugin. A website can therefore be exposed even if its themes and plugins are fully updated, provided the underlying PHP installation remains vulnerable.
The risk can be especially serious in Apache installations using mod_php, where a request may trigger the vulnerability before the application’s own code runs. Cloudflare’s technical analysis provides further details about the affected runtime behavior and mitigation strategies.
Which PHP Versions Have Been Patched?
The PHP development team released security updates on October 21, 2026. Administrators should install the appropriate fixed release for their PHP branch.
| PHP branch | Fixed version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP 8.1 and older are no longer supported by the upstream PHP project and do not receive its regular security updates. Some Linux distributions and long-term support vendors provide security fixes through backported patches, so administrators using older versions should check their supplier’s advisory or plan to move to a supported release.
The issue can affect internet-facing PHP deployments running PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Website owners should check the PHP runtime actually used by their application rather than assuming that updating WordPress or installing a security plugin is sufficient.
For the latest patch information, consult the official PHP release announcements and your operating system or hosting provider’s security advisory.
How Website Owners Can Protect Their Sites
The most important step is to install the official PHP security update. The PHP security announcement provides further information about the fixes, and there is no complete workaround that replaces patching the vulnerable runtime.
Website owners should first confirm which PHP version their live website is using. Managed hosting customers should contact their providers and ask whether the PHP2Shell fixes have been installed on the server and all relevant PHP workers.
If this article helped you, please consider supporting our work. Every small contribution keeps Abijita.com independent and running.
Organizations should also keep their web application firewalls enabled and review server logs for suspicious requests, unusual PHP worker restarts, repeated HTTP 500 errors and memory-related failures. These indicators do not prove that an attack succeeded, but they can help administrators identify systems that need further investigation. Additional defensive guidance is available in Check Point’s PHP2Shell security analysis.
The US National Security Agency has also issued guidance on the vulnerabilities and recommended that organizations consider taking affected systems offline when an immediate update is not feasible. Administrators should assess the exposure of their systems and prioritize patching internet-facing services.
For WordPress site owners, the key point is that updating WordPress alone will not fix PHP2Shell. The PHP version running on the server must be patched. If the hosting environment cannot be updated promptly, administrators should consider temporarily restricting access to the affected service until the fix is applied.
PHP2Shell Attacks Spread Before Disclosure as New Exploit Bypasses ASLR
