PHP2Shell: patch PHP before it becomes an incident
Two critical PHP vulnerabilities can be triggered before an application runs. Check the fixed versions, upgrade steps, and what to verify on servers in Chișinău and Moldova.
A PHP runtime security update should not wait for the next redesign or sprint. On 21 October 2026, the PHP team released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, associated with PHP2Shell. In some configurations, a crafted HTTP request can lead to unauthenticated code execution. The issue is in the PHP runtime, not a WordPress plugin or a Laravel release.
We checked the runtime in our own service stack and found PHP 8.4.24. We pinned the Docker image to 8.4.27, rebuilt the containers, and verified PHP-FPM, queue, Reverb, and scheduler after restart. They are now all running the fixed version. The update was applied at the runtime level, not only in application code.
For businesses running websites, online stores, and portals in Chișinău and across Moldova, the practical question is simple: which PHP version is actually running on every server and container?
Which PHP versions need an update
Install at least the fixed release for your current branch. Earlier versions in each listed branch are affected:
- PHP 8.5.0–8.5.11 → update to 8.5.12 or later;
- PHP 8.4.0–8.4.26 → update to 8.4.27 or later;
- PHP 8.3.0–8.3.35 → update to 8.3.36 or later;
- PHP 8.2.0–8.2.34 → update to 8.2.35 or later.
PHP 8.2 receives security updates until 31 December 2026. If you are planning a migration now, choose a branch with longer support, such as PHP 8.3, 8.4, or 8.5, and check application compatibility first. PHP 8.1 and older no longer receive regular releases from the PHP project. Some distributions and vendors may provide backports; check the vendor advisory and installed package rather than relying on the version number alone.
The fixed versions and recommendations are in the official PHP advisory published on 21 October. Branch support dates are listed on PHP Supported Versions.
Why updating the runtime matters
The first vulnerability involves out-of-memory handling and invalid request state during cleanup. The second involves global state that can remain after its memory is freed and be consumed later by the same PHP process. An application filter or plugin update cannot repair the PHP engine.
The risk applies to PHP processing web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. A server may run several PHP versions, and php -v reports CLI, which may differ from the runtime serving the website.
Steps for a complete fix
- Inventory runtime environments. Check PHP-FPM and Apache, active containers, base images, workers, schedulers, and staging systems.
- Patch the right package source. Update the distribution package or base image to a fixed version. For PHP 8.1 and older, confirm a vendor backport in writing or plan a move to a supported branch.
- Restart every PHP process. A new package does not replace the binary already loaded by FPM or long-running workers.
- Verify every SAPI and host. Confirm the version after deployment in the environment serving real traffic, not only in a development terminal.
- Review logs. If a system was exposed, check web server and PHP logs for unusual errors and separately assess whether incident response is needed.
Limiting request sizes or disabling a feature may reduce some attack paths, but it does not replace the update. PHP states that installing a fixed release is the only complete fix.
PHP upgrades and website security in Chișinău
TAG.md offers technical audits and infrastructure upgrade support for websites, online stores, and portals. We inventory runtime environments, check application compatibility, prepare deployments, and confirm active versions after services restart. If you run a project in Chișinău or Moldova and want to verify the PHP runtime serving production, talk with us about a technical assessment.