CVE-2026-109618 / -109619 – Critical PHP RCE

What is behind it?

CVE-2026-109618 — OOM-Corruption

When an out-of-memory error occurs, vulnerable PHP uses longjmp() to leave the current context. If request data is only partially initialized at that point, shutdown may later read invalid data or interpret it as valid structures.

Request size and internal memory use are different quantities. Numerous multipart headers or nested fields can consume substantially more memory than their size on the wire suggests. A small post_max_size alone therefore does not establish protection.

The patch changes OOM handling: a delayed soft OOM at a safe VM point, or immediate process termination at a higher threshold, avoids the unsafe return through cleanup.

Details: GHSA-w8hw-w9fx-j79w — RCE via OOM corruption.

CVE-2026-109619 — Use-after-free

PHP workers typically process multiple requests in sequence. Globally reachable state must never keep pointing to memory belonging to a completed request. This boundary is violated here: stale references can remain after request memory has been freed.

This is a use-after-free. Exploitation requires both an operation that leaves stale state behind and a subsequent operation that consumes it. Upload progress is one confirmed path; diagnostics during early initialization are another. PHP 8.5 also has a relevant fatal-error-backtrace path.

Adding workers or recycling them does not turn a vulnerable installation into a patched one. These choices can affect the conditions of an attack chain, but do not remove the underlying bug.

Details: GHSA-6wmf-4rv5-p3rp — RCE via stale global state.

Am I affected?

The PHP project lists PHP-FPM, Apache with mod_php, CGI, FrankenPHP and LiteSpeed as web deployments that need attention. The specific attack paths differ.

Code initially executes with the web worker’s privileges. Whether this exposes other tenants, secrets or the host depends on file permissions, mounts, process isolation and reachable services. PHP RCE therefore does not automatically imply root access. Tenant isolation nevertheless remains central to the risk assessment in shared hosting.

Attack-path distinctions: GHSA-w8hw-w9fx-j79w — RCE via OOM corruption and GHSA-6wmf-4rv5-p3rp — RCE via stale global state.

PHP 8.1 and earlier no longer receive regular project releases. Minimal source backports for 7.4, 8.0 and 8.1 help package builders, but do not extend regular support. Such installations require verifiable evidence from their package vendor or a migration.

For distribution-maintained packages, check the complete package version. Ubuntu 24.04 LTS provides the fix as 8.3.6-0ubuntu0.24.04.13, for example; Debian 13 uses 8.4.27-1~deb13u1. Comparing only the upstream version number is therefore insufficient.

Package evidence: Ubuntu USN-8948-1 and Debian DSA-6574-1 — php8.4; upstream: PHP Security Advisory — 21 October 2026.

Quick system checks

The following commands read local version, configuration and process information. The examples use rg (ripgrep); package queries apply to Debian/Ubuntu.

# CLI version and loaded configuration
php -v
php --ini

# Settings for this CLI binary
php -r 'foreach ([
    "memory_limit",
    "post_max_size",
    "session.upload_progress.enabled",
    "fatal_error_backtraces"
] as $key) {
    printf("%s=%s\n", $key, var_export(ini_get($key), true));
}'

# Running web workers and start times
ps -eo user,pid,lstart,args | rg '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd'

# Complete package versions (Debian/Ubuntu)
dpkg-query -W -f='${Package} ${Version}\n' \
  'php*' 'libapache2-mod-php*' 2>/dev/null

Document each virtual host’s mapping to its socket, FPM pool or container. With Plesk, also account for handlers under /opt/plesk/php/. Check the effective web context through an internally restricted diagnostic route; a public phpinfo() page would unnecessarily expose configuration details.

Immediate action: update PHP

The permanent fix is updating the PHP installation actually serving requests. This includes separate handlers, FPM pools, containers and older runtimes.

1. Check the mapping: Which binary, pool or image serves each website?
2. Install a patched build: Use an upstream security release or a backport documented by the package vendor.
3. Replace workers: Restart affected FPM services or Apache; recreate container services using the corrected image.
4. Verify the result: Check package versions, running processes and web handlers, then test application functionality.

Environment-specific instructions

These commands are examples for the stated package source and deployment model. Running them on your system may briefly interrupt service. Establish compatibility and recoverability first. If the candidate version does not contain the fix, a successful upgrade does not establish protection.

# Refresh package lists and inspect the candidate version
sudo apt update
apt-cache policy php8.4-fpm php8.4-cli php8.4-common

# Upgrade installed packages (do not install missing packages)
sudo apt install --only-upgrade php8.4-fpm php8.4-cli php8.4-common

# Replace FPM workers
sudo systemctl restart php8.4-fpm
systemctl status php8.4-fpm --no-pager

# Example: Ubuntu packages with FPM
sudo apt update
apt-cache policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

# Check installed package versions
dpkg-query -W -f='${Package} ${Version}\n' php8.3-fpm php8.3-common

# Example: inspect a separate Plesk binary
/opt/plesk/php/8.3/bin/php -v

# Inventory system FPM services
systemctl list-units --all --type=service | rg 'php.*fpm|plesk.*fpm'

# Inspect the current service and image
docker compose -f compose.yml ps
docker compose -f compose.yml images

# Pull the corrected image and recreate only the PHP service
docker compose -f compose.yml pull php-web
docker compose -f compose.yml up -d --no-deps --force-recreate php-web

# Check the binary inside the new instance
docker compose -f compose.yml exec php-web php -v

Temporary measures before patching

If immediate patching is impossible, exposure to individual paths can be reduced. PHP specifies the following for the confirmed session paths:

; Apply before request parsing, then restart every worker
session.upload_progress.enabled = 0
; Additionally, for PHP 8.5
fatal_error_backtraces = 0

Use php.ini or suitable server/FPM-pool settings. Application-level ini_set() and FPM .user.ini settings take effect too late for these early paths.

For the OOM path, PHP also describes administratively enforcing memory_limit=-1. This removes the controllable PHP memory ceiling, but underlying allocation failures remain possible. It also removes a normal limit on memory consumption, requiring deliberate consideration of isolation and availability.

Bound request size, field counts, multipart parts, headers and nesting at the frontend. Container/cgroup limits may provide an availability boundary; PHP advises against using RLIMIT_AS or RLIMIT_DATA as substitutes because these can trigger the vulnerable allocation failure.

Measures and limitations: PHP Security Advisory — 21 October 2026 and CERT-EU Security Advisory 2026-018.

After the PHP update

After rollout, it should be clear which corrected build serves each website. Verify four things separately:

• Package or image: Match the complete version or digest against the vendor advisory.
• Running processes: Check start times; old workers must no longer process requests.
• Web context: Verify the actual handler and effective configuration through an internally restricted diagnostic route.
• Application: Test logins, uploads, background jobs and typical requests.

# Example after restarting FPM
systemctl show php8.3-fpm -p ActiveEnterTimestamp -p MainPID
ps -eo user,pid,lstart,args | rg '[p]hp-fpm|[a]pache2|[h]ttpd'

Only restore temporary settings to the intended operating values after confirming patch coverage. This especially applies to a temporarily disabled memory_limit. Update old images retained for rollback and scaling too.

Threat assessment and incident response

Demonstrated technical exploitability, a public exploit concept and confirmed production compromises are distinct claims. This article does not infer a count of compromised systems from an exploit demonstration.

During investigation, correlate OOM events, worker crashes and suspicious multipart requests with new files, child processes or outbound connections. Individual errors do not prove an attack; quiet logs do not prove integrity either. If there is concrete suspicion, preserve artifacts and initiate incident response. Updating closes the vulnerability but does not remove persistence already established by an attacker.

Sources & further reading

As of October 21, 2026. For subsequent updates, consult current vendor advisories and complete package versions.

• PHP Security Advisory — 21 October 2026
• GHSA-w8hw-w9fx-j79w — RCE via OOM corruption
• GHSA-6wmf-4rv5-p3rp — RCE via stale global state
• Ubuntu USN-8948-1
• Debian DSA-6574-1 — php8.4
• CERT-EU Security Advisory 2026-018