Remediation guides
Short operational guides for the checks that come up while patching. They assume you can read the PHP advisory and your vendor errata.
RiskA practical risk assessment for PHP2ShellRank exposure by internet reach, SAPI, and whether a fixed package exists. Do not rank by the application brand.InventoryCheck the installed PHP version without fooling yourselfCLI, PATH, alternatives, and package managers report different PHP builds. Record which one you asked.InventoryCheck the PHP-FPM version that is actually runningFind the FPM binary from the process list and ask that binary, not the CLI, for its version.CompatibilityExtensions that break when PHP changesList the modules the web SAPI loads before you change branches. Rebuild custom extensions with the new headers.InventoryFind the PHP runtime that is reachable from the internetStart from the public hostname and walk back to a process. Do not start from the shell and guess.IncidentFirst day response for PHP2ShellA same-day order of operations: inventory, patch what you can, contain what you cannot, and avoid fake fixes.IncidentIf you suspect a PHP worker was compromisedPreserve evidence, remove the vulnerable runtime from the internet, and rebuild from known packages. Do not start by hunting payloads on this site.InventoryPatch every PHP version a vhost still callsSide-by-side PHP installs are normal. Updating the default binary leaves the other sockets vulnerable.ChangePlan the rollback before you upgrade PHPKeep the previous package or image, know the restart command, and define what failure looks like.ChangeReduce downtime without skipping the worker restartBlue/green and extra capacity let you restart PHP without pretending a reload loads a new binary.OperationsRestart PHP-FPM after a security updateA restart drops requests and loads the new binary. A reload may keep old workers. Know which one you are running.InventorySee whether Apache has mod_php loadedUse the module list and the MPM name. mod_php plus prefork is the layout PHP ranked highest risk.VerificationVerify a vendor backport without trusting the upstream versionCompare the package version to the vendor advisory. php -v can stay still when the fix is present.VerificationVerify the patch after the upgradeConfirm the running worker, the package version, and a real application request. A downloaded package is not yet in service.DetectionWhat to look for in logs while you patchPHP's logging advice helps you find risky configuration. It does not prove a worker was exploited or that it is safe.LegacyWhat you can honestly do with end-of-life PHPVendor backports, source backports for three branches, isolation, and migration. Configuration is not a complete fix.