Cloudflare 即時部署 php2shell 漏洞防護

更新 - 10 月 23 日，PHP 專案發布了一份 資訊通告，針對 PHP 會話上傳進度功能中的相關漏洞 CVE-2026-115560。此漏洞影響已完整修補的 PHP 版本，包括 8.5.12，將在 PHP 下一個正式版本中修復。

所有使用 Cloudflare WAF 的客戶，只要其網站使用 PHP 的預設上傳進度欄位名稱，即可防護已知的利用嘗試。改變 session.upload_progress.name 的客戶則不在此 WAF 規則覆蓋範圍內。

現有規則「PHP 遠端程式碼執行攻擊 (CVE-2026-109618, CVE-2026-109619) #6」可防護此漏洞。

將提供更多資訊。

10 月 21 日，Calif.io、Wiz、OpenAI 與 Quarkslab 公佈了兩項 PHP 漏洞，分別以 CVE-2026-109618 與 CVE-2026-109619 追蹤，亦稱為 php2shell。此漏洞影響所有執行 PHP 5.4 或更新版本的網頁伺服器，攻擊者可利用之在應用程式處理特殊設計的 HTTP 流量時，造成拒絕服務、遠端程式碼執行及資料外洩。

Cloudflare 已參與協調部署緩解措施以保護網際網路，與 PHP 基金會、OpenAI 及 Wiz 等合作。自 2026 年 10 月初起，Cloudflare 已開發並部署 Web 應用程式防火牆 (WAF) 防護，且比公開披露提前約 9 小時部署。自 10 月 21 日 3:02 UTC 起，使用我們免費或付費 WAF 的 Cloudflare 客戶預設已受到 php2shell 的保護。

在漏洞在官方發布前即被洩露期間，Cloudflare 成功為所有客戶部署多項緩解措施，我們亦觀察到針對客戶的攻擊流量。透過追蹤匹配數量並與規則邏輯交叉比對，我們發現攻擊者正在變異攻擊載荷以嘗試繞過我們的防護。

對抗 php2shell 需要超越標準的基於請求的規則。單靠請求資料並不總能提供足夠證據來區分惡意利用與合法流量。來源的回應提供額外上下文，協助判斷利用是否成功，同時降低誤報風險。

為實現此防護，我們開發了完整交易偵測（full transaction detection）— Cloudflare WAF 的新功能，將同一 HTTP 交易中的請求與回應訊號結合。回應規則可在回應到達請求者之前阻擋符合條件的來源回應。php2shell 的防護是我們首次使用此功能發布的受管偵測。

即使已啟用 WAF 防護，客戶仍應修補其 PHP 版本；WAF 只提供額外的深度防禦層。安全分析師將持續監控攻擊活動，並在未來數小時或數天內若出現新技術或變種時更新規則。您可在 變更日誌 中追蹤新規則。

此防護已於所有已部署 WAF 的方案中自動提供，包括免費使用者。

我們對漏洞的瞭解

PHP 被約 70% 的網站 使用。php2shell 漏洞影響 PHP 執行環境本身，可能讓攻擊者在易受攻擊的伺服器上執行惡意程式碼、洩露客戶資料或中斷服務。由於 PHP 為 WordPress、Magento 等廣泛使用的平臺底層，這些缺陷可能會影響網際網路上大量應用程式。

這兩個漏洞涉及 PHP 在處理 HTTP 請求時出錯時的記憶體處理方式。通常 PHP 會分配記憶體來儲存處理請求所需的資料，完成後再釋放。若處理意外停止，例如因記憶體不足，PHP 會無法安全清理記憶體。這些漏洞在 PHP 處理錯誤後，仍嘗試使用尚未完全設定的資料或已被釋放的記憶體時產生。

攻擊者可傳送特製的 HTTP 請求以觸發這些條件。大型請求只是讓記憶體承受壓力的一種方式，問題不僅僅是消耗伺服器資源。透過操縱 PHP 在這段無效記憶體中遇到的資料，攻擊者可能能夠使 PHP 程式崩潰、洩露敏感資訊，或執行攻擊者提供的程式碼。

這兩個漏洞在不安全的記憶體存取發生時機上不同：

這些缺陷位於 PHP 執行環境中，僅更新網站程式碼或外掛無法修復這些漏洞。管理員需要更新執行其應用程式的 PHP 軟體。若主機商管理 PHP，請要求其套用安全更新。

管理員可參照 PHP 針對受影響版本的公告及修復說明。在修補期間，保持 Cloudflare WAF 防護啟用。限制不必要的上傳並限制上傳大小亦能降低風險，但這些措施並不能取代 PHP 修復。

新規則

對於 Free 客戶，已在 Cloudflare Managed Free Ruleset（規則集 ID 77454fe2d30c4220b5701f6fdfb893ba）下發布新規則。Free 客戶不必採取任何操作即可啟用保護。若要覆寫規則集行為，可參考我們的 檔案。

付費方案的保護已作為 Cloudflare Managed Ruleset（Ruleset ID efb7b8c949ac4650a09736fc376e9aee）的一部分發布。 若您使用 Professional、Business 或 Enterprise 方案，請檢閱 Managed Ruleset 部署以確認它已 已部署 阻擋模式。

為了更精確辨識利用企圖，Cloudflare 開發了完整交易偵測，這是一項新的 WAF 能力，可同時分析同一 HTTP 交易的雙方。雖然僅憑請求就能辨識部分惡意載荷，但回應中包含有用訊號，可用來建立更高信心的規則，降低誤報。相符的完整交易規則可在原始回應抵達請求者前阻擋它。瞭解其運作方式，請參閱我們的完整交易偵測部落格文章。

新的 Cloudflare Managed Response Firewall Default 已自動部署於所有方案，包括免費方案。為確認回應規則已啟用，您可前往 安全 > 安全規則 頁面。閱讀完整交易部落格以瞭解如何自訂其部署。

檢閱事件並自訂保護

為分析已阻擋的請求，請前往 安全 > 安全分析 > 事件。依照上表中的規則 ID 過濾並檢查符合的請求、動作與路徑。事件可識別動作是來自管理規則還是自訂規則。需要調整保護的客戶可 更新範圍 以符合其應用程式相關部分。

更新 PHP 並保持保護啟用

使用我們 Managed Ruleset 的 Cloudflare 客戶預設已受到保護。我們建議遵循 建議，盡快將供應商更新套用於您的 PHP 版本，並保持 WAF 保護啟用作為額外防護。我們的 WAF 分析師將持續更新保護措施以應對新興技術。

複製提示以修復！

# 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.