Fixing PHP2Shell: upgrade and verify PHP step by step

1. Understand the risk

Both PHP flaws can be reached through web requests. Successful exploitation could allow code execution with the PHP worker’s privileges, potentially leading to modified files, exposed data or keys, or an outage. The PHP project advises checking every web-facing PHP installation, with particular urgency for mod_php.

Open image full size

2. Identify the PHP runtime serving web requests

1. List all websites, subdomains, PHP-FPM pools, Apache mod_php servers, containers, and provider-specific PHP handlers.
2. In your hosting panel, check the PHP branch and handler selected for each domain. On a VPS, inspect the versions of running PHP-FPM or Apache services and their packages.
3. Treat `php -v` as a check of the CLI only. The web SAPI may differ. If you verify it with a diagnostic file, restrict access to authorized internal users and delete the file immediately afterward.
4. Record the package source, build date, and vendor advisory for both CVEs. A package with an older version number may still contain a backported fix.

php -v
php --ini
systemctl list-units 'php*-fpm.service' --all

3. Choose a patched version

PHP 8.1 and older branches no longer receive normal upstream updates. The PHP project provided exceptional source backports for 7.4, 8.0, and 8.1, but this does not reinstate support. For distribution packages, check the security changelog as well as the version number.

4. Back up, then upgrade

1. Make a verified backup of the website files, database, and relevant configuration, and record a brief rollback plan.
2. Test the selected PHP branch with your application and required extensions, then install the patched upstream release or verified vendor package.
3. For containers, build a new image from a patched base image and replace running instances. In Plesk, update both the sites’ PHP handlers and Plesk’s own `sw-engine`/`plesk-engine` component.
4. Restart or replace all affected PHP workers. Installing a package alone may leave old processes running vulnerable code.

5. Verify the live website

1. After upgrading, verify the actual web-facing PHP branch and vendor patch status for each affected domain, not just the CLI version.
2. Test the homepage, login, forms, file uploads, payment flow, and scheduled tasks if you use them.
3. Confirm that every FPM pool, Apache worker, or container has been replaced, and check the error log after the upgrade.
4. Record the version, package release, time of verification, and domains checked. If you have several sites, verify each one separately.

6. If an upgrade is temporarily impossible

• According to the PHP advisory, `session.upload_progress.enabled=0` may block some confirmed session-related attack paths. Set it at the server or pool level before request processing, then restart every worker.
• `memory_limit=-1` may remove one trigger involving PHP’s memory limit, but increases the risk of resource exhaustion and is not a complete fix. Use it only after operational review and with separate resource limits.
• Limit upload and request sizes according to the application’s needs. The official PHP examples use an 8 MB `post_max_size`, or 32 MB when uploads are required.
• If you cannot verify the patch, you may need to temporarily restrict or shut down the affected service.

7. If you suspect a compromise

1. Preserve web, PHP, and system logs, timestamps, and the state of running services. Do not delete evidence indiscriminately.
2. Isolate the affected system from further access and seek incident-response assistance.
3. Investigate modified files, new users, suspicious processes, and outbound connections. Patching does not remove malware already placed on the system.
4. Based on your investigation, rotate affected passwords, tokens, and keys. If needed, restore from a clean backup and verify the patch again.