Cloudflare has reported a sharp surge in cyberattack attempts following the disclosure of two critical vulnerabilities in PHP, the programming language used by a large portion of the web. The attacks accelerated within hours of details becoming public, rising from thousands of attempts to tens of thousands within 45 minutes, hundreds of thousands within two hours and millions afterward. The vulnerabilities, collectively known as PHP2Shell, could allow attackers to execute malicious code on vulnerable web servers without first authenticating.

The incident highlights how quickly attackers can weaponize newly disclosed security flaws, particularly when the affected technology is widely deployed. Cloudflare says it developed and deployed web application firewall protections before public disclosure, making them available to customers with its WAF enabled, including free-plan users. However, the company warns that these protections are not a substitute for installing the official PHP security updates. The reported surge represents attempted exploitation, not proof that millions of systems were successfully compromised.

Key Takeaways

  • Millions of exploit attempts reported: Cloudflare observed attacks escalating rapidly after PHP2Shell details became public.
  • Two critical vulnerabilities identified: CVE-2026-109618 and CVE-2026-109619 affect PHP’s runtime and memory-handling behavior.
  • Remote code execution is possible: Attackers may be able to execute malicious code on vulnerable servers without authentication.
  • Emergency patches are available: PHP released security updates for supported branches, including PHP 8.5, 8.4, 8.3 and 8.2.
  • Cloudflare deployed WAF protections: Rules were activated ahead of public disclosure and are available to customers with WAF enabled.
  • Website operators must still patch: Firewall protection reduces risk but does not eliminate the underlying vulnerability.
  • Service disruptions were reported: Some organizations restricted or suspended online services as a precaution.

What Happened After the PHP Vulnerabilities Were Disclosed?

The incident illustrates the speed at which cybersecurity threats can escalate once vulnerability details or working exploit techniques become available.

According to Cloudflare CEO Matthew Prince, the company initially observed thousands of exploitation attempts. That activity increased to tens of thousands within 45 minutes, hundreds of thousands within two hours and millions over the subsequent period.

The rapid escalation suggests that attackers were actively testing ways to exploit the newly disclosed weaknesses. Security researchers also reported changes in attack payloads as attackers attempted to evade existing protections.

The vulnerabilities became known as PHP2Shell. They affect the PHP runtime itself rather than being confined to a single website plugin or application.

This distinction is important. Websites built using popular platforms such as WordPress, Drupal, Joomla and Magento may depend on PHP, but the vulnerability can exist in the underlying PHP software even when an individual website’s application code is otherwise secure.

Cloudflare’s observations demonstrate the difference between a coordinated disclosure process and what happens when technical details become available to potential attackers. Once the vulnerability is understood, automated scanning and exploitation can spread quickly across internet-facing systems.

What Is PHP2Shell?

PHP2Shell refers to two critical vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619.

Both involve unsafe memory handling when PHP processes requests that trigger certain error conditions. Under particular circumstances, PHP may fail to initialize or manage internal data safely, potentially allowing an attacker to manipulate memory in ways that lead to serious security consequences.

CVE-2026-109618: Out-of-memory corruption

This vulnerability involves PHP’s handling of a request when the runtime runs out of memory.

Under certain conditions, the error and cleanup process can leave internal data in an unsafe state. An attacker may be able to exploit that behavior to corrupt memory and potentially execute malicious code.

CVE-2026-109619: Stale global state

The second vulnerability involves references to memory that has already been released.

If PHP retains an unsafe reference after a request ends, a later request handled by the same process may interact with invalid memory. Depending on the environment and exploit conditions, this can lead to memory disclosure or remote code execution.

Both vulnerabilities are serious because they affect the software responsible for processing web requests. Attackers may not need a valid account or user interaction to exploit a vulnerable server.

VulnerabilityCore issuePotential impact
CVE-2026-109618Out-of-memory corruptionMemory corruption and possible remote code execution
CVE-2026-109619Stale references to released memoryMemory disclosure and possible remote code execution
Combined namePHP2ShellPotential compromise of vulnerable PHP servers

The PHP security team rated both issues as critical, with a CVSS v4.0 score of 9.2 reported by security advisories.

Why the Vulnerabilities Pose a Broad Risk

PHP remains one of the most widely used server-side programming languages. It powers websites, content management systems, e-commerce platforms and many custom web applications.

That widespread adoption creates a large potential attack surface. A vulnerability in an application-specific plugin may affect a limited set of installations, whereas a flaw in the PHP runtime can affect many different applications that rely on vulnerable PHP versions.

The risk is particularly significant for internet-facing servers that process requests from untrusted users. Depending on the server configuration and exploit path, an attacker could potentially gain the ability to run code with the permissions of the PHP worker process.

Possible consequences include:

  • Unauthorized access to application data
  • Exposure of sensitive information
  • Installation of malicious software
  • Disruption of website availability
  • Further attacks against connected systems

A successful exploit does not automatically give an attacker unrestricted control over an entire organization. The impact depends on the server’s permissions, configuration, network access and other security controls. Nevertheless, remote code execution can provide a serious foothold that attackers may use to escalate their activities.

Cloudflare’s Response and Web Application Firewall Protections

Cloudflare said it developed mitigations and deployed protections before the public disclosure of PHP2Shell.

According to the company’s October 21 security blog, its protections became available to customers with its web application firewall enabled at 03:02 UTC that day, approximately nine hours before public disclosure.

Cloudflare also introduced a detection approach that evaluates information from both the incoming request and the server’s response. This can help distinguish malicious activity from legitimate traffic more accurately than rules that examine the request alone.

The company said attackers were changing their payloads to try to bypass existing protections, prompting continued monitoring and adjustments to its defenses.

Cloudflare made the relevant managed protections available across its plans for customers using its WAF, including free-plan customers.

However, a WAF operates as an additional security layer. It can block known attack patterns, but it cannot guarantee that every exploit variant will be detected or that a vulnerable server is safe.

Cloudflare has therefore urged customers to apply the PHP patches even if they already use its protective rules.

PHP Releases Emergency Security Updates

The PHP development team released emergency security updates addressing both vulnerabilities.

The primary fixed versions announced for supported branches were:

PHP branchFixed version
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Additional source-level backports were made available for PHP 7.4, 8.0 and 8.1. Administrators using older releases should check the relevant PHP advisory, operating-system vendor or hosting provider for an appropriate supported fix.

Installing an update is not always the end of the process. Administrators must ensure the updated runtime is actually being used by the web server and restart the relevant PHP processes when required.

Updating WordPress, a plugin or a theme alone does not fix a vulnerability in the PHP runtime. Website operators need to update the underlying PHP installation.

Website Disruptions and Emergency Measures

The incident also prompted organizations to take precautionary measures.

Reports described some European government websites becoming unavailable and Japanese financial institution Mitsubishi UFJ Financial Group temporarily suspending certain internet services. Japan’s Finance Ministry also restricted access to its website as a precaution, while Japanese Prime Minister Sanae Takaichi urged website operators to check whether they use PHP and apply the necessary updates.

These restrictions demonstrate how organizations may respond when a serious vulnerability creates uncertainty about their exposure.

However, a service being taken offline does not itself prove that the organization was successfully breached. Some restrictions were precautionary measures intended to reduce risk while administrators assessed their systems and applied fixes.

For organizations operating essential services, the decision to temporarily restrict access can be a way to reduce exposure when immediate patching or verification is not possible.

What Website Owners and Developers Should Do

The most important step is to establish which PHP version is running on every internet-facing server and apply the appropriate security update.

Organizations should also review their exposure and investigate any suspicious activity that occurred before patching.

Recommended actions include:

  1. Inventory PHP installations: Check production servers, staging environments, containers and managed hosting accounts.
  2. Apply the security update: Install the fixed release appropriate for the PHP branch and operating environment.
  3. Restart PHP processes: Confirm that web servers and PHP workers are using the patched runtime.
  4. Keep WAF protections enabled: Use Cloudflare or another suitable security layer to help block malicious requests.
  5. Review security logs: Look for suspicious requests, unusual PHP errors, unexplained process restarts or unexpected changes to files.
  6. Assess possible compromise: If a server was exposed while vulnerable, investigate it rather than assuming that a later patch resolves any earlier intrusion.
  7. Contact hosting providers: If PHP is managed by a hosting company, request confirmation that the affected runtime has been patched.

Organizations should also follow official advisories for their operating system, hosting environment and PHP distribution. Security fixes can be delivered differently by different vendors, so version numbers and remediation instructions should be verified against the system actually in use.

The Bigger Picture

The PHP2Shell incident shows why vulnerability disclosure is a critical moment in the cybersecurity lifecycle. A security flaw may remain difficult to exploit until researchers identify the underlying behavior, but once details become public, attackers can quickly automate their attempts against exposed systems.

The episode also demonstrates the importance of coordinated security work. Researchers, maintainers, infrastructure providers and hosting operators all play different roles in finding vulnerabilities, developing fixes, blocking malicious traffic and reducing exposure.

Cloudflare’s early protections provided an additional layer of defense, but the incident reinforces a fundamental principle: perimeter security cannot replace fixing vulnerable software. Organizations that depend on widely deployed technologies must be prepared to patch quickly and verify that those patches are effective.

FAQs

1. What is PHP2Shell?

PHP2Shell is the name used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Under certain conditions, the flaws can allow attackers to execute malicious code on vulnerable web servers.

2. How many attacks did Cloudflare observe?

Cloudflare reported that attempts rose from thousands before disclosure to tens of thousands within 45 minutes, hundreds of thousands within two hours and millions afterward. These figures describe attempted exploitation, not confirmed successful breaches.

3. Which PHP versions are affected?

The vulnerabilities affect PHP installations that process web requests. Fixed releases were announced for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with additional source backports for certain older branches. Administrators should consult official advisories for their exact environment.

4. Does Cloudflare protect websites against PHP2Shell?

Cloudflare deployed managed WAF protections for customers with WAF enabled, including free-plan customers. These rules provide an additional defense layer but do not replace installing the PHP security update.

5. Can updating a WordPress plugin fix PHP2Shell?

No. The vulnerability affects the PHP runtime itself, so updating a WordPress plugin or theme alone is insufficient. Website owners must update the PHP software running their applications or confirm that their hosting provider has done so.

Looking Ahead

The immediate priority is for website operators to identify vulnerable PHP installations, apply the appropriate security updates and investigate suspicious activity. Cloudflare’s observations show how quickly attackers can scale their efforts after a vulnerability becomes public, making delayed patching a significant risk.

The longer-term lesson is that security depends on more than a single protective product. Coordinated disclosure, reliable software updates, layered defenses and continuous monitoring must work together. For organizations running PHP-based websites, verifying that the fixed runtime is active is the most important step toward reducing exposure to PHP2Shell.

Get the day’s top stories in your inbox

One concise email. No spam, unsubscribe anytime.