PHP released security updates on 21 October 2026 for two critical vulnerabilities that can allow unauthenticated remote code execution. Both are rated CVSS 9.2. PHP advises treating all installations serving web requests as at risk and updating immediately.

Cloudflare has observed attack traffic and attempts to modify payloads to bypass its protections. Prioritize internet-facing PHP systems now.

What is affected

The vulnerabilities affect the PHP runtime itself, including deployments using PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

PHP identifies mod_php as the highest-risk deployment, with demonstrated exploitation before application code executes. Updating a CMS, application, or plugin does not patch the underlying interpreter. Exploitability varies by configuration, but other deployment modes should not be assumed safe.

Include hosted websites, staging systems, vendor portals, containers, and appliances with PHP-based management interfaces in your review.

The vulnerabilities

CVE-2026-109618: Memory corruption during out-of-memory handling

An allocation failure can interrupt request processing while internal data is only partly initialized. Request cleanup may then use that invalid state, enabling remote code execution.

CVE-2026-109619: Stale state between requests

A worker can retain references to memory released after an earlier request. A subsequent request may access that stale state before initialization resets it, creating a use-after-free condition. The precise attack paths depend on PHP version and configuration.

Fixed versions

Check your distribution or hosting provider for patched packages. Vendor packages may contain backported fixes without matching these upstream version numbers.

PHP 8.1 and earlier are unsupported upstream. Minimal source backports are available for 7.4, 8.0, and 8.1, but upgrading to a supported branch remains the preferred path. PHP 8.2 reaches end of security support on 31 December 2026.

What to do now

1. Identify PHP deployments, starting with internet-facing systems and administrative interfaces.
2. Apply the runtime update or a vendor-confirmed backport.
3. Restart the affected services and recycle every worker, then verify the running version.
4. Remove vulnerable services from exposure if patching cannot be completed promptly. Taking systems offline until updated is consistent with NSA advice.
5. Confirm completion with hosting and appliance providers, including the package installed and when services restarted.

Verify the PHP runtime actually serving requests

Check php -v, but also identify the PHP-FPM binary, Apache module, container image, or other runtime handling web traffic. The command-line version may be different.

Review the configuration and FPM pools those services actually load. Response headers can provide clues, but missing or hidden version information does not establish that a system is patched. Avoid exposing a public phpinfo() page or sending exploit requests to production systems.

Temporary measures

Configuration changes reduce specific attack paths. They do not replace patching.

PHP recommends the following interim measures while updates are being applied:

• For the out-of-memory path, set memory_limit=-1 through an administrative setting that applications cannot override. Pair this with suitable container or cgroup memory controls. Underlying allocation failures remain a risk.
• Keep post_max_size low: PHP suggests 8M where uploads are unnecessary or 32M where needed, with upload_max_filesize below it. Apply appropriate request limits at the proxy or web server as well.
• Do not substitute RLIMIT_AS or RLIMIT_DATA, which can trigger vulnerable allocation failures.

For the confirmed stale-state paths:

session.upload_progress.enabled = 0

Apply this before request parsing through php.ini or appropriate server configuration, then restart every worker. Do not rely on application-level ini_set() or FPM .user.ini.

On PHP 8.5, also set:

fatal_error_backtraces = 0

These settings block specific confirmed paths only. Review invalid or deprecated configuration and attacker-reachable fatal errors. Hiding diagnostics does not prevent the underlying condition.

Hunt for suspicious activity

Review available telemetry from 20 October onward, extending the window where findings warrant it. Look for:

• PHP or web server processes spawning unexpected shells, interpreters, or download tools.
• Reverse-shell patterns such as /dev/tcp/ or unusual mkfifo execution.
• Unexpected reconnaissance commands running as the web server account.
• New or modified web files, particularly in writable directories.
• New persistence through cron, systemd services, scheduled tasks, or accounts.
• Unusual outbound connections from affected servers.

These are investigation leads, not proof of exploitation individually. Correlate process, network, file, authentication, and web logs.

If compromise is suspected, isolate the host and preserve evidence before cleanup. Patching prevents further exploitation of these flaws; it does not remove an attacker already present.

Use WAF protection alongside patching

Cloudflare has deployed protections across free and paid plans. Paid-plan customers should confirm the relevant managed ruleset deployment uses block mode and review matching events in Security Analytics.

Keep protection enabled while patching, but do not treat blocked requests as evidence that the origin is safe. Cloudflare explicitly recommends updating PHP despite its WAF coverage.

What ThreatDefence is doing

Our SOC is hunting across monitored environments for suspicious web server child processes, reverse-shell behavior, and other post-exploitation activity.

We can also review your internet-facing estate for identifiable PHP exposure. External findings should be combined with host, package, and provider checks to confirm patch status.