‼️ Websites Worldwide Targeted By Millions of Attempts To Exploit Critical PHP Vulnerabilities

Website operators are confronting an urgent security threat after Cloudflare reported millions of attempts to exploit PHP2Shell, two critical vulnerabilities in PHP.

Emergency updates released on 21 October address weaknesses that can allow attackers to execute code without authentication. The PHP development team has warned that installations serving web requests require attention, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk deployment, citing a demonstrated attack that can begin before application code executes.

The response has already disrupted online services. Reuters reported precautionary suspensions at Japanese financial and transport companies, Orange subsidiaries and Finnish government services. Cloudflare chief executive Matthew Prince described attack attempts escalating from thousands before disclosure to hundreds of thousands within two hours, then millions. Finland’s state IT provider, Valtori, said its shutdowns were preventive rather than the result of a confirmed breach.

The distinction between attempted exploitation and successful compromise remains central to understanding the incident. Large volumes of malicious traffic demonstrate intense interest in the vulnerabilities, but they do not establish how many servers attackers have successfully penetrated.

Sansec’s updated assessment , published on 22 October, says exploitation requires knowledge of the target and particular conditions, making indiscriminate mass compromise less straightforward than initially feared. The company nevertheless continues to urge immediate updates.

Critical Flaws Affect the Underlying PHP Runtime

The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 , affect PHP’s internal memory handling. Both carry critical CVSS v4.0 ratings of 9.2. They sit beneath individual websites and applications, creating a remediation problem that cannot be resolved simply by updating a content management system or removing a vulnerable plugin. AWS’s technical guidance identifies upgrading PHP as the complete fix.

PHP’s extensive use across hosting environments makes that distinction consequential. An organisation may maintain its website diligently while depending on a hosting provider, infrastructure team or software supplier to update the underlying runtime.

Cloudflare specifically warns that application and plugin updates alone cannot repair PHP2Shell. Where hosting providers manage PHP, customers need confirmation that those providers have applied the relevant security updates.

Amazon Records Attempts Before Public Disclosure

One of the most significant developments is evidence that attempts began before the coordinated public release.

In its PHP2Shell threat intelligence report , Amazon said its MadPot honeypot network recorded an attempt on 17 October , four days before the patches and coordinated technical disclosure. Further attempts appeared ahead of the release on 21 October, with differences in payloads and infrastructure suggesting multiple actors.

Amazon said it remained uncertain whether those early attempts would have succeeded against real-world systems. It also did not establish how the actors obtained the relevant information. Its findings support looking for suspicious activity before the public announcement, rather than assuming exposure began when the emergency updates became available.

Leaked Details Accelerate the Emergency Release

Disclosure itself became part of the response challenge. According to Huntress’s incident account , details circulated online on 20 October before the intended coordinated announcement. PHP subsequently scheduled an accelerated security release.

That sequence left administrators preparing for a critical update while information the flaws was already spreading. Huntress reported that it had not observed exploitation across its partner base as of 10am Eastern time on 21 October, while acknowledging reports from other providers. That observation was limited to its own visibility and the stated time; it should not be interpreted as evidence that exploitation was absent elsewhere.

How the Two Memory Vulnerabilities Work

The first vulnerability, CVE-2026-109618 , concerns how PHP responds when a memory allocation fails.

PHP can abort a request while internal data is only partially initialised. Its cleanup routines may subsequently treat that unfinished data as valid. Under exploitable conditions, the result can extend beyond a crashed process to remote code execution.

The official advisory describes several ways of reaching the vulnerable state. Crucially, the failed memory allocation does not have to occur in the same operation that left the invalid data behind. This makes the problem more complex than a single oversized request or a simple resource-consumption bug.

The second vulnerability, CVE-2026-109619 , involves internal state surviving after the memory supporting it has been released.

PHP worker processes can handle successive requests. Certain error conditions leave a worker retaining references to memory belonging to an earlier request. Before normal initialisation replaces those references, another operation may access them, creating a use-after-free condition.

The advisory explains that fatal errors are not the only relevant trigger: some nonfatal diagnostics can also recreate state after cleanup has already occurred. Carefully arranged memory conditions can turn the resulting invalid access into remote code execution.

Sensitive Data Exposure and the Role of AI in Research

These mechanisms explain why the scope of the incident extends beyond any one website product. Wiz’s research describes demonstrations against widely used applications and warns that exposed process memory may contain passwords, authentication tokens, API keys or certificates.

Wiz also describes artificial intelligence as instrumental in making complex exploitation research practical. Its researchers used frontier models to help develop and adapt exploit chains across different applications. The company’s account points to a change in the effort required to investigate longstanding memory-safety weaknesses, rather than evidence that every attack now being observed is AI-generated.

Exploitation Depends on the Target Environment

There remains an important difference between a runtime containing a vulnerability and an attacker having a reliable exploit for every installation.

Publicly available demonstrations do not establish a universal request that compromises all vulnerable servers. Some depend on additional application weaknesses or specific environmental conditions. That assessment tempers comparisons with vulnerabilities whose exploitation could be automated uniformly across large numbers of targets; it does not overturn PHP’s warning that affected installations need patching.

Emergency Updates and Fixed PHP Versions

For administrators, the immediate priority is installing the appropriate fixed release. The PHP security announcement identifies these versions:

Older branches require particular care. PHP 8.1 and earlier no longer receive ordinary upstream updates, although some distribution and long-term-support vendors provide backported fixes. PHP also supplied minimal source backports for versions 7.4, 8.0 and 8.1 to assist maintainers and organisations building their own packages.

Restarting Processes and Rebuilding Container Images

Deployment details matter as much as obtaining a patched package. Aikido’s remediation guidance calls for restarting PHP processes and rebuilding container images. Updating only a running container can leave its underlying image vulnerable, allowing a later deployment to reintroduce the problem.

The practical implication is that remediation needs to reach both the systems currently handling requests and the templates or images used to replace them. Teams should verify the runtime actually serving web traffic, rather than treating a completed package installation as sufficient evidence that every application instance is protected.

Web Application Firewalls Provide Limited Protection

Web application firewalls offer an additional defensive layer, but their coverage has limits.

Cloudflare says it deployed protections for customers using its free and paid WAF services before public disclosure. It also observed attackers changing payloads to try to evade detection. Its response included examining both incoming requests and outgoing responses, giving detection systems more context than request inspection alone.

Despite those protections, Cloudflare continues to recommend patching the PHP runtime.

AWS similarly presents firewall rules as temporary exposure reduction. Its guidance discusses restrictions on multipart uploads and known request patterns, while explaining that a firewall cannot inspect PHP worker memory or fully account for server-side configuration.

Such restrictions can also interfere with legitimate uploads. Organisations therefore need to assess their application requirements when applying temporary controls, while continuing the runtime upgrade. A blocked attack pattern does not establish that all paths to exploitation have been removed.

Investigating Exposure Before the Patches

Patching also needs to be accompanied by an investigation proportionate to the system’s exposure.

Amazon recommends reviewing activity from at least 17 October, checking web logs, unexpected process execution and unexplained file modifications. Its published infrastructure indicators include shared anonymisation services, so a matching address warrants investigation rather than being treated automatically as proof of compromise.

For security teams, that means separating three questions: whether a server was vulnerable, whether it received suspicious requests, and whether those requests produced unauthorised activity. Each requires different evidence. A firewall alert may demonstrate targeting; unexpected processes or modified application files may justify a deeper incident response.

Distinguishing Precautionary Measures From Confirmed Breaches

The same distinction should guide communication with customers and executives. Precautionary downtime, attempted exploitation and confirmed data theft describe materially different events. Reporting them accurately is essential while the incident remains fluid.

PHP2Shell now presents organisations with two parallel responsibilities: remove the vulnerable runtime and establish whether earlier exposure led to compromise. The availability of emergency fixes makes rapid remediation possible, but the evidence of pre-disclosure activity means installing those fixes cannot, by itself, answer what happened before them.

👆🏻 Download the full threat report to uncover the DNS infrastructure behind the global BigBear 2.0 PhaaS campaign