Critical PHP Security Release (October 21, 2026): What to Know and How to Upgrade Safely

On 20 October 2026 the PHP project announced an upcoming critical PHP security release. It will fix two vulnerabilities, each rated CVSS v4.0 9.2, and is scheduled for Wednesday, 21 October 2026 at 14:00 UTC. The PHP team asks all users to prepare now so they can update as soon as the release is available. It may ship earlier if details become public or if exploitation is seen in the wild.

This article was created with AI assistance and written before the release. Facts were checked against the official php.net announcement and supported-versions page on October 21, 2026. Affected and fixed versions will only be known when PHP publishes the release, so always follow the official advisory.

What we know about the PHP security release

Several security researchers have described the issues as remote code execution flaws. PHP has not confirmed that, so plan for the worst case: an internet-reachable PHP application may be exploitable once details are public. Your goal is to be able to patch every exposed PHP runtime within hours of the release, not days.

PHP security release time in your time zone

Upstream source releases arrive first. Linux distribution packages, Docker images, and hosting platforms follow on their own schedules, from hours to days later. Plan your window around when your channel publishes, not only the upstream time.

Which PHP versions are supported?

PHP publishes security fixes only for supported branches. According to php.net, these are the supported branches as of October 2026:

The fixed releases will be the next patch version in each affected branch. Confirm the exact numbers in the official release notes. If you are not yet on the September 2026 releases listed above, upgrading to them now shortens tomorrow’s change.

Prepare before the release: a checklist

1. Inventory every PHP runtime. Include web servers, PHP-FPM pools, CLI hosts running cron jobs, queue workers, container images, CI runners, and build images. Record the branch, exact version, SAPI, and how each was installed: OS package, third-party repository, Docker base image, control panel, or source build.
2. Rank by exposure. Internet-facing applications come first, then internal applications, then build and CI systems.
3. Find end-of-life versions now. Anything on PHP 8.1 or older needs a separate plan (see below).
4. Confirm your update channel. Know which repository, image tag, or hosting setting delivers the patch, and subscribe to its security advisories.
5. Freeze unrelated changes. Do not combine the security update with application deploys or a minor-version upgrade, such as 8.3 to 8.4.
6. Prepare a staging run. Line up a smoke test and your automated test suite so you can validate the patched build quickly.
7. Prepare rollback. Keep the current package versions or image digests recorded so you can revert in minutes if a regression appears.
8. Line up people and monitoring. Agree who patches what and when, and watch error rates, latency, and PHP-FPM logs during the rollout.
9. Check edge protection. If you run a WAF, be ready to enable vendor rules for these CVEs as soon as they are published. Treat them as a stopgap, not a fix.

To list versions quickly on each host:

# CLI version (may differ from the web SAPI)
php -v

# PHP-FPM version (binary name varies by distribution)
php-fpm -v || php-fpm8.3 -v || /usr/sbin/php-fpm -v

# Debian/Ubuntu installed packages
dpkg -l | grep -E '^ii\s+php[0-9.]*-(cli|fpm|common)'

# RHEL/Alma/Rocky installed packages
rpm -qa | grep -E '^php(-|[0-9])' | sort

# Running containers and their PHP versions
docker ps --format '{{.Names}}' | xargs -I{} sh -c 'echo "{}: $(docker exec {} php -r "echo PHP_VERSION;" 2>/dev/null)"'

Principles for a low-disruption PHP security upgrade

• Stay on your branch. A patch update within a branch, such as 8.4.26 to the next 8.4 release, keeps the same extension API. Compiled extensions keep working and code changes are not expected. That makes it a much smaller change than a minor upgrade.
• Reload, don’t hard-stop. PHP-FPM supports a graceful reload that lets in-flight requests finish. Set process_control_timeout (for example 10s) so workers can complete before the switch.
• Roll out gradually. Patch one node, a canary pod, or one site first. Watch it for a few minutes, then continue.
• Drain before restart. Behind a load balancer, remove a node from rotation, patch it, verify it, and return it.
• Patch every SAPI. CLI, FPM, and the Apache module are separate packages or binaries, and each one needs the update.
• Rebuild, don’t mutate, containers. Build a new image from the patched base image and redeploy it.

PHP upgrade paths by setup and stack

Debian and Ubuntu: distribution packages

Debian and Ubuntu keep the PHP branch shipped with each release; for example, Debian 12 uses PHP 8.2, Debian 13 uses PHP 8.4, and Ubuntu 24.04 uses PHP 8.3. They backport security fixes into those packages, so the package version will not match the upstream version number. Watch the Debian Security Advisories (DSA) or Ubuntu Security Notices (USN), then:

sudo apt-get update
sudo apt-get install --only-upgrade 'php8.3-*'     # use your branch
sudo systemctl reload php8.3-fpm                    # graceful reload
php -v && php-fpm8.3 -v

Distributions may also patch branches that are end of life upstream but still supported by the vendor. Check the vendor’s advisory for your release.

Ondřej Surý repositories (deb.sury.org / Ubuntu PPA)

If you install PHP from the widely used Surý repositories, they usually package upstream releases soon after publication, and version numbers follow upstream. Upgrade with the same apt-get install --only-upgrade command and reload PHP-FPM.

RHEL, AlmaLinux, Rocky Linux, Fedora

Red Hat and rebuild distributions ship PHP through AppStream, which uses module streams on RHEL 8 and 9, and backport fixes announced in their advisories. Sites using the Remi repository get upstream releases directly. In both cases:

sudo dnf upgrade --refresh 'php*'
sudo systemctl reload php-fpm
php -v

Alpine Linux

Alpine packages each branch separately (for example php83, php84). Run apk update && apk upgrade once the patched packages appear in your Alpine release, or rebuild container images that use Alpine as their base.

Docker: official PHP images

The official php images (for example php:8.4-fpm, php:8.4-apache, php:8.4-cli, and their -alpine variants) are rebuilt when a new upstream release is published. To pick up the fix:

# Rebuild without cache so the new base layer is pulled
docker build --pull --no-cache -t registry.example.com/app:php-sec-2026-10 .

# Confirm the runtime version inside the new image
docker run --rm registry.example.com/app:php-sec-2026-10 php -v

• If you pin base images by digest (recommended), update the digest to the newly published one.
• If you pin an exact patch tag such as php:8.4.26-fpm, change it to the new patch tag.
• Multi-stage builds copy PHP from more than one base image, so update every stage that does.
• Extensions installed with docker-php-ext-install or PECL are rebuilt with the image; no extra step is needed within the same branch.

Kubernetes

Roll the patched image through a normal Deployment rolling update so capacity never drops:

• Use readiness probes that hit a real PHP endpoint, so traffic only reaches pods that serve requests.
• Set maxUnavailable: 0 and a small maxSurge for a zero-capacity-loss rollout, and keep a PodDisruptionBudget.
• Add a preStop sleep plus PHP-FPM’s graceful shutdown so in-flight requests finish.
• Remember CronJobs, queue-worker Deployments, and init containers that run PHP.
• Roll back with kubectl rollout undo if error rates rise.

Shared hosting, cPanel, and Plesk

On managed or shared hosting, the provider patches PHP builds such as cPanel’s EasyApache packages or Plesk’s PHP handlers. Your job is to confirm that it happened. Check the patch level in your control panel (for example cPanel’s MultiPHP Manager), or put a temporary phpinfo() page behind authentication and remove it afterwards. If your site uses an end-of-life version, switch it to a supported branch in the control panel after testing.

PaaS and serverless

• Laravel Forge and Laravel Cloud: Laravel has said it will update its platforms with patched versions. Follow its announcements; you may need to redeploy.
• Buildpack platforms such as Heroku resolve the PHP version at build time, so trigger a new build and deploy once the platform publishes the new runtime.
• AWS Lambda with Bref: update to the layer version that contains the patched PHP release, then redeploy.
• Managed platforms such as Elastic Beanstalk or App Service: apply the platform update or redeploy to the patched platform version.

Windows and IIS

Download the new build from windows.php.net that matches your architecture and thread-safety setting (IIS with FastCGI normally uses the non-thread-safe build). Unpack it next to the current version, copy over php.ini and any extension DLLs built for the same branch, point the FastCGI handler at the new directory, and recycle the application pool.

Custom builds from source

Record your current configure options with php -i | grep "Configure Command", build the new release with the same options into a new prefix, switch your service to it, and reload. Keeping the old prefix in place gives you an instant rollback.

Developer machines and CI images

Lower risk, but do not skip them: brew upgrade php on macOS, update CI images such as setup-php versions or base images, and rebuild any internal Docker build images.

Restart long-running PHP processes

A package upgrade does not change processes that are already running. Anything that keeps a PHP process alive keeps running the vulnerable binary until it restarts:

• Queue workers: php artisan queue:restart, php artisan horizon:terminate, or php bin/console messenger:stop-workers, managed by Supervisor or systemd.
• Application servers: Laravel Octane, RoadRunner, Swoole, and ReactPHP processes need a restart or reload.
• FrankenPHP embeds PHP in its binary, so you need a FrankenPHP build or image that includes the patched PHP release.
• Apache with mod_php: run apachectl graceful, or schedule a restart.

Check process start times after patching. Any PHP process older than the upgrade is still running the old code.

Verify the upgrade

1. Check the version for every SAPI: CLI, FPM, and the web server (through an authenticated status or diagnostics endpoint, not a public phpinfo()).
2. Compare against the fixed versions listed in the official advisory, or your distribution’s advisory if it backports fixes.
3. Run smoke tests and your automated test suite against staging, then production.
4. Watch PHP-FPM logs, 5xx rates, and latency for at least an hour after rollout.
5. Rescan with your vulnerability scanner so your asset inventory shows the new version.
6. Keep expose_php = Off so you do not advertise your PHP version in the X-Powered-By header.

If you are still on PHP 8.1 or older

PHP 8.1 reached end of life on 31 December 2025, and older branches earlier. The PHP project will not publish fixes for them. Your options, in order of preference:

1. Check vendor support. Your OS vendor may still patch its packaged PHP, for example through extended or long-term support subscriptions.
2. Use commercial extended support for PHP if you cannot upgrade in time.
3. Reduce exposure while you upgrade: put the application behind a WAF with rules for these CVEs, restrict access by network where possible, and turn off unused endpoints and upload features.
4. Plan the branch upgrade. Tools such as Rector, PHPCompatibility for PHP_CodeSniffer, and PHPStan help find incompatible code. Upgrade dependencies with Composer, run your tests, and move to PHP 8.4 or 8.5 for the longest support window.

How DAST tools help you catch issues like this sooner

No scanner can predict an unpublished vulnerability in the PHP engine. Patching the runtime is the only fix for this release. Remote code execution in a real application, however, rarely depends on one bug alone. Attackers chain an engine flaw with weaknesses in your own application: an upload endpoint that accepts PHP files, an input that reaches a shell or template, a debug page, or a header that tells them exactly which version you run. Dynamic application security testing (DAST) finds those weaknesses from the outside, the same way an attacker would, so the next engine-level emergency has fewer ways in.

DastPilot scans your APIs from an OpenAPI spec or Postman collection, as every role you configure. Its checks that matter most for PHP applications:

• Version and stack disclosure: flags fingerprinting headers such as X-Powered-By and Server that reveal your PHP version to anyone scanning for vulnerable targets.
• Dangerous file uploads: tests whether upload endpoints accept .php and other executable file types, a common route from a file upload to code execution.
• Injection that leads toward code execution: command injection, server-side template injection, SQL and NoSQL injection, path traversal, XXE, and SSRF probes on every parameter your API definition describes.
• Leaky errors and debug surfaces: detects verbose error output and unauthenticated debug or configuration endpoints that hand attackers internal details.
• Authorization and authentication: BOLA, BFLA, and token-handling checks, so an attacker who gets a foothold cannot easily move from one account to all of them.
• Regression tracking: compares each scan with the last, so a weakness that returns after an emergency deploy is flagged as reopened.

Two practical habits make the difference during an event like this one. First, run scans on a schedule or in your pipeline, so these weaknesses are already fixed before the next advisory lands. Second, rescan staging immediately after an emergency runtime upgrade to confirm that the patched build still enforces the same defenses. DAST complements patching and version inventory; it does not tell you which PHP CVEs affect you. Pair it with your package manager, image scanner, or asset inventory for that. See how findings are reported in the sample DastPilot report.

After you patch: close the remaining gaps

A runtime patch fixes PHP itself, not your application code or its dependencies. While the change window is open, it is a good time to:

• Run composer audit to catch known-vulnerable packages. For dependency hygiene in JavaScript front ends, see how to mitigate npm supply chain attacks.
• Rescan staging with your DAST tool to confirm that the patched build still enforces authorization, authentication, and injection defenses.
• Automate the next one. Teams that already run security checks in their pipelines can rebuild, test, and ship an emergency patch in one pass. See API security testing in CI/CD.
• Add PHP version and patch level to your asset inventory so the next emergency starts with a query, not a hunt.

Frequently asked questions

When is the PHP critical security release?

The PHP project scheduled it for Wednesday, 21 October 2026 at 14:00 UTC, which is 7:30 PM IST, 10:00 AM EDT, 3:00 PM BST, and 4:00 PM CEST. PHP said it may release earlier if vulnerability details become public or exploitation is detected.

Which PHP versions are affected by the October 2026 vulnerabilities?

PHP did not disclose affected versions before the release. Fixes are published for supported branches, PHP 8.2, 8.3, 8.4, and 8.5. Check the official release announcement for the exact affected and fixed versions.

Will PHP 8.1 get a security fix?

PHP 8.1 reached end of life on 31 December 2025, so the PHP project will not publish fixes for it. Your operating system vendor or a commercial extended-support provider may still patch it. Otherwise, upgrade to a supported branch.

Do I need downtime to update PHP?

Usually not. A patch release within the same branch is a drop-in update. Use a graceful PHP-FPM reload, rolling updates behind a load balancer, or a Kubernetes rolling deployment so in-flight requests complete and capacity stays available.

How do I check my PHP version?

Run php -v for the command-line version and php-fpm -v (or the versioned binary, such as php-fpm8.3 -v) for PHP-FPM. The web SAPI can differ from the CLI, so check each one, and use your package manager or container image to confirm the installed patch level.

Can a DAST tool detect PHP vulnerabilities like these?

A DAST tool cannot predict an undisclosed flaw in the PHP engine, and patching is the only fix. DAST tools such as DastPilot find the application weaknesses attackers chain with engine flaws, including PHP version disclosure, executable file uploads, command and template injection, and exposed debug endpoints, so you can fix them before the next advisory.

What are the CVE numbers for the PHP security release?

Third-party reports link the release to CVE-2026-109618 and CVE-2026-109619. PHP had not confirmed the identifiers before the release, so verify them against the official advisory.