PHP2Shell fix guide for Debian

Identify release and installed PHP packages

Debian 12’s published update is 8.2.35-1~deb12u1 in DLA-4848-1. Debian 13’s PHP 8.4 update is 8.4.27-1~deb13u1 in DSA-6574-1. A host using another repository needs that supplier’s patch evidence.

Inventory installed extension packages as well as the FPM or Apache integration. The package meta-name php does not by itself identify the runtime serving a particular site.

cat /etc/os-release
dpkg-query -W 'php*'
apt-cache policy php8.2-fpm php8.2-common

Before you change the runtime

Record the current package revision, runtime handler, configuration and deployment topology. Confirm a current fix for both CVEs from the responsible vendor. Back up application data and configuration using a tested restore process. If an incident is suspected, preserve evidence before changing processes or files.

Test the intended PHP build with the application, extensions, scheduled jobs and database in staging. Plan a maintenance window or a rolling change with health checks. Keep a configuration and application rollback plan; do not restore a vulnerable runtime to public traffic without restricting exposure.

Update the packages you confirmed

Refresh package metadata through the approved APT workflow, inspect candidates and review the transaction for your installed PHP branch. Apply the supported security updates, then restart the actual FPM service or Apache process that loads the module.

Do not substitute a Debian 13 PHP 8.4 command into a Debian 12 PHP 8.2 installation. Check the enabled security repository and support coverage if no fixed candidate appears. A completed APT command without a fixed candidate is not proof of remediation.

Verify all handlers and pools

Confirm the complete installed revision, loaded module or FPM executable, worker startup time and domain handler mapping. Test application behavior after replacement and retain the advisory and transaction evidence with your change record.

Verify the result and handle a delayed patch

Check the actual web-serving binary, package revision or image on every instance. Replace old workers and verify their startup times. Validate application health, uploads, sessions, queue workers and scheduled jobs. CLI output alone does not prove what serves HTTP requests.

If a fixed deployment fails compatibility checks, restrict access and escalate to your vendor or administrator. Temporary WAF or configuration changes may reduce specific attack paths but are not a complete substitute for patching. Investigate suspicious activity separately: a successful update cannot establish that the system was never compromised.