PHP security updates address two critical vulnerabilities

What happened

On October 21, 2026, the PHP project published a security advisory for two critical vulnerabilities affecting PHP installations that serve web requests. The project describes CVE-2026-109618 as remote code execution via out-of-memory corruption and CVE-2026-109619 as remote code execution via stale global state. Government cybersecurity agencies advise organizations to identify PHP-based applications, coordinate with providers, and apply available updates.

PHP’s upstream security releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP.net says Linux distributions and long-term support vendors received patches in advance and advises users of PHP 8.1 and older to check with their vendor or upgrade to a supported version.

Why the version number may not tell the whole story

Some operating-system and hosting vendors apply a security fix as a backport to an older package branch. In that case, the public-facing PHP_VERSION string may remain at an older upstream version even though the vendor’s package includes the fix. Conversely, a general statement that a fleet is “covered” does not identify which package or server build handles a specific account.

For shared hosting, customers generally cannot inspect the system package changelog themselves. Ask the provider to confirm the status for the package and server that handle your account. An exact version check can identify the web runtime; it cannot independently prove a backport.

Special note for PHP 5.6 and other legacy branches

PHP 5.6 is long past upstream support. PHP.net states that PHP 8.1 and older no longer receive updates from the PHP project. Legacy coverage therefore depends on a separate distribution or commercial extended-support provider and the particular package installed by your host.

cPanel’s October 22 bulletin lists patched CloudLinux EasyApache 4 package builds for older branches, including ea-php56 5.6.40-25. That listing is specific to CloudLinux’s package line; it does not prove that every PHP 5.6 installation, hosting provider, reseller environment, or LiteSpeed runtime has that build. The same cPanel bulletin says its own EasyApache 4 updates were then released for PHP 7.4 and above, and points customers using versions older than 7.4 to TuxCare Extended Lifecycle Support. Check which vendor package actually supplies PHP on your server.

What to ask your hosting provider

1. Which PHP runtime and package vendor serve my domain, including the SAPI/handler?
2. Does that exact package/build contain fixes for CVE-2026-109618 and CVE-2026-109619?
3. For PHP 5.6, is an extended-support provider supplying the patched package, and which package lineage applies?
4. Can you confirm the fix is installed on the server serving my account, and whether any account action or PHP-version change is required?

Share your domain, the PHP version, and SAPI from the exact-version check. A provider may not disclose internal server identifiers, but should be able to answer whether the package serving your site includes the fixes. If the answer is unclear, ask for confirmation against both CVE IDs and your specific PHP branch.

Next steps

• Check every site and subdomain; they may use different PHP versions or handlers.
• Request vendor/package-specific confirmation from your host, especially for PHP 5.6 or other legacy versions.
• Plan migration from unsupported PHP branches to a currently supported version when your application permits it.
• Do not treat a version string, a generic “fleet-wide” assurance, or a mitigation as a substitute for package-level verification and a supported upgrade path.