PHP fixed two critical vulnerabilities: versions and next steps

PHP published security fixes on October 21, 2026, for two critical flaws, CVE-2026-109618 and CVE-2026-109619. Both can allow an attacker to run code on a vulnerable server without logging in. PHP says installations serving web requests are at risk; operators should match their PHP branch to the fixed release and check with the vendor that supplies their package or service. PHP’s security advisory lists the fixes and interim controls.

What the two PHP vulnerabilities do

CVE-2026-109618 involves PHP running out of memory while request data is only partly initialized. During cleanup, PHP may then handle invalid data as if it were valid.

CVE-2026-109619 involves request-related internal state that remains after its backing memory is freed. A later request handled by the same worker can use that stale state. PHP classifies both flaws as critical and says they can enable unauthenticated remote code execution, meaning an attacker may run code on the server without first signing in.

Which web setups are at risk?

PHP names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed among the affected web-serving setups. It identifies Apache mod_php as the highest-risk configuration in that list.

Match your PHP branch to a fixed release

PHP’s fixed upstream releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Use the release for the branch your installation runs.

The version shown by a distribution or long-term-support vendor may follow its own package scheme. PHP says some distributions and LTS vendors backport fixes, so check the package source or service provider for the relevant update rather than relying on the upstream version number alone.

PHP 8.1 and older no longer receive updates from the PHP project. PHP published minimal source backports for branches 7.4, 8.0, and 8.1, and some vendors provide backported fixes. The vendor’s package status determines what is available for a particular installation.

The UK National Cyber Security Centre’s PHP guidance also advises checking appliances and third-party services that bundle PHP. A site may depend on PHP through software or infrastructure managed by another organization, so include those systems in the inventory.

If you cannot update immediately

PHP’s interim controls address specific exploit paths and do not provide a complete fix. For CVE-2026-109618, PHP recommends setting memory_limit=-1 in configuration that applications cannot override and limiting request-body size. PHP warns that an underlying allocation failure can still reach the vulnerable path.

For CVE-2026-109619, PHP recommends disabling session.upload_progress before request parsing and restarting workers. For a confirmed fatal-backtrace path in PHP 8.5, it also names fatal_error_backtraces=0. PHP says applying the appropriate update is the only complete solution.

The NCSC advises organizations to inventory PHP deployments and prioritize systems exposed to the internet. Apply the relevant update or temporary controls; if neither can be applied in time, consider taking the system offline. If immediate updating or shutdown is not possible, check for compromise and backdoors before or during remediation. Continue tracking updates for vendor packages and for appliances or services that include PHP.

What website visitors can do

These vulnerabilities affect PHP on the server, so the organization operating that system must apply the fix. A visitor cannot install the server’s PHP update.