CVE-2026-109618 and CVE-2026-109619: PHP Vulnerability 2026 Explained

Introduction

Two CVE Identifiers, One Critical Assessment Task

Security bulletins list CVE-2026-109618 and CVE-2026-109619 side by side, as if they were one problem. They are not. The PHP security team published them together on 21 October 2026 as two critical PHP vulnerabilities, each with its own advisory, failure mechanism and interim controls. Both are rated 9.2 on CVSS v4.0 and fixed by the same releases. 

Engineering teams still have to decide which systems face which flaw and what proves a fix is live. This article compares the two CVEs using the PHP advisories and vendor bulletins, then covers which runtime serves production, which package carries the fix and what proof to keep. For incident background, see our PHP2Shell security crisis overview.

Start With the Advisory Record: What Each CVE Actually Identifies

CVE-2026-109618 (advisory GHSA-w8hw-w9fx-j79w, titled “RCE via OOM corruption”) covers what happens when a request runs out of memory at the wrong moment. PHP can be interrupted while request data is only partly set up, and cleanup then treats that unfinished data as valid. The confirmed triggers run through multipart request parsing, according to Mattias Geniar’s mitigation analysis. On Apache with mod_php, researchers also triggered it with an ordinary form post. PHP-FPM stops a worker when request startup fails, which closes that startup path, but FPM remains affected in other ways. 

CVE-2026-109619 (advisory GHSA-6wmf-4rv5-p3rp, “RCE via stale global state”) covers state a PHP worker keeps between requests. Error, session, object and extension state can still point at memory that belonged to one request, and a later request on the same worker may use it. The advisory confirms two consumers: session upload progress, which is enabled by default and needs no call to session_start(), and, on PHP 8.5, fatal error backtraces. A warning during initialization can also consume stale error state, including warnings from per-request settings such as php_value lines in .htaccess. Hiding errors does not help.

Both flaws carry the vector AV:N/AC:H/AT:P/PR:N/UI:N. A 9.2 score therefore does not mean trivial exploitation: the vector records high attack complexity and attack requirements that must be present, as the University of Toronto advisory lists it. PHP validated full remote code execution for both, and the same advisory notes that reliability depends on build, extensions and server layout. 

Compare the Failure Conditions, Not Just the CVE Numbers

The table shows what sources establish for each CVE. Where they do not settle a point, the cell says so. 

Four differences matter in practice. First, the controls do not overlap. Memory and request size limits address CVE-2026-109618, while disabling session upload progress addresses one confirmed path for CVE-2026-109619. A team that applies only one set leaves the other CVE open, and PHP says neither set makes an installation safe. 

Second, execution model changes exposure. PHP rates Apache mod_php highest because an unauthenticated request can trigger the attack before any application code runs. All PHP installations serving web requests are in scope, including PHP-FPM, PHP-CGI, FrankenPHP and LiteSpeed. 

Third, end-of-life branches are not equal. AWS says no fix is available for CVE-2026-109618 on end-of-life branches, while interim controls for CVE-2026-109619 may help where effective. Fourth, sources differ on which CVE carries the memory disclosure path, so treat both as capable of exposing worker memory. 

From Runtime Defect to Business Exposure

A vulnerable runtime is not the same as an exposed asset, and neither is a compromised one. Treat exposure as five stages: a vulnerable runtime exists somewhere in the organization; it receives input from an untrusted party; the attacker meets the advisory’s conditions; exploitation succeeds; and evidence confirms an incident. Each stage needs its own evidence. A missing patch proves only the first. 

Public reporting now supports the third stage and part of the fourth, but not the scale of the fifth. Amazon recorded an attempt on 17 October, four days before the fix, and later called the bugs broadly exploited without knowing whether early attempts would have worked. watchTowr observed exploitation on 21 October. CISA said that day it had not observed exploitation, and reports dated 23 October show neither CVE in its Known Exploited Vulnerabilities catalog. The PHP Foundation said the leaked proofs of concept it inspected held no working exploit, and Sansec later argued mass exploitation was less likely than feared, as Geniar summarizes.

Business impact sits in two bands: documented possibilities, namely code execution and worker memory disclosure that may include passwords, tokens and API keys, and confirmed outcomes at specific organizations, which public sources do not establish at scale. Label which band each risk claim belongs to. 

The Production Runtime May Not Match the Version You Checked

A version check answers a narrow question: which PHP did this shell or scan reach? VirusTotal fingerprinted about 5.1 million IP addresses running PHP on 21 October, yet only about 1.1 million announced a version, so roughly four in five hide it. Those counts describe footprint, not confirmed vulnerable hosts, but they show why outside checks miss most servers. 

Inside an organization the mismatch is usually local: the command-line PHP differs from the PHP-FPM pool serving the site, several branches sit side by side, a container image on disk is newer than the container running, and control panels and bundled applications ship their own PHP. WordPress is one application that inherits all of this, as our WordPress-specific analysis explains. 

A short, read-only workflow identifies the runtime that serves one application. The commands below are illustrative: service and package names vary by distribution, so adapt them to your environment. 

• Find the handler: mod_php, a PHP-FPM socket or another server API (SAPI, the interface between PHP and the web server), as the web server configuration shows. 
• Ask the serving binary, not your shell: run the version command of the PHP-FPM binary named in the service unit, or php -v inside the running container. 
• Compare timestamps. A service that started before the package was installed is still running old code. 

systemctl show php8.3-fpm –property=ActiveEnterTimestamp 

rpm -q –qf ‘%{INSTALLTIME:date}\n’ php-fpm # RPM-based systems 

grep ‘ upgrade php8.3-fpm’ /var/log/dpkg.log # Debian-based systems 

• Record both timestamps and the version output with the date, so the check can be repeated. 

Map the Vulnerability to the Right Package and Support Branch

Remediation depends on who builds your PHP, and a version string cannot settle it because vendors can fix a flaw without renumbering. Plesk patched its end-of-life builds with unchanged version numbers and a build date of 21 October 2026, and Meow Apps notes that Ubuntu 24.04’s fixed PHP 8.3 package still carries the 8.3.6 base version with a new revision suffix. 

End-of-life branches need a separate decision. AWS lists PHP 5.4 through 8.1 as having no upstream fix and says migration to a supported branch is required. A vendor backport can change that for your system, but only your vendor can confirm it. This table was last verified on 26 October 2026. 

What Counts as Proof That the Fix Reached Production?

A closed ticket is not proof. Six checks make remediation defensible: 

• The advisory is mapped to the right asset and runtime. 
• The installed build matches a confirmed fixed release, or a vendor fix naming both CVEs. 
• The web-serving runtime uses that build, checked on the running service, not the shell. 
• Workers were restarted after installation, because stale state lives in running workers. 
• Health checks and application smoke tests passed. 
• The result, the date and the responsible owner are recorded. 

Use a record like this for each asset. The entries are illustrative placeholders, not evidence of testing performed by HireDeveloper.dev. 

Keep a separate log review beside the fix record, starting 17 October, when attempts were first recorded. Researchers list unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, oversized PHPSESSID cookies and worker crashes as signals. Amazon adds POST requests containing PHP_SESSION_UPLOAD_PROGRESS. None proves an attack, and their absence proves nothing. 

When a Security Bulletin Does Not Match Your Environment

Bulletins describe products, and you run configurations. When a managed host, custom build or bundled appliance is not clearly covered, ask the vendor in writing which runtime and build serve you and whether both CVEs are fixed. Read the package changelog instead of the version string. Check official notices, including the Dutch NCSC list of products with a PHP dependency. Record remaining uncertainty with an owner and a deadline. 

While uncertainty remains, match controls to exposure and business risk. An internet-facing system holding sensitive data may justify isolation, a multipart block at the web server, or going offline, which the NCSC advises considering when neither the update nor mitigations can be applied quickly. A low-exposure internal system may justify extra monitoring.

Treat none of these as equal to the fix. PHP says its temporary measures reduce exposure to specific attack paths but do not make an installation safe. Geniar lists suggestions that give false confidence: hiding errors, ini_set() or .user.ini, and RLIMIT_AS. Firewalls help only when the origin cannot be reached directly, and AWS says a WAF only partly helps with CVE-2026-109618. 

A Short Triage Framework for Engineering Leaders

Sort every PHP asset into one of five states, and move assets between states only with evidence. Priority within a state comes from documented factors: verified vulnerability details, internet exposure, plausible exploitation conditions, asset importance and fix availability. Do not invent numeric risk scores without an agreed method. 

Patching can move an asset to verified fixed, but it does not close an investigation. An exposed asset that stayed unpatched after 17 October belongs in the last row until the logs say otherwise. 

The Operational Takeaway: Verify the Runtime, the Fix, and the Evidence

Reliable vulnerability management takes more than recognizing a CVE number or reading a version string. These two CVEs share a score and a fix but not a mechanism. Map each advisory to the runtime that serves traffic, confirm the fix reached it and the workers restarted, and keep the evidence. For implementation steps, use our step-by-step remediation guide. 

Related Sources

• PHP2Shell WordPress Fix: Why Updating Plugins Will Not Protect Your Site

• How to Fix PHP2Shell Vulnerabilities: A 2026 Guide

• PHP2Shell Security Crisis 2026

• Mattias Geniar — Early Mitigation Guidance for CVE-2026-109618

• AWS Security Bulletin — PHP Web Runtimes

• F5 Knowledge Base

• cPanel Security Release — CVE-2026-109618 and CVE-2026-109619

• VirusTotal Blog — Exposure-Window Analysis for CVE-2026