Critical PHP RCE Flaws CVE-2026-109618 and CVE-2026-109619: Patch and Response Guide

Security advisory — October 21, 2026. Two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, have prompted an emergency security release. Both can enable unauthenticated remote code execution under specific circumstances. Administrators should update PHP promptly, verify the version their web workers actually run, and investigate potential compromise where exposure existed. This is a general operational guide based on PHP's official October 21 advisory, not a report about any particular hosting provider or customer.

What happened and why it matters

The PHP team published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to address two critical flaws in request-memory handling. The PHP Foundation explained that these issues can allow an attacker without a login to run code on a server in suitable conditions. Web-facing PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed installations all warrant assessment. The PHP team considers mod_php especially exposed because it has demonstrated an attack that runs before application code starts.

A runtime flaw is different from a bug in a particular WordPress plugin or CMS. An otherwise maintained website can still be affected if its underlying PHP interpreter is vulnerable. Installing the latest CMS update is important but does not patch the interpreter.

The two CVEs explained

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

During an out-of-memory failure, PHP may exit request handling while internal data is incompletely initialised. Cleanup can subsequently interpret invalid internal memory as valid data. The official technical advisory describes multiple paths involving memory pressure and multipart request processing. This is a memory-safety issue inside PHP, not a recommendation to increase a website's upload limits.

CVE-2026-109619: stale global state

Some request-owned state can remain referenced after its backing memory has been freed. A subsequent request handled by the same worker may consume that stale state before ordinary initialization replaces it. This is a use-after-free scenario described in the official advisory. The technical preconditions differ by execution model: do not interpret evidence of particular mod_php paths as a claim that all FPM configurations have identical exploitability.

Fixed versions and unsupported branches

Linux vendors can backport security fixes without replacing the upstream version string. Always consult your distribution's security tracker and package changelog as well as the displayed package version; a simplistic numeric comparison is not sufficient to evaluate vendor-patched packages.

Why patched PHP may not appear in apt immediately

The official upstream release and downstream Linux package publication are separate steps. A distribution or third-party repository must build, test, sign and publish packages suitable for its supported environment. During this lag, a package manager may report that its existing older build is the “newest version” available in that configured repository. That is not proof that the upstream vulnerability has been fixed.

Check the installed and candidate packages without changing anything:

sudo apt update
apt-cache policy php8.3-fpm
apt list --upgradable 2>/dev/null | grep -E '^php'

Adjust the branch to match your environment. A sample result where both Installed and Candidate still show an unpatched upstream version means that repository does not currently offer the patched release. It does not mean that every Linux vendor is behind. Do not assume that changing to another unpatched minor branch solves the issue.

Also avoid blanket wildcard package operations that accidentally select extensions or interpreters never used by your applications. Inventory installed components first, review the transaction with a simulation where practical, and follow the distribution or panel vendor's supported update method.

A safer emergency patch workflow

1. Identify exposure. Inventory internet-facing hosts, PHP branches, SAPI types, workers, pools, containers and scheduled PHP processes.
2. Preserve a recoverable state. Take a snapshot or tested backup and record the installed versions and configuration. Ensure an out-of-band administrative route remains available.
3. Check vendor packages. Confirm that an applicable patched release or verified backport is available from a trusted source.
4. Update one failure domain at a time. Where there are multiple active nodes, plan a rolling rollout, account for session continuity and be ready to revert deployment problems.
5. Restart workers. PHP-FPM, Apache workers or other runtimes must actually load the new binaries; package installation alone does not guarantee all old processes have exited.
6. Verify both code and service. Check installed packages, running processes, app responses, logs and real HTTP requests. Do not expose an unrestricted phpinfo page to the internet.
7. Investigate compromise. Look for unexplained files, webshell indicators, suspicious tasks, unexpected outbound connections, altered service settings and unusual activity; preserve logs and evidence.

For a single PHP-FPM version, read-only checks might include:

php -v
systemctl status php8.3-fpm --no-pager
ps -eo pid,lstart,args | grep '[p]hp-fpm'
dpkg-query -W 'php8.3*' 2>/dev/null

php -v identifies the command-line interpreter and cannot prove which PHP binary the web server or each pool executes. Verify the actual service configuration and web runtime through a secured internal method. If compromise is suspected, isolate affected systems and coordinate incident response before destructive clean-up.

Temporary mitigations: partial risk reduction only

The upstream advisory explicitly says there is no complete workaround. The following options address documented paths but introduce trade-offs. They should be assessed by a qualified administrator, in staging where possible, and removed or reevaluated after patching.

For CVE-2026-109619

Disable PHP session upload progress at configuration level with session.upload_progress.enabled=0 and restart all affected workers. This blocks confirmed session-related paths, not other potential variants. On PHP 8.5, disabling fatal_error_backtraces also blocks one confirmed path. Remove invalid or deprecated settings that generate diagnostics before request initialization. Merely hiding those diagnostics is not protective.

For CVE-2026-109618

The advisory discusses removing PHP's finite memory limit using memory_limit=-1, applying low post_max_size values (8 MB for applications without uploads, or 32 MB where uploads are needed), and limiting request complexity and size at the proxy or web server. The memory-limit change creates a substantial availability risk: a request can consume excessive RAM. Consider container or cgroup memory boundaries, performance and operational safeguards before attempting it. The upstream advisory warns against relying on RLIMIT_AS or RLIMIT_DATA as substitutes. Do not apply emergency configuration values indiscriminately across diverse websites.

Old PHP applications and compatibility

Unmaintained PHP 8.1 installations should not be treated as protected merely because a partial workaround has been applied. Migrate to a maintained branch or confirm a supported backport. However, changing a web application from PHP 8.1 to 8.4 or 8.5 during an incident may reveal incompatible extensions, plugins, deprecated language features or application assumptions. Prefer a staged compatibility assessment. In the immediate incident, a fixed update within an existing supported branch generally limits compatibility changes.

WAFs, patching and incident response

A WAF and request-size limits can reduce particular attack opportunities but are not evidence that the runtime is safe. Do not publish detailed exploit traffic or claim that any single WAF rule will block both vulnerabilities. Operators should follow vendor advisories, preserve relevant telemetry and consider protective isolation for critical unpatched services if risk cannot otherwise be controlled.

Automatic security updates also require scrutiny: confirm repository coverage, update policies, excluded packages and whether restarts occur. Monitoring for new packages can shorten response time, but it does not replace a verified rollout.

Frequently asked questions

Is PHP-FPM safe compared with mod_php?

No blanket exemption exists. Upstream identifies greater demonstrated risk for mod_php, but advises all PHP installations serving web traffic to patch.

Does installing PHP 8.5 always solve the problem?

No. The relevant question is whether the build contains the fix. PHP 8.5.11 predates the patch; PHP 8.5.12 includes it.

Should teams publish a phpinfo page to verify the update?

A publicly accessible phpinfo page can disclose configuration and environment details. Prefer internal verification and remove temporary diagnostics immediately.

Can an application update or WAF replace the PHP update?

No. The upstream PHP team describes patching as the only complete remediation for these two vulnerabilities.

References

• PHP official October 21, 2026 security announcement and mitigations.
• CVE-2026-109618 technical advisory.
• CVE-2026-109619 technical advisory.
• PHP Foundation: security release context.