Cloudflare deploys protections against php2shell vulnerability

Today, Calif.io, Wiz, OpenAI and Quarkslab disclosed two vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and known as php2shell. The vulnerabilities affect all web servers running PHP 5.4 or later and they may allow an attacker to cause denial of service, remote code execution, and data exposure when an application processes specially crafted HTTP traffic.

Cloudflare has been part of a coordinated effort to deploy mitigations to protect the Internet, working with PHP foundation, OpenAI and Wiz among others. Cloudflare has developed and deployed web application firewall (WAF) protections since early October 2026, which were deployed about 9 hours ahead of public disclosure. Starting on October 21 3:02 am UTC, Cloudflare customers using our free or paid WAF were protected by default against php2shell.

Cloudflare successfully deployed multiple mitigations for all its customers while the vulnerability was leaked before the official release date and we observed attack traffic targeting our customers. We observed how attackers were mutating the attack payload to try to bypass our protections by tracking the volume of matches and cross-referencing with the rule logic.

Protecting against php2shell required more than standard request-based rules. Request data alone does not always provide enough evidence to distinguish an exploit from legitimate traffic. The origin’s response adds context, helping identify whether an exploit succeeded while reducing the risk of false positives.

To deliver this protection, we developed full transaction detection, a new Cloudflare WAF capability that combines signals from the request and response within the same HTTP transaction. Response rules can then block a matching origin response before it reaches the requester. The php2shell protections are the first managed detections we have released using this capability.

Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation. Our security analysts continue monitoring attack activity and update the rules when and if new techniques and variations emerge in the hours and days ahead. You can track new rules in the changelog.

The protections are available and deployed automatically on all plans with WAF deployed, including Free users.

What we know about the vulnerabilities

PHP is used by almost 70% of websites. The php2shell vulnerabilities affect the PHP runtime itself and can allow attackers to execute malicious code on vulnerable servers, expose customer data, or disrupt services. Because PHP underpins widely used platforms such as WordPress and Magento, these flaws could potentially affect a large number of applications across the Internet.

The two vulnerabilities involve how PHP handles memory when something goes wrong while processing a HTTP request. Normally, PHP allocates memory to store the data it needs to process a request, then releases it when that work finishes. If processing stops unexpectedly, for example because it runs out of memory, PHP fails to clean up the memory safely. These vulnerabilities arise when PHP handles an error and then tries to use data that was not fully set up or memory that has already been released.

An attacker can send specially crafted HTTP requests to trigger these conditions. Large requests are one way to put memory under pressure, but the problem goes beyond consuming server resources. By manipulating the data PHP encounters in this invalid memory, an attacker may be able to crash a PHP process, expose sensitive information, or execute code provided by the attacker.

The two vulnerabilities differ in when the unsafe memory access happens:

These flaws are in the PHP runtime, so updating website code or a plugin(s) alone does not fix these vulnerabilities. Administrators need to update the PHP software running their applications. If a hosting provider manages PHP, ask the provider to apply the security update.

Administrators can follow the PHP advisory for affected versions and remediation instructions. Keep Cloudflare WAF protections enabled while patching. Restricting unnecessary uploads and limiting upload sizes can also reduce exposure, but these measures do not replace the PHP fix.

New rules

For Free customers, new rules have been released under the Cloudflare Managed Free Ruleset (Ruleset ID 77454fe2d30c4220b5701f6fdfb893ba). Free customers don’t have to take any actions to enable the protection. To override the ruleset behavior, you can refer to our documentation.

Protection for paid plans has been released as part of the Cloudflare Managed Ruleset (Ruleset ID efb7b8c949ac4650a09736fc376e9aee). If you are on a Professional, Business, or Enterprise plan, review your Managed Ruleset deployment to confirm it has deployed block mode.

To better identify exploit attempts, Cloudflare developed full transaction detection, a new WAF capability that analyzes both sides of the same HTTP transaction. While some malicious payloads can be identified using the request alone, the response contains useful signals that can be used to create rules with higher confidence, reducing false positives. A matching full transaction rule can block the origin response before it reaches the requester. Learn how it works in our full transaction detection blog post.

The new Cloudflare Managed Response Firewall Default has been automatically deployed for customers on all plans, including Free. To verify that the response rules are active, you can visit the Security > Security Rules page. Read the full transaction blog to learn how to customize its deployment.

The new Cloudflare Managed Response Firewall Default detection is protecting your traffic.

Review events and customize protection

To analyze blocked requests, visit Security > Security Analytics > Events. Filter by the rule IDs in the table above and inspect the matched request, action, and path. Events identify whether the action came from a managed or custom rule. Customers who need to tailor the protection can update the scope of the Managed Ruleset to the parts of an application where it is relevant.

Update PHP and keep the protection enabled

Cloudflare customers using our Managed Ruleset are protected by default. We recommend following the advisory recommendation and applying the vendor update to your PHP repos as soon as possible while keeping the WAF protection enabled as an additional protection. Our WAF analysts will continue to update protections as new techniques emerge.

# Security task: check and fix "php2shell" (CVE-2026-109618, CVE-2026-109619)

Two critical PHP runtime vulnerabilities were disclosed on 2026-10-21 (CVSS v4.0 9.2).
They allow unauthenticated remote code execution, data exposure and DoS through crafted
HTTP requests. Exploitation is already happening. The bug is in the PHP runtime itself,
so updating app code, frameworks, WordPress or plugins does NOT fix it.

Official advisory (treat as source of truth, re-fetch it in case it was updated):
https://www.php.net/archive/2026.php#2026-10-21-5
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618, RCE via OOM corruption)
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, RCE via stale global state)

**Fixed upstream versions:** 8.5.12, 8.4.27, 8.3.36, 8.2.35
**Affected:** every PHP install that serves web requests (PHP-FPM, Apache mod_php,
php-cgi, FrankenPHP, LiteSpeed). mod_php has the highest risk: a demonstrated exploit
triggers before any application code runs.

## Rules
- Do NOT guess. If you can't confirm a version or setting, say so.
- Ask me before changing anything on production or shared infrastructure,
  restarting production services, or editing deploy config. Read-only discovery is fine.
- Don't stop at the first finding. Inventory everything, then report.

## Step 1: Inventory every place PHP runs
Search the current repo/workspace AND any machines/containers I have access to:
- Repo: `*.php`, `composer.json`/`composer.lock` (check `require.php` and
  `config.platform.php`), `Dockerfile*`, `docker-compose*`, `.php-version`,
  `.tool-versions`, `.devcontainer/`, CI files (GitHub Actions `setup-php`, GitLab CI
  `image:`), IaC (Terraform, Ansible, Helm, k8s manifests), PaaS config
  (`app.yaml`, `Procfile`, Platform.sh, Laravel Forge/Vapor, etc.).
- Base images: list every `FROM php:*`, `FROM wordpress:*`, `FROM bitnami/*`,
  `FROM serversideup/*`, `FROM dunglas/frankenphp*` and similar, with tags.
- Running hosts/containers (if accessible): `php -v`, `php-fpm -v`, `php -i | grep -i "server api"`,
  `apachectl -M | grep -i php`, `docker ps` + `docker exec <c> php -v`.
- Note the SAPI for each (FPM / mod_php / CGI / FrankenPHP / LiteSpeed / CLI-only).
- Note long-running workers (Laravel Octane, RoadRunner, Swoole, FrankenPHP worker
  mode). These are relevant to the stale-state bug.

If no PHP is found anywhere, tell me clearly and stop. Nothing else is needed.

## Step 2: Decide if each instance is vulnerable
For each instance, classify it as PATCHED / VULNERABLE / UNKNOWN:
- Upstream builds: vulnerable if below 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 on that branch.
- **PHP 8.1 and older are EOL upstream:** vulnerable unless a vendor backport is confirmed.
- **Distro packages (Debian/Ubuntu/RHEL/Alpine/etc.)** often backport fixes WITHOUT
  bumping the upstream version, so `php -v` alone isn't enough. Check the package
  changelog for the CVE IDs, e.g.
  `apt changelog <php-pkg> | grep -E "CVE-2026-10961[89]"` or
  `rpm -q --changelog <php-pkg> | grep -E "CVE-2026-10961[89]"`.
- If PHP comes from `rpms.remirepo.net`: the advisory says it will not have same-day
  updates. Flag this and recommend distro packages or building from source.
- Managed hosting / shared hosting / PaaS: mark UNKNOWN and tell me to ask the provider.

## Step 3: Fix (only after I approve the plan for prod)
1. Upgrade PHP to a fixed version (or the vendor-patched package):
   - Bump Docker base image tags to a fixed patch release, rebuild, redeploy.
   - Update CI `php-version` pins.
   - `apt`/`dnf`/`apk` upgrade of the distro PHP packages.
   - 7.4 / 8.0 / 8.1 built from source: the PHP security team published minimal
     backport branches linked from the advisory. Otherwise upgrade to a supported version.
2. **Restart EVERY PHP worker** (FPM pools, Apache, FrankenPHP, LiteSpeed, Octane/
   RoadRunner/Swoole). Old processes keep running vulnerable code until restarted.
3. Verify each instance afterwards (version + changelog check) and report the evidence.

## Step 4: Temporary mitigations (ONLY if patching isn't possible right away)
These reduce exposure but do NOT make the server safe. Apply them in php.ini / the FPM
pool / server config (not `ini_set()` or `.user.ini`) and restart every worker:
- CVE-2026-109618:
  - `memory_limit=-1`, set non-overridably (e.g. `php_admin_value`), and confirm nothing
    re-applies a finite limit.
  - Low `post_max_size` (8M with no uploads, 32M with uploads), with
    `upload_max_filesize` below it.
  - Enforce request size / field count / multipart part count / header limits at the
    web server or proxy, including requests without `Content-Length`.
  - Use container/cgroup memory limits. Do NOT use `RLIMIT_AS`/`RLIMIT_DATA`.
- CVE-2026-109619:
  - `session.upload_progress.enabled=0`.
  - On PHP 8.5: `fatal_error_backtraces=0`.
  - Remove invalid/deprecated per-request settings that emit diagnostics early (hiding
    them via `error_reporting`/`display_errors`/`@` does not help).
  - Fix attacker-reachable fatal errors and timeouts.
- If the site sits behind Cloudflare: confirm the WAF Managed Ruleset is deployed in
  **block** mode (Free plans get the Managed Free Ruleset automatically). This is
  defense in depth, not a replacement for patching.

## Step 5: Look for signs of compromise (read-only)
Since exploitation started before disclosure, check what you can access:
- PHP-FPM/Apache error logs for segfaults, "Allowed memory size exhausted", or
  worker crashes, especially clustered around unusually large POST/multipart requests.
- Recently modified or unexpected files in web roots (webshells), new cron jobs,
  unexpected processes or outbound connections from PHP users.
Report anything suspicious. Do not delete evidence.

## Final report
Give me a table: location | how PHP is provided | SAPI | version | status
(PATCHED/VULNERABLE/UNKNOWN) | action taken or needed. Then list:
- What you changed (files, commands), what still needs my approval, and anything that
  needs a hosting provider.
- Mitigations applied as stopgaps and when they should be removed.
- Any compromise indicators found.