PHP Security Update: Patches Released for CVE-2026-109618 and CVE-2026-109619

Updated October 21, 2026 | Information checked through 7:04 p.m. EDT / 23:04 UTC

PHP has released security updates for CVE-2026-109618 and CVE-2026-109619. Both are rated critical, CVSS v4.0 9.2, and can allow attackers to execute code without authentication. PHP is urging users to update immediately. ^1, 2, 3

This update follows our October 20 notice. Official technical advisories, researcher demonstrations and corrected PHP releases are now available. Organizations should update the PHP runtime and verify that the fixed build is serving their websites. ^{1, 4, 5, 6}

What the vulnerabilities affect

These are flaws in the PHP runtime. PHP identifies web-serving installations using Apache with mod_php, PHP-FPM, CGI, FrankenPHP and LiteSpeed as at risk. It considers mod_php the highest-risk configuration, with demonstrated exploitation before application code runs. ¹

Wiz traces at least one vulnerable path back to PHP 5.4 and reports demonstrations against WordPress, Drupal and Joomla. It also demonstrated disclosure of PHP worker memory that could contain passwords, tokens and API keys, without first achieving code execution. These are research demonstrations, not a list of compromised organizations. ⁵

Successful code execution runs with the web worker’s privileges. The consequences depend on the files, credentials and services that account can access. Cloudflare also identifies service disruption and data exposure as potential impacts. ^7, 8

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

PHP can interrupt a request when a memory allocation fails. If that interruption occurs while internal data is partly initialized, request cleanup can use unfinished data as though it were valid. An attacker can turn the resulting memory corruption into code execution. ²

Exhausting all server RAM is unnecessary: reaching PHP’s configured per-request memory limit can trigger the failure. ⁶

With Apache mod_php, crafted request data can trigger this during startup, before the website’s PHP code executes. PHP-FPM terminates workers after startup failure, changing the attack conditions. ⁹

FPM evidence requires a qualification: the detailed OOM advisory says no complete FPM exploit has been demonstrated for that path; the PHP Foundation’s release account separately reports FPM code execution through application-level paths. The published accounts are not fully aligned. Neither supports excluding FPM from patching. ^9, 10

The patch changes memory-exhaustion handling so cleanup does not continue through partially initialized state. ⁹

CVE-2026-109619: freed memory reused across requests

A PHP worker can retain internal references after the request’s memory has been freed. A later request handled by that worker can use those references before initialization replaces them. This is a use-after-free: PHP accesses memory that no longer belongs to the original operation. ³

The advisory documents a PHP 8.5 fatal-error backtrace path and a session upload-progress path. It confirms code execution with mod_php and an application-dependent session path with PHP-FPM. The demonstrated cross-request paths require requests to reach the same worker. ⁷

The fix resets request-owned internal state across request boundaries. Disabling upload progress addresses particular paths; it does not cover every affected state or extension. ⁷

Active exploitation: what is verified

Cloudflare reports observing attack traffic targeting its customers and changes to payloads intended to evade its protections. This establishes reported exploitation attempts. Its public article does not provide a verified count of successfully compromised servers. ⁸

watchTowr also reports active exploitation attempts against both CVEs. Its October 21 briefing explicitly describes attempts. This supports treating exploitation attempts as observed activity, without claiming that every attempt succeeded. ¹¹

Unit 42 reports seeing a proof of concept. Its live threat brief, checked at the time of this update, does not identify a confirmed successful compromise. ¹²

The reviewed public reports do not establish a reliable count of successfully compromised organizations or a named campaign responsible for those compromises. Research demonstrations and intercepted attack requests must be distinguished from confirmed intrusions. ^{5, 6, 8, 11, 12}

What was disclosed before release

The PHP Foundation says the CVE identifiers appeared on forums and social media around 15:00 UTC on October 20, accompanied by an incorrect CVSS score of 10.0. It says technical details were absent from that initial disclosure. Around 20:00 UTC, Calif mistakenly published a demonstration video; copies circulated after its removal. PHP brought the planned October 22 release forward to October 21. ¹⁰

The Foundation also reports that Chainguard published patched images before the coordinated release. It says privately supplied mitigation advice may have leaked; that part of its account remains unconfirmed. ¹⁰

Which versions to install

The same fixed releases address both CVEs. ^2, 3

Distribution packages must be checked against the distributor’s complete package version. A backported fix can retain an older upstream version number. Ubuntu’s security notice and Debian’s announcement identify the following corrected builds. These are distribution-specific packages, not interchangeable upstream downloads. ^13, 14

Ubuntu lists corrected Apache-module, CGI, CLI and FPM packages in USN-8948-1. Debian recommends upgrading its php8.4 packages. ^13, 14

PHP 8.1 and older are outside normal upstream support. Some distributors provide backports. PHP has also supplied minimal source backports for 7.4, 8.0 and 8.1 for operators without an LTS provider or who build from source. These exceptional patches do not restore ongoing upstream support. ¹

Ubuntu’s additional notice, USN-8948-2, lists fixes for older supported subscription channels. For example, Ubuntu 20.04’s PHP 7.4 fix is 7.4.3-4ubuntu2.29+esm5 through Ubuntu Pro. The notice also covers Ubuntu 18.04 and Legacy Support updates for 16.04 and 14.04. Availability depends on the applicable subscription and enabled repositories. ¹⁵

How to apply and verify the updates

Updating WordPress, a plugin or another PHP application alone does not replace the vulnerable PHP runtime. Managed-hosting customers should ask their provider to confirm the corrected PHP build serving each site. ⁸

AHCTS recommends the following deployment sequence:

1. Identify every runtime. Record the PHP version, package source and web handler for each site, FPM pool, server and container. Include additional PHP versions installed by hosting panels. Match the update to the runtime serving the application.
2. Prepare recovery and application checks. Preserve configuration and recoverable backups. Identify critical login, transaction, upload and background-job functions to test during the update.
3. Install the corrected packages or build. Use the applicable vendor channel and update installed PHP components and extensions together. For source builds, deploy the corrected release with the required extensions and configuration. For managed platforms and appliances, follow the vendor’s release instructions.
4. Replace the running processes. Restart each affected PHP-FPM service, Apache instance using mod_php, or other PHP worker service. For containers, replace the running containers with the corrected image. Confirm old workers have exited.
5. Verify the served application. Check the complete package/build version and the PHP runtime used by each site, then run the application checks. Record the deployed version, restart or replacement time, and outcome.

PHP can load different configuration files for different server interfaces. php -v and php --ini inspect the command-line installation; they are useful inventory checks but do not establish which runtime a web request reaches. Verify the web runtime through a controlled administrative check, and remove any temporary diagnostic page afterward. ¹⁶

For Ubuntu installations using Canonical’s packages, the documented system-update process is shown below. Review the proposed changes: apt upgrade can update other installed packages as well. Confirm that the relevant PHP packages reach the corrected versions in USN-8948-1, then complete the worker restart and application verification. ^13, 17

sudo apt update
sudo apt upgrade

For Docker deployments, obtain a base or application image containing the fix, update any pinned digest, rebuild your image and redeploy it. Docker documents --pull for refreshing a base image and --no-cache for rebuilding layers. Restarting a container from the same vulnerable image does not install a patch. Verify the PHP build in the replacement workload. ¹⁸

Temporary controls have limits

PHP states that updating is the only complete remedy. The following vendor-documented measures reduce particular attack paths and must not be recorded as equivalent to patching. ¹

• Session upload progress: set session.upload_progress.enabled=0 in startup configuration and restart every worker. The setting must apply before request parsing; application ini_set() and FPM .user.ini are insufficient here. Other stale-state paths remain. ^1, 7
• PHP 8.5 fatal backtraces: fatal_error_backtraces=0, followed by a worker restart, blocks the confirmed backtrace path only. ⁷
• Memory-limit control: PHP documents administratively enforcing memory_limit=-1 as a partial OOM mitigation. This removes PHP’s per-request memory cap and increases memory-exhaustion risk; underlying allocation failures can still trigger the vulnerable path. Separate capacity controls and monitoring are necessary. PHP warns against substituting RLIMIT_AS or RLIMIT_DATA. ^6, 9
• Request restrictions: enforce appropriate decoded-body, multipart, header and nesting limits before requests reach PHP. Where multipart requests are unnecessary, PHP recommends blocking them at the frontend. These controls do not cover every path. ⁹

Cloudflare has deployed WAF protections for free and paid plans. Paid-plan customers should confirm the Managed Ruleset is deployed in block mode. Review matching security events and keep protections enabled while patching. Cloudflare also instructs customers to install PHP updates; a WAF is an additional control, not evidence that the runtime is fixed. ⁸

If a fixed build cannot be deployed promptly, AHCTS recommends restricting access to the affected service or temporarily removing it from public exposure while remediation is arranged.

Community concerns about patch effectiveness

An unverified claim concerns PHP 8.5.12 itself. An October 21 update to a Reddit post in r/IndiaTech alleges that researchers have bypassed the newly patched release. At the time of review, the claim supplied no named researcher, reproduction details, tested configuration or link to supporting analysis. AHCTS has not verified that claim. ¹⁹

Other reporting concerns the limits of temporary workarounds. The Hacker News and TryHackMe explain that disabling session.upload_progress.enabled does not address both vulnerabilities. Both recommend installing the released PHP updates. Their coverage of an incomplete configuration workaround does not establish a bypass of the patched runtime. ^20, 21

GMO Flatt Security’s updated analysis also warns that configuration changes cannot cover every attack scenario and calls them temporary measures. It recommends the official fixed releases. This supports the distinction between reducing exposure through settings and correcting the vulnerable PHP code. ²²

Deployment gaps are also being discussed. Comments in r/selfhosted warn that updating a host does not update a separate container’s PHP installation, and that downloading a new image does not replace an existing container. Those comments concern whether the fix is running; they do not demonstrate exploitation of a corrected build. ²³

In the public sources reviewed through the time stated above, AHCTS did not identify a reproducible bypass of the released fixes or a PHP acknowledgement of an incomplete patch. PHP’s notice continues to identify 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as the corrected releases and recommends immediate updating. This is a review of published evidence, not independent exploit testing. ¹

AHCTS recommends completing patch deployment, verifying every serving runtime and retaining investigation records. We will update this notice if a documented bypass, vendor correction or revised release changes the remediation guidance.

Check for compromise as well as patching

Wiz identifies unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, malformed or unusually large PHPSESSID response cookies, and unexplained PHP worker turnover as investigation leads. Application logs may provide limited context because some vulnerable paths run below the application layer. ⁵

Huntress recommends examining unexpected child processes started by PHP or web-server workers, including shells, other interpreters and download utilities. These are general suspicious behaviors, not proof of exploitation of either CVE. Its cited example of earlier PHP abuse was explicitly unrelated to PHP2Shell. ²⁴

AHCTS recommends preserving proxy, web-server, PHP and endpoint records; investigating unexpected executable files, outbound connections and account activity; and isolating systems where compromise is suspected. Patching prevents the corrected flaws from being used again, but it does not remove an attacker’s existing access. If credentials or secrets were exposed, contain the intrusion and replace them from a trusted environment.

AHCTS will publish further updates as verified information becomes available about exploitation, affected products or remediation.