Critical PHP Security Update: Fix Two RCE Vulnerabilities

PHP has released security updates for two critical remote code execution vulnerabilities. Here is what developers and infrastructure teams need to check, update, and verify.

A routine security update can quickly become an urgent infrastructure task when it affects the runtime behind production applications. On October 21, 2026, the PHP team published a security advisory for two critical vulnerabilities that can allow unauthenticated remote code execution (RCE).

The issue is especially serious because an attacker may be able to trigger vulnerable code paths before an application has a chance to apply its own validation or authentication logic. Updating a framework or a CMS alone will not fix a vulnerability in the PHP runtime itself.

If you operate PHP websites, APIs, WordPress installations, Laravel applications, or servers running PHP-FPM, treat this advisory as an infrastructure-level priority. Inventory your installations, check the packages provided by your operating system or hosting vendor, and apply the relevant security fix as soon as possible.

Which PHP versions contain the fixes?

The PHP project released these corrected versions on October 21, 2026:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

These releases address both vulnerabilities described in the official advisory. PHP strongly encourages users to update immediately. If you install PHP through a Linux distribution or a long-term support vendor, check that vendor's security notices and install its patched packages. Package versions do not always match upstream version numbers because vendors may backport fixes.

PHP 8.1 and older no longer receive routine updates from the PHP project. Some distributions and LTS providers may supply backported patches, so verify the status of your specific package rather than assuming that an older version is either patched or vulnerable based on its version string alone. If no supported patch is available, plan a migration to a supported PHP branch.

PHP 8.2 is approaching end of life on December 31, 2026. Applying PHP 8.2.35 addresses these vulnerabilities, but teams still using this branch should plan an upgrade before security maintenance ends.

Why remote code execution is so dangerous

Remote Code Execution is a high-impact vulnerability class because it can allow an attacker to execute instructions on the affected server. The consequences depend on the privileges of the PHP process and on the surrounding environment, but potential impacts include reading accessible application files, exposing configuration secrets, accessing data, changing application behaviour, or using a compromised server as a foothold for further attacks.

The critical detail in this advisory is that the vulnerable paths exist inside PHP. Application-level controls remain important, but they cannot reliably repair incorrect memory handling or internal runtime state. Authentication middleware, request validation, framework upgrades, and plugin updates are not substitutes for a patched runtime.

CVE-2026–109618: remote code execution through out-of-memory corruption

The first issue, CVE-2026–109618, involves PHP's handling of out-of-memory (OOM) conditions. Under certain circumstances, a memory allocation failure can interrupt request processing while internal request data is only partially initialized. During cleanup, PHP may then treat invalid data as if it were valid, creating a memory-corruption condition that can lead to remote code execution.

This is a reminder that software must handle failure paths as carefully as normal execution. Error handling, partial initialization, and resource cleanup are complex parts of a runtime. A failure that appears to be a simple allocation problem can become a security issue if internal invariants are not preserved.

Server resource limits and request-size controls can help reduce exposure to some attack paths, but they do not correct the underlying defect. The PHP advisory specifically warns that mitigations are incomplete and that updating is the only safe choice.

CVE-2026–109619: remote code execution through stale global state

The second issue, CVE-2026–109619, concerns stale internal state associated with a request. Request-owned data can remain referenced after the memory backing it has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

This matters in long-running worker models, where a process may handle multiple requests over its lifetime. Correctly releasing memory is not enough: references to released memory must not remain usable, and every request must begin with a valid, predictable internal state.

As with the first vulnerability, the fix belongs in PHP itself. Application code changes may reduce specific exposure paths, but they cannot guarantee that the runtime's internal state management is safe.

Which PHP server configurations are affected?

The advisory covers PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team identifies Apache with mod_php as the highest-risk configuration because a demonstrated exploit can trigger the issue through a single unauthenticated request before application code runs.

Do not interpret that distinction as proof that other configurations are safe. A reverse proxy, web application firewall, load balancer, or modern framework does not automatically remove a vulnerability in the PHP runtime. These controls may form part of a defence-in-depth strategy, but the underlying runtime still needs to be patched.

Check every place PHP runs: production and staging servers, container images, command-line jobs, queue workers, administrative tools, and secondary sites on the same host. It is common for the command-line executable and the runtime used by a web server to come from different packages or versions.

How to check the PHP version on Linux

Start by checking the PHP CLI executable:

php -v

php -v

This reports the version used by the command-line shell. It does not prove that Apache or PHP-FPM uses the same runtime. On Debian or Ubuntu, list installed PHP packages with:

dpkg -l | grep -E 'php[0-9.]|php-fpm'

dpkg -l | grep -E 'php[0-9.]|php-fpm'

To discover PHP-FPM services registered with systemd, run:

systemctl list-units --type=service | grep -i php

systemctl list-units --type=service | grep -i php

Use these commands as an initial inventory, then inspect the actual web-server configuration, PHP-FPM pools, containers, and package repositories. If several PHP branches are installed side by side, verify each one and identify which sites or services use it. Updating the CLI package alone will not protect a website that continues to run a vulnerable PHP-FPM service.

How to update PHP on Ubuntu and Debian

The correct procedure depends on the operating-system release, the package source, and the PHP branch in use. Before changing a production server, confirm that the configured repository provides a package containing the fix. Distribution vendors may publish patched packages on their own schedule and may use version strings that differ from upstream releases.

Refresh the package index:

sudo apt update

sudo apt update

Review packages that can be upgraded:

apt list --upgradable

apt list --upgradable

Apply the security updates using your distribution's normal change-management process. On production systems, check application compatibility, PHP extensions, dependencies, and rollback options before proceeding. Avoid blindly upgrading every package during an incident if that could introduce unrelated changes without testing.

After installing the correct package, restart or reload the relevant services as required so that new worker processes use the patched runtime. For example, on a server that actually uses the PHP 8.4 FPM service:

sudo systemctl restart php8.4-fpm
sudo systemctl status php8.4-fpm

sudo systemctl restart php8.4-fpm
sudo systemctl status php8.4-fpm

The service name is only an example. Adapt it to the installed PHP branch and your server configuration. Then verify the package version, service health, application logs, and the behaviour of critical application flows. A successful package installation is not enough if a vulnerable service or container is still running.

Temporary mitigations: useful, but not a substitute for patching

The PHP advisory describes measures that can reduce exposure to specific attack paths if an immediate update is not possible. The project is explicit: these measures do not make an installation safe, and there are no complete mitigations. Use them only as temporary risk-reduction steps while arranging the update.

For CVE-2026–109618, the advisory recommends setting memory_limit=-1, preferably in an administrator-controlled configuration such as php_admin_value in an FPM pool or Apache configuration. Check that no pool, directory, or application setting restores a finite limit. This removes the controllable PHP memory-limit failure, but an underlying allocation failure can still reach the vulnerable path. Because this setting removes PHP's per-request memory limit, evaluate its operational consequences carefully and use other resource controls to protect service availability.

The advisory also recommends keeping post_max_size low. For applications that do not need file uploads, it suggests post_max_size = 8M; where uploads are required, it suggests post_max_size = 32M, with upload_max_filesize kept below that value. Enforce appropriate limits at the web-server or proxy layer as well, including decoded request size and relevant multipart and input-count limits. Choose values that fit the application, and do not treat them as a complete fix.

For CVE-2026–109619, the advisory recommends setting session.upload_progress.enabled=0 in configuration that applies before request parsing, then restarting every affected worker. Do not rely on ini_set() or FPM .user.ini for this mitigation. On PHP 8.5, it also recommends setting fatal_error_backtraces=0 to block a confirmed fatal-backtrace attack path. This is not a general solution to the vulnerability.

The advisory further recommends removing invalid or deprecated per-request settings that emit diagnostics before initialization, and fixing attacker-reachable fatal errors and execution timeouts in callbacks, upload or import processing, and cleanup. Hiding diagnostics with error_reporting, display_errors, or the @ operator does not address the issue. Review the official advisory before applying any mitigation, and prioritise patching.

WordPress, Laravel, and custom applications need a runtime update

WordPress administrators may instinctively start by updating plugins and themes. Laravel developers may focus on Composer dependencies or framework releases. Those tasks remain essential, but neither fixes a vulnerability in the PHP engine.

Because these flaws can be triggered before application code runs, the remediation must reach the runtime serving the application. Check the PHP version configured for each virtual host, FPM pool, container, and background worker. If your hosting provider manages PHP for you, ask which patched package is deployed and when it will be applied.

For agencies and IT teams responsible for many sites, this is also an inventory and process test. An accurate record of domains, PHP branches, package sources, and service owners makes it much easier to identify exposure and prove that remediation is complete.

Build a repeatable security-update process

Critical advisories are easier to handle when the response does not begin from scratch. Maintain an inventory of runtime versions and where they are used. Track security notices from your operating-system and hosting vendors. Test updates on representative staging systems, document the production rollout, and confirm that the patched runtime is actually running.

Containerised environments need particular attention: updating a host package does not patch PHP inside an existing image. Rebuild images with a corrected base image or package, redeploy them, and verify that old containers have been replaced. The same principle applies to scheduled jobs and queue workers that may continue running after a web service has been updated.

Least-privilege service accounts, network segmentation, resource limits, logging, and monitoring can help limit the impact of a compromise. They are valuable layers of defence, not alternatives to security updates.

Final checklist: what to do now

• Inventory all PHP runtimes serving web requests, including PHP-FPM, Apache modules, CGI, containers, and secondary applications.
• Check the PHP security advisory and your operating-system or hosting vendor's package status.
• Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install a verified vendor package containing the fixes.
• Restart or redeploy affected services and workers as required.
• Verify the running runtime, service health, application logs, and critical application flows.
• Plan migration away from unsupported PHP branches, including PHP 8.2 before its security support ends.

The October 21, 2026 PHP advisory is a reminder that application security depends on more than application code. A well-written application can still be exposed by a vulnerable runtime beneath it. The immediate priority is to patch every affected installation, verify that the fix is active, and make the next security response faster through better inventory and deployment practices.

Have you checked the PHP runtimes in your production environment? Share in the comments how you track PHP versions and roll out critical security updates across servers, containers, and client applications.

Official reference

PHP security advisory: Critical remote code execution vulnerabilities, October 21, 2026

Suggested Medium topics: PHP, Cybersecurity, Web Development, DevOps, Linux, Software Engineering, Information Security.