PHP2Shell and the “Patching Can’t Keep Up” Problem: Put Cloudflare in Front of Your Website as a Security Gateway

In late October 2026, website operators found themselves in a race against time with the PHP2Shell vulnerability in the PHP core. Technical teams were forced to patch, update, and verify, while attackers had already struck before official patches were released.

This article summarizes what happened with PHP2Shell, why patching alone is often not fast enough, and a complementary approach: placing a protective gateway at the website entrance using Cloudflare, alongside patching efforts.

1. What happened with PHP2Shell?

On October 21, 2026, PHP disclosed two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both received a 9.2/10 rating on the CVSS v4.0 scale and affect PHP, the engine powering roughly 70% of websites worldwide according to W3Techs.

Of particular concern: details were leaked and active exploitation occurred before security patches were officially published.

2. How dangerous is PHP2Shell?

PHP2Shell allows unauthenticated attackers to execute remote code without logging in, read sensitive memory data, or cause service crashes. Because the flaw resides within the PHP core, it affects virtually all web server configurations running PHP 5.4 or higher.

Mechanism: Two memory management flaws

Both flaws trigger when PHP processes an HTTP request that gets interrupted mid-execution:

• CVE-2026-109618: Upon running out of memory, PHP halts while request-internal data is only partially initialized. Subsequent cleanup steps treat this uninitialized data as valid structures.
• CVE-2026-109619: Following a fatal error, internal state pointers continue pointing to freed memory regions. Subsequent requests processed by the same worker process can reuse this stale state.

Attackers trigger these conditions using specially crafted HTTP requests. PHP's upload tracking feature (session upload progress) is one confirmed vector for exploitation.

Who is affected?

PHP developers noted that all common web server deployments are at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The highest risk lies with mod_php, where unauthenticated requests can initiate attacks even before application code executes.

Research teams analyzing the vulnerability tested environments running WordPress, Drupal, and Joomla, confirming unauthenticated remote code execution as well as extraction of passwords, authentication tokens, and API keys directly from PHP memory.

What does this mean for businesses?

• Loss of server control: attackers can install malicious scripts or tamper with website content.
• Data exposure: customer records, database credentials, and API keys can be exfiltrated.
• Business disruption: websites can be taken down, directly impacting sales and customer operations.

Updating WordPress or plugins does not resolve this vulnerability. The underlying PHP runtime environment on the server must be updated.

3. Why is patching alone not fast enough?

Patching PHP is the only complete root-cause fix for PHP2Shell. However, the event highlighted a persistent exposure window between active attacker exploitation and full patch deployment. This gap stems from four key factors:

1. Attacks precede patches. Vulnerability details leaked prior to official public disclosure, and Cloudflare observed attack traffic targeting customers before patches became available.
2. Immediate patching is not always feasible. Many sites operate on managed hosting environments where PHP updates depend entirely on provider maintenance schedules.
3. Legacy versions lack official patches. PHP 8.1 and earlier branch releases no longer receive official updates from the PHP project. PHP 8.2 will also reach End-of-Life on December 31, 2026.
4. Variants emerge after initial fixes. Two days later, PHP disclosed CVE-2026-115560, affecting patched versions like 8.5.12 under specific configurations. This variant will be addressed in a subsequent scheduled release.

This reality creates a classic operational dilemma. The key question becomes: how can organizations minimize risk while waiting to patch?

4. A complementary solution: Placing a protective shield at the website entry

Instead of relying solely on updating backend servers, an extra layer can be added: all website traffic must pass through a front-line perimeter control first. This perimeter filters malicious requests before they reach origin servers. Cloudflare operates on this model, standing in front of origin infrastructure to inspect traffic and filter out attack patterns.

What is Cloudflare?

Cloudflare is an Internet infrastructure company offering services such as Content Delivery Networks (CDN), Web Application Firewalls (WAF), and Distributed Denial-of-Service (DDoS) mitigation. While largely transparent to end-users, roughly 20% of web properties globally utilize its platform.

By proxying traffic for millions of websites, Cloudflare detects emerging threat vectors across its network and deploys rules globally. Consequently, protection efficiency depends heavily on how rapidly rules are updated.

How does the protective gateway work?

When proxying is enabled on DNS records, incoming client connections terminate at Cloudflare rather than origin servers. Cloudflare inspects requests and forwards valid traffic to the backend. The true IP address of the origin server remains concealed.

Valid requests route through Cloudflare to origin servers. Direct connections targeting the origin IP are blocked when servers are properly hardened as described below.

Prerequisites for effective origin shielding

Hiding DNS records alone is insufficient. If attackers discover the origin IP, they can bypass Cloudflare entirely. Cloudflare recommends:

• Restricting inbound origin server traffic exclusively to Cloudflare IP ranges, blocking all other sources.
• Auditing non-proxied DNS records (e.g., SPF, TXT) to ensure they do not expose origin IPs.
• Separating mail services onto independent infrastructure, as outbound mail headers can reveal server IPs.
• Rotating origin server IP addresses post-migration, as historic DNS lookup data persists in public databases.
• Alternatively, implementing Cloudflare Tunnel: origin servers establish outbound daemon connections to Cloudflare, eliminating the need for open inbound ports or public origin IPs entirely.

5. How Cloudflare mitigated PHP2Shell

Cloudflare deployed emergency WAF rules blocking PHP2Shell prior to official vulnerability publication, providing default protection for customers across both Free and paid tiers.

Differences across service tiers

• Free Tier: new protections were incorporated into the Cloudflare Managed Free Ruleset and enabled automatically without configuration changes.
• Pro, Business, Enterprise Tiers: rules reside within the Cloudflare Managed Ruleset. Administrators should confirm that rule action states are set to Block.

Introducing Full Transaction Detection

Cloudflare noted that inspecting request payloads alone cannot reliably distinguish exploitation attempts from legitimate traffic in all cases. To address this, they introduced Full Transaction Detection, a WAF capability analyzing both incoming requests and origin server responses within a single HTTP stream.

This dual-layer mechanism operates as follows:

1. Requests matching definitive attack signatures are blocked at the edge network.
2. If a request bypasses initial filters, Cloudflare can still intercept and block the origin response before it reaches the client, preventing memory exfiltration.

PHP2Shell mitigation rules served as the initial deployment of this technology, enabled automatically across all plan levels, including Free accounts.

An ongoing cat-and-mouse game

Cloudflare observed attackers rapidly modifying payload structures to evade detection, prompting continuous security rule updates.

Regarding the CVE-2026-115560 variant disclosed on October 23, Cloudflare stated existing rules maintain protection, provided that websites retain the default naming parameter for session.upload_progress.name.

6. Operational benefits beyond security: Performance, offloading, and low entry cost

Deploying Cloudflare at the network edge offers three distinct operational advantages alongside attack mitigation.

• Improved latency: Cloudflare caches static content across global edge data centers closer to end-users.
• Reduced origin load: edge caching decreases request volume hitting backend servers, while automated DDoS protection mitigates volumetric surges.
• Low barrier to entry: the Free tier includes automated WAF mitigations for major threats like PHP2Shell. Comprehensive managed rule suites begin at the Pro tier ($20/month billed annually).

(Major cloud providers like AWS and Azure offer comparable WAF solutions, though pricing structures and default rule implementations vary.)

Is deployment complex?

In most scenarios, no application refactoring is required. The primary setup step involves migrating domain DNS management to Cloudflare and enabling proxy mode for relevant DNS records.

However, securing origin servers against direct IP access requires backend firewall configuration as outlined in Section 4, which should be performed by technical personnel.

7. Cloudflare is not a silver bullet

While Cloudflare reduces exposure during patch delays, it does not replace patching PHP. Cloudflare explicitly advises patching core software, treating WAF protection as defense-in-depth. Six limitations should be noted:

1. Protection depends on existing rules. WAFs rely on signature rules published by vendors. Prior to rule availability for zero-day flaws, backend systems remain vulnerable. Pre-disclosure deployment occurred for PHP2Shell, but future zero-day guarantees cannot be made.
2. Cannot reverse executed code. Blocking outbound response payloads prevents data exfiltration, but cannot roll back server-side code execution that already ran on the origin.
3. Rule evasion risks. Attackers continuously iterate payload obfuscation techniques to bypass WAF signatures.
4. Proxied traffic coverage only. Direct connection requests reaching origin IP addresses bypass edge inspection completely.
5. Configuration dependency. Paid tiers require rule actions to be set to Block. Sites modifying session.upload_progress.name are not protected against the CVE-2026-115560 variant by default rules.
6. Single point of dependency. Edge provider service outages directly impact all downstream proxied properties.

8. Immediate recommended action plan

The highest priority action is patching PHP. Subsequent steps mitigate risk during and after update deployment.

Root-cause remediation

• ☐ Audit all web servers running PHP and identify installed version numbers. If using managed hosting, request immediate updates from your provider.
• ☐ Upgrade PHP installations to version 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or higher, depending on the active branch.
• ☐ For PHP 8.1 or earlier: coordinate with Linux distribution vendors or Long-Term Support (LTS) providers for backported patches, or plan upgrades to supported release branches.
• ☐ Plan migration paths off PHP 8.2 prior to its December 31, 2026 End-of-Life date.

Temporary mitigation (does not replace patching)

• ☐ Set session.upload_progress.enabled=0 inside php.ini, FPM pool configurations, or main server configs, then restart worker processes. Avoid relying on ini_set() or .user.ini for this configuration.
• ☐ Maintain this setting until the next scheduled PHP release to safeguard against the CVE-2026-115560 variant.

Cloudflare perimeter defense

• ☐ Enable proxying (orange cloud status) for website DNS records.
• ☐ Restrict direct origin traffic: configure firewall rules to accept connections solely from Cloudflare IP ranges, or implement Cloudflare Tunnel while keeping daemon clients updated.
• ☐ Paid tiers: verify Managed Rulesets have rule action modes configured to Block.
• ☐ Review Security > Security Analytics > Events in the dashboard, filtering by PHP2Shell rule IDs to identify scanning or attack activity targeting your domain.

9. Incident response: If compromise is suspected

Because active exploitation preceded patch releases, unpatched servers exposed during that timeframe should be audited. If indicators of compromise are observed, follow this response sequence:

1. Isolate origin servers. Disconnect origin servers from network access. Blocking via Cloudflare WAF only filters proxied traffic and does not prevent direct access to exposed origin IPs.
2. Analyze logs. Correlate Cloudflare security event logs (filtered by PHP2Shell rule IDs) against web server and PHP error/access logs to identify attack origins and timelines.
3. Patch PHP prior to restoration. Restoring clean backups onto unpatched server environments leaves the system vulnerable to re-compromise upon reconnection.
4. Rotate all secrets. Cycle database passwords, API credentials, session keys, and application secrets. Reason: the vulnerability allows arbitrary memory disclosure, potentially compromising active secrets residing in PHP process memory.

10. Conclusion: Patch the core, guard the entrance

The PHP2Shell incident demonstrates that threat actors can launch exploits before patches become available. While patching PHP remains mandatory, implementing an edge gateway like Cloudflare allows organizations to mitigate risk during the vulnerable window prior to patch completion, offering low initial costs and minimal architectural friction.

This strategy forms a dual-layer defense: patching core software on the inside while maintaining perimeter surveillance at the entrance. The two controls complement each other; neither replaces the other.

References

• Cloudflare – Cloudflare deploys protections against php2shell vulnerability
• PHP.net – News Archive 2026（10/21および10/23のアドバイザリ）
• Cloudflare Docs – Protect your origin server
• Cloudflare Docs – Secure your origin
• Cloudflare Docs – Restrict external connections
• Kinsta – Cloudflare Market Share
• PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• Cloudflare – Plans