Two critical PHP vulnerabilities were disclosed on October 21, 2026. If you maintain a PHP application, here's how to check your runtime, patch safely, and avoid turning an urgent security update into a production incident.
The PHP team has released security updates for two vulnerabilities that can allow unauthenticated remote code execution on affected systems.
The vulnerabilities are:
CVE-2026-109618
CVE-2026-109619
Both have a CVSS v4.0 score of 9.2 and have been associated with the name PHP2Shell.
The official PHP advisory is here: https://www.php.net/archive/2026.php
The key takeaway is straightforward: identify every affected PHP deployment and apply the appropriate security update immediately.
The more complicated part is making sure the fix reaches the PHP runtime actually serving production traffic.
Which PHP versions are affected?
The PHP project has published the following fixed releases:
PHP 8.1 and earlier are no longer supported upstream. Some operating-system vendors and long-term-support providers may offer backported security fixes, so check the guidance for your specific environment.
Don't assume that running an older version automatically means you must rewrite your application. The immediate priority is to establish whether your actual runtime has the necessary security fix, then plan any broader upgrade work that is required.
Understand what you're patching
These vulnerabilities affect PHP's runtime rather than a single application framework.
According to the PHP security advisory, one vulnerability involves unsafe handling of an out-of-memory condition, while the other involves stale internal state referencing memory that has already been freed.
Under exploitable conditions, these issues can lead to remote code execution.
This distinction matters because upgrading a Laravel package or changing application-level validation rules does not, by itself, fix a vulnerability in the PHP runtime.
Likewise, a well-written application is not automatically protected if it runs on a vulnerable PHP build.
The correct remediation depends on your runtime, operating system, hosting platform, and deployment process.
*Check the PHP version you actually run
*
Start with the command-line PHP installation:
php -v
You should see the installed CLI version.
For example:
PHP 8.4.27 (cli)
However, there's an important catch: the CLI version may not be the version serving web requests.
A server can have multiple PHP installations. Your terminal may use one version while PHP-FPM, Apache, a container, or a managed hosting service uses another.
Check the relevant deployment configuration and confirm the runtime used by your application.
For PHP-FPM, inspect the service and pool configuration for the relevant PHP version. For Docker-based applications, inspect the image and rebuild configuration. For managed platforms, consult the provider's runtime documentation.
Avoid exposing a public diagnostic endpoint containing phpinfo() just to check a version. If you use one temporarily in a controlled environment, remove it immediately afterward.
Patch the runtime and redeploy
For a directly managed installation, use the appropriate patched package supplied by your operating-system vendor or update your PHP build according to the official instructions.
On container-based deployments, updating PHP on your laptop or host does not update an image that has already been deployed.
A typical workflow looks like this:
# Inspect the current CLI runtime
php -v
# Inspect PHP dependencies
composer check-platform-reqs
# Run your project's test suite
# Use the test command defined by your project
These commands are diagnostic and validation steps, not a complete patching procedure. The actual runtime update depends on your operating system, package manager, container image, and deployment platform.
After updating, rebuild affected images or packages and redeploy the application where required.
Restart the relevant workers or services if your platform requires it, then verify that the running processes use the patched runtime.
For managed hosting, ask the provider to confirm whether the fix has been applied to your specific application.
Don't confuse a runtime patch with an application upgrade
This is where legacy applications can become difficult to maintain.
Imagine a Laravel application that has been running successfully for years. Its dependencies were installed under an older PHP version, automated test coverage is incomplete, and the original developers are no longer available.
The team may need to move to a supported runtime, but the application may rely on outdated packages or behaviours that have changed between PHP versions.
That does not mean the security fix should be delayed unnecessarily. It means the team needs to distinguish between two related tasks:
Immediate remediation: Get the appropriate security fix into the running environment.
Longer-term modernization: Address unsupported runtimes, incompatible dependencies, framework constraints, and application code that prevents safe upgrades.
Sometimes the first task is straightforward. Sometimes the second requires a carefully planned migration.
Keeping those tasks separate helps teams prioritize the security response without losing sight of their underlying technical debt.
A practical deployment checklist
Before considering the incident resolved, work through the following:
Inventory PHP applications, servers, containers, and background workers.
Confirm the PHP version serving each application.
Check whether the runtime has the appropriate security fix.
Apply the vendor-supported patch or upgrade.
Rebuild and redeploy container images where necessary.
Restart affected services or workers when required.
Verify the runtime version after deployment.
Run automated tests and validate critical application workflows.
Review logs and investigate suspicious activity if exposure may have occurred.
Document the fix and identify any remaining unsupported components.
If immediate remediation is not possible, follow the official advisory and your security team's incident-response guidance. Temporary controls may reduce exposure, but they are not a substitute for installing the appropriate fix.
What about Composer and Laravel?
Composer helps manage application dependencies, but updating Composer packages alone does not patch the PHP engine.
You should still check platform requirements and dependency compatibility when planning a runtime upgrade.
Useful commands include:
composer check-platform-reqs
composer outdated
The first checks whether the current PHP and extensions satisfy the installed packages' requirements. The second helps identify packages with newer releases, but it does not tell you that every update is safe or necessary.
Review the output before making changes. Updating every dependency at once during an urgent security incident can introduce unrelated risks.
For Laravel applications, also verify that your Laravel version and third-party packages support your target PHP version.
Run the test suite, inspect deprecation warnings, and validate important workflows in staging before deploying application-level changes.
What should you do if your application is too old to upgrade easily?
This is a common problem for business-critical software.
An application can continue working for years even when its framework, dependencies, or runtime are approaching the end of their supported lifetimes.
The difficulty often isn't knowing that an upgrade is necessary. It's understanding how much needs to change and how to prove that the updated application still works.
A sensible approach is to:
Establish the current runtime and framework versions.
Identify unsupported dependencies and compatibility constraints.
Define a supported target version.
Make the smallest safe set of changes needed to reach that target.
Test the resulting application and document any remaining risks.
You do not necessarily need to rewrite a working application from scratch.
For teams that need help with this process, Unstale focuses on modernizing existing codebases through tested upgrade pull requests.
You can also read the PHP 8.2 to 8.4 upgrade guide for more on compatibility challenges involved in moving between PHP versions.
Final thoughts
PHP2Shell is a reminder that application security depends on more than writing secure code. It also depends on maintaining the runtime, keeping dependencies supported, and being able to deploy fixes quickly.
Start by verifying your production runtime and applying the appropriate security update. Then use the incident as an opportunity to identify older applications that are becoming increasingly difficult to maintain.
The goal is not to make every application undergo a major migration after every security advisory.
It's to make sure that when the next critical update arrives, you can respond confidently rather than discovering that your production codebase has become too fragile to change.
Useful references
Official PHP security advisory
This article is for general technical information and is not a substitute for the official security advisory or a review of your specific deployment.
Top comments (0)