Patch PHP2Shell on Ubuntu or Debian with PHP-FPM

Confirm this runbook matches your server

This guide is for an authorised administrator of a server whose PHP packages are managed through Ubuntu or Debian’s supported package channels. It is not a command list for Hostinger shared hosting, a cPanel EasyApache installation, a Plesk-provided runtime or a custom container. Those environments may use separate vendors, paths and service names. Establish the owner before changing software that a hosting control panel manages.

Prepare a recovery route you can actually use. Confirm that you can reach the management console if the web service fails, retain a current configuration copy and check that backups are recoverable. Record the maintenance owner and test contact. If there are signs of an active intrusion, preserve evidence and contain the service as part of incident response before making broad changes to the machine.

Read the operating system, packages and request path

Connect using the organisation’s approved administration method. The following inspection examples show the operating system and installed PHP-related packages. Package listings can include components that are not active; use them as an inventory, then map each public virtual host to its actual PHP service. Check the full package revision and repository origin, not only the first three version numbers.

cat /etc/os-release
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 2>/dev/null
systemctl list-units --type=service --all 'php*-fpm.service'
command -v php
php --version

Read the relevant web-server virtual-host configuration through your normal configuration management or administrator tooling. Identify whether the PHP request is sent to an FPM socket or handled through Apache mod_php. A machine can have both, and a command-line default selected through alternatives does not change a web-server socket. Document the domain, pool, service and package relationship so the update has an explicit target.

Use the correct fixed package mapping

Canonical’s advisory checked on 22 October lists Ubuntu 24.04’s PHP 8.3 fix as 8.3.6-0ubuntu0.24.04.13 and Ubuntu 22.04’s PHP 8.1 fix as 8.1.2-1ubuntu2.28. These examples demonstrate backporting: a lower-looking base version can contain the security change. Check the full current revision for your Ubuntu release and any required support entitlement; do not apply those revisions to a different distribution.

For Debian, the security tracker checked on the same date lists bookworm’s fixed PHP 8.2 source package as 8.2.35-1~deb12u1 and trixie’s fixed PHP 8.4 source package as 8.4.27-1~deb13u1 for both CVEs. Consult both current tracker entries and the relevant advisory. Testing, unstable and third-party repositories can have different status. The package candidate visible to your server must come from a channel you trust and that actually provides the relevant correction.

Check the candidate before applying the upgrade

The example below assumes Ubuntu 24.04 using its distribution PHP 8.3-FPM packages. Substitute only packages and service names already confirmed in your inventory. Read the proposed changes before proceeding. If the installed package is held, the security repository is absent, or the candidate comes from an unexpected vendor, investigate that condition instead of adding a random repository to make the numbers look current.

sudo apt update
apt-cache policy php8.3-fpm php8.3-common php8.3-cli
sudo apt upgrade --simulate
sudo apt upgrade

A full supported upgrade may affect more than PHP, so plan its maintenance scope and review failures. Where a narrowly targeted update is necessary, obtain the complete package set and dependency instructions from your distributor or administrator; do not update only the convenient CLI package while leaving the web interpreter behind. Retain the transaction output and final package revisions in the change record.

If PHP came from an external repository, the distribution notice may not establish its patch status. Ask that supplier for its advisory, fixed build and ongoing support position. Decide whether to move to distribution packages as a controlled migration. Swapping package origins during an emergency without checking extension and configuration differences can create a second outage.

Replace the service that executes the requests

After installation, replace the serving PHP processes using the method appropriate to the identified handler. For the Ubuntu 24.04 PHP 8.3-FPM example, a controlled restart is shown below. Plan for interrupted requests and supervise recovery. If Apache uses mod_php, the Apache service is the relevant interpreter host; restarting only an unused FPM service would not address it. If multiple FPM versions serve sites, cover each affected service.

sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm
systemctl show php8.3-fpm -p MainPID -p ActiveEnterTimestamp -p ExecStart
journalctl -u php8.3-fpm --since "15 minutes ago" --no-pager

The service timestamps and successful restart help demonstrate process replacement, but they do not identify the security content of the installed package. Use them alongside the vendor revision mapping. Where a load balancer or more than one server is involved, record the operation for every node and ensure a node that failed its update cannot silently rejoin later.

Verify PHP through the website’s actual handler

Use a protected operational diagnostic or existing application health mechanism to confirm the web request reaches the expected SAPI, pool and build. Do not publish a phpinfo page on the public internet to collect evidence. If a temporary diagnostic is unavoidable, restrict access before deployment, return only the minimum required fields and remove it afterwards. A cached homepage cannot tell you which interpreter processed the contact form.

Treat disagreements as evidence to investigate. For example, a correct CLI revision with an older web build usually points to a second package, socket or deployment route. Do not suppress the mismatch just because the public page renders.

Test business functions and keep rollback secure

• Open an uncached dynamic page and inspect server errors, response status and latency.
• Test login, logout and session continuity where the site has accounts.
• Submit a non-sensitive test enquiry using an approved test mailbox and confirm the result.
• Exercise checkout in the payment provider’s test mode, never with invented live card details.
• Verify scheduled jobs, background consumers, required PHP extensions and application logs.

Define a fallback that does not simply restore the vulnerable interpreter. A corrected alternate pool, a compatible fixed image or a static maintenance response can be safer than an old snapshot reopened to the internet. If an application is incompatible, keep the affected service isolated while resolving the issue. Record the failed test and the chosen containment rather than marking the patch complete for administrative convenience.

Example: the command line is fixed but one site is not

Imagine a server with two websites: one uses the distribution FPM pool, while an older subdomain points at a second custom pool. An administrator updates PHP and verifies the shell version, but the subdomain continues using the other service. Mapping both virtual hosts to their sockets exposes the gap. The team updates the second runtime through its actual supplier, replaces its workers and retests the affected domain.

A good final record includes the distributor advisory, previous and final package revisions, repository origin, each runtime service, restart time and business test outcomes. Log retention and intrusion review remain separate tasks. This workflow provides evidence for patch deployment without pretending that an operating-system update is a complete hacked-website recovery investigation.