What lies behind the name PHP2Shell
PHP2Shell is the name used for two PHP engine vulnerabilities: CVE-2026-109618 and CVE-2026-109619. The official announcement on 21 October 2026 describes the possibility of unauthenticated remote code execution.
The first issue concerns handling a situation where available memory is exhausted. The second concerns internal state retained between requests. In both cases, the error is in the runtime, beneath the application code.
An updated CMS does not automatically mean an updated server
The PHP team’s risk assessment includes installations serving web requests: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest demonstrated risk is for mod_php. Recognising the CMS name alone is not enough for an administrator.
For a WordPress website, updating the core or a plugin does not necessarily change the PHP version used by the server. These are two separate layers whose responsibilities and procedures need to be coordinated.
Versions including initial corrections
The versions in the table are those announced at disclosure. For a later intervention, choose a supported version with current security updates, or a patched package confirmed by the distribution vendor.
| PHP Branch | Patched version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
PHP inventory commands
Run these commands in the terminal of the environment you are checking, with PHP available in PATH. They display information and do not install updates. For containers, check inside the application environment, not only on the host.
php --version
php --iniThe CLI version can differ from PHP-FPM or the module used by the website. This result alone does not confirm that the web application has received the fix.
How to complete remediation
We recommend an inventory of websites and their runtimes before making changes. A single machine can have several PHP versions, and the command-line version can differ from the one used by the website.
The intervention should leave verifiable evidence of the running version and application functionality. A success message from the package manager is only one step in the process.
- Identify PHP service and package used by each website.
- Prepare a backup and a compatible rollback option.
- Apply the update and restart the processes that need to load the new version in a controlled way.
- Check the essential pages, forms, orders and scheduled tasks as appropriate.
- Confirm active version and track errors after intervention.
Track the update through to the last package
On 23 October, the PHP team also published a recommendation concerning session.upload_progress.enabled for an unusual configuration combination. On 26 October, rebuilt Windows packages appeared with a Brotli fix. These are separate details that need to be checked in the current announcements.
For the team operating the website, the practical conclusion is to document the runtime, dependencies and checks performed. Monitoring and traffic filtering complement this work; they do not replace applying patches.
Sources and verification
The technical information was checked on 31 October 2026. Package status and vendor recommendations can change; consult the current announcement for the product in use before making changes.