Emergency PHP Patch Oct 21, 2026: Two 9.2 RCE Vulnerabilities CVE-2026-109618 & 109619

On October 21, 2026, the PHP security team released emergency updates 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to address two unauthenticated remote code execution (RCE) vulnerabilities: CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Every organization running websites, APIs, e-commerce platforms, or management systems on PHP must update their PHP runtime and restart backend processing workers immediately, as these flaws reside in PHP core and cannot be mitigated by patching application code.

Earlier on October 20, 2026, the PHP security team issued a pre-release notification (scheduled for 14:00 UTC on October 21) so system administrators and infrastructure providers could prepare. In the official announcement on October 21, 2026, PHP underscored: "All PHP users are strongly encouraged to update immediately." This article summarizes the verified technical details so founders, business owners, and engineering teams can audit and protect their systems today.

What Are CVE-2026-109618 and CVE-2026-109619?#

Unauthenticated Remote Code Execution (RCE) is a class of vulnerability that allows a remote attacker to execute arbitrary code on the target server without requiring prior authentication or valid credentials.

From an operational standpoint, when an RCE flaw exists directly inside the PHP interpreter, every application-level security layer (such as Laravel authentication middleware, WordPress security plugins, or Magento ACL policies) can be completely bypassed. The attack takes place during PHP's own request handling pipeline, either before or after application code executes.

Below are the technical details of the two vulnerabilities as disclosed by the PHP security team:

1. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — RCE via Out-of-Memory (OOM) Corruption#

This vulnerability occurs during the handling of out-of-memory (OOM) conditions. When PHP terminates due to memory exhaustion while a request's internal data structures are only partially initialized, the subsequent request cleanup routine can misinterpret this incomplete (invalid) data as valid. Through this memory corruption, an attacker can steer the process toward remote code execution.

2. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — RCE via Stale Global State#

The second vulnerability involves memory lifecycle management across requests within the same worker. Specifically, internal state owned by one request can persist after its underlying memory buffer has been freed. When a subsequent request is processed by that same worker, the engine may reuse this stale state before the standard initialization routine resets it.

At present, the official PHP advisory does not indicate whether these vulnerabilities have been exploited in the wild. However, with a CVSS v4.0 score of 9.2 and technical details publicly accessible, delaying updates puts infrastructure at severe risk.

Which Systems Are Affected by the October 21, 2026 PHP Patch?#

All PHP installations serving web requests that run versions lower than the latest patch in each respective release branch are affected. This covers every widely used runtime environment:

• PHP-FPM (the most common architecture when paired with Nginx or Apache)
• Apache with mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Critical Note: PHP rates the risk as highest for Apache running mod_php. The security team confirmed there is a demonstrated exploit where an unauthenticated request triggers the attack before any application code has a chance to execute. Consequently, you cannot protect yourself by updating your framework or deploying PHP-level firewall plugins.

Affected and Patched PHP Versions#

For businesses running retail, F&B, or O2O platforms, payment gateways, POS systems, and CRMs rarely run on a single machine. Quite often, the core application runs in modern containers, but a legacy WordPress landing page, a secondary cron/webhook worker, or an internal portal may still run an outdated PHP build. Audit your entire server fleet.

Immediate Action Checklist for Founders and Engineering Teams#

Follow these five steps in exact order to ensure your environment is fully secured:

1. Verify the PHP and SAPI Version Across All Servers: Check both the CLI and the active runtime serving web requests (PHP-FPM, mod_php, FrankenPHP, LiteSpeed, php-cgi). Do not rely solely on running php -v in the terminal, as the CLI binary and the FPM/Apache module on the same host can differ.
2. Update via Distro Packages or Official Docker Images:
   • Linux Distributions (Ubuntu, Debian, RHEL, etc.): Linux distributions and LTS vendors received early notification from the PHP team. Run your package manager updates. Note: Distro packages often keep the upstream base version number and backport security fixes. Therefore, verify vendor security advisories or the package changelog rather than relying only on php -v.
   • Docker / Containers: Once your base image ships PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, pull it, rebuild and redeploy all running containers, then confirm the PHP version inside the container.
   • Critical Warning for rpms.remirepo.net Users: The volunteer-maintained repository at rpms.remirepo.net will not provide updates on October 21, 2026. PHP recommends that users relying on Remi repo switch immediately to official distribution packages or compile from source.
3. Restart PHP-FPM, Apache, and All Worker Processes: Updating disk packages is insufficient if processes resident in RAM still execute legacy code. Restart php-fpm, apache2/httpd, FrankenPHP, LiteSpeed, and all associated background workers.
4. For Shared or Managed Hosting Environments: If your company uses shared hosting without root access to upgrade PHP, open an urgent support ticket with your provider to confirm when they will apply patches for CVE-2026-109618 and CVE-2026-109619.
5. Post-Update Verification: Confirm the installed package changelog (on Linux distros) or the runtime version loaded by your web server, and check worker process start times to ensure no legacy processes remain running.

Temporary Mitigations if You Cannot Update Today#

The PHP security team stresses that the mitigations below only reduce exposure to specific attack vectors and DO NOT make the system safe. Upgrading PHP remains the only complete remediation. However, if you must wait for a maintenance window, apply the following configurations immediately:

Mitigations for CVE-2026-109618 (OOM Corruption)#

• Set memory_limit=-1 in an unalterable manner that application code cannot override (e.g., using the php_admin_value directive in your FPM pool configuration or Apache config).
• Set post_max_size to a low limit: 8M if your application does not handle file uploads, or 32M if it does; keep upload_max_filesize strictly lower than post_max_size.
• Enforce strict request size limits at the web server or reverse proxy layer.
• Use container-level memory limits or cgroups as the primary resource boundary; DO NOT use RLIMIT_AS or RLIMIT_DATA.

Mitigations for CVE-2026-109619 (Stale Global State)#

• Set session.upload_progress.enabled=0 directly in php.ini, your FPM pool configuration, or server config (do not use ini_set() inside application code and do not configure this via .user.ini), then restart all worker processes.
• If running PHP 8.5, additionally set fatal_error_backtraces=0 and restart workers.
• Identify and patch fatal errors as well as request timeout points that could be externally triggered by an attacker.

Notes for PHP 8.1 and Below, plus PHP 8.2 EOL#

If your systems still run PHP 8.1 or older, these branches no longer receive regular upstream releases from the PHP project. You have two options:

1. Check whether your Linux distribution or commercial LTS provider offers backported security patches for your current PHP packages.
2. If you compile from source, the PHP security team has published minimal source backports for PHP 7.4, 8.0, and 8.1 on GitHub to facilitate emergency patching. Long-term, you must plan an upgrade to an actively supported version.

Additionally, teams running PHP 8.2 should note that PHP 8.2 reaches End of Life (EOL) on December 31, 2026. After completing the emergency upgrade to 8.2.35 today, scheduling an upgrade to PHP 8.3 or 8.4 in your Q4/2026 roadmap is essential to avoid being caught unprepared by future security vulnerabilities.

Source: Official security advisories from php.net and the php-src GitHub repository (GHSA-w8hw-w9fx-j79w / CVE-2026-109618 and GHSA-6wmf-4rv5-p3rp / CVE-2026-109619).