Critical PHP Security Update: What to Do on 21 October 2026

PHP has released fixes for two critical vulnerabilities that can allow unauthenticated remote code execution. If you operate a PHP website, update its runtime immediately and verify that the processes serving requests have picked up the fix.

The official PHP advisory covers CVE-2026-109618, involving out-of-memory corruption, and CVE-2026-109619, involving stale internal state. PHP considers all installations serving web requests at risk, including FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed. The demonstrated mod_php attack can occur before application code executes.

Which PHP versions contain the fixes?

Use the fixed release for your existing supported branch, or a later release containing these fixes. This avoids turning an urgent patch into an unnecessary branch migration. The table combines PHP’s release changelog with its official support schedule; support status is shown as of 21 October 2026.

PHP 8.1 and older are outside normal PHP project support. The advisory links exceptional minimal source backports for 7.4, 8.0 and 8.1; these do not restore ongoing support. Ask your distribution or LTS provider for its fixed package, or plan a supported-version upgrade. Vendor backports can retain an older upstream version number, so check the vendor’s security notice and complete package revision.

Find every PHP runtime you operate

Start with an inventory: public sites, administrative tools, API services, scheduled commands, queue consumers and containers. One server can have several PHP branches and several independent copies of the same branch. A successful update in your SSH session can leave a website or container running older code.

These commands identify the PHP selected by the current shell:

command -v php
php -v
php --ini
php -m

Record the web server’s FPM socket or upstream, the relevant service configuration, and the executable used by process managers. For Octane, identify its server implementation and runtime too. Check the running request path through an authenticated diagnostic or private readiness check that reports PHP_VERSION and PHP_SAPI. Do not leave a public phpinfo() page behind.

Keep the application release and dependency lockfile stable where possible. Test the candidate PHP runtime with the application’s required extensions and platform requirements before directing traffic to it.

Laravel Cloud: no redeployment required

Laravel Cloud customers do not need to redeploy for this incident. In its official PHP vulnerability response update, updated at 14:27 UTC, Laravel says it is automatically replacing PHP in running applications. Applications remain online; deployments are paused until patched images are available.

Follow that incident page for completion and deployment-resumption notices. Its instructions supersede earlier advice to prepare a redeployment. Continue checking application health while the platform performs the update.

For general branch changes, Cloud’s runtime documentation describes General Settings → Runtime and redeployment. That separate workflow is unnecessary for this managed incident response. A branch label such as “PHP 8.4” is still distinct from the complete patch version reported by a running application.

How to patch PHP on Laravel Forge

Start with the official Forge PHP security update guide. Forge’s automatic security updates do not patch PHP: its PHP packages come from a separate repository outside Ubuntu’s normal unattended security updates. Each server needs an explicit PHP update.

Forge recommends the dashboard because it repairs the PHP package source before upgrading. Open server dashboard → PHP tab → version dropdown → Update PHP X.X, then confirm. Repeat for every installed PHP branch, including unused branches. The guide also provides SSH instructions if dashboard access is slow; verify the package candidate before installing.

The upgrade restarts that branch’s FPM service and reloads Nginx, with possible brief downtime. Existing CLI workers need a separate refresh, including queues, Horizon, Octane and Reverb. Verify their replacement processes and follow the runtime-specific guidance below.

Laravel’s live incident update, timestamped 14:27 UTC, still warned that Ubuntu PHP PPAs lacked the fixes. Check its latest availability notice and your package candidate; an update attempt alone proves nothing. Laravel advises powering down servers that cannot be patched promptly.

Branch selection remains separate: Forge’s general PHP documentation explains that changing the default for new sites does not change existing sites, and the CLI default is another setting. For an availability requirement, use your established redundant deployment procedure and account for shared services before updating.

The same Laravel incident post covers Vapor: native PHP 8.3+ applications receive automatic redeployment, while custom and Docker runtimes require owners to rebuild with patched PHP and redeploy.

Updating a Linux server you manage

Use your distribution’s supported package procedure and existing trusted repository. Refresh repository metadata, inspect the candidate versions and security changelog, and preview the transaction before installing. On Ubuntu, sudo apt update refreshes the package index; it does not install PHP updates. Ubuntu’s package management documentation explains that distinction.

Package names, available PHP branches and release timing depend on the distribution and repository. Include the web runtime, CLI and matching extensions in the review. Take a verified backup and check whether package hooks will restart FPM or a process manager automatically. An uncontrolled restart can interrupt traffic before your planned switch. If fixed packages are unavailable, escalate to your provider instead of treating a successful package command as confirmation of remediation.

Replace the processes using the old runtime

Installing files on disk does not establish that existing processes have loaded them. For FPM, use the service’s supported graceful replacement procedure and verify the resulting workers. With a redundant setup, start a patched pool, test it privately, switch traffic, then drain the old pool. Plan the same sequence across replicas.

Laravel documents php artisan octane:reload for refreshing application workers after code deployment. An engine update needs additional care: ensure the server and its workers are started with the patched executable or embedded PHP build. A worker reload can retain an existing parent runtime, depending on the server. Verify the replacement processes rather than assuming the command changed PHP. See Octane’s worker lifecycle documentation.

For ordinary Laravel queue workers, php artisan queue:restart requests a graceful exit after current jobs finish. Ensure restart polling is enabled, the cache signal reaches workers, and the process manager starts replacements with the patched binary. Follow Horizon’s own termination procedure if you use Horizon. Check job completion, fresh worker processes and scheduled tasks afterward. Laravel’s queue deployment guide explains the restart mechanism.

Containers need their own patched images

Updating the host’s PHP packages does not update PHP inside a container. Pull a verified fixed image or rebuild from an updated base, test it, and replace the running containers through your deployment system. Docker’s image guidance explains why rebuilding matters and why --pull is needed to check for a refreshed base.

If you pin image digests, explicitly update the digest to the verified fixed build. A mutable tag such as latest is not evidence of its contents. Confirm the PHP version in each new container and the actual serving process, including separately deployed administration tools and worker images.

Verify security and application health

Finish with two kinds of evidence: the correct runtime is active, and the application still works.

• Record the installed release or vendor backport, executable or image identity, and running process replacement.
• Check the private readiness endpoint and representative pages through the public route, watching for HTTP errors during the switch.
• Exercise authentication, database access and a safe background job; inspect application logs, failed jobs and worker health.
• Confirm that every replica and relevant service is covered, then remove temporary diagnostics.

A green homepage alone cannot prove that all workers are patched. Likewise, a new CLI version cannot establish web availability. Keep both records with the deployment so the result is reviewable.

If you cannot patch immediately

PHP says there is no complete mitigation other than updating. Laravel maintenance mode still involves PHP execution, so it does not repair this engine vulnerability; Laravel documents maintenance mode as application behavior.

If temporary isolation is necessary, arrange controls that prevent untrusted requests from reaching PHP, such as a static response at the proxy or edge, and cover direct-origin access too. This interrupts application access and requires an operational decision. Review the advisory’s temporary measures with your provider while pursuing the actual runtime update.

This site, tillythecoder.com, is now running PHP 8.4.27.