Back up your application and configuration, and test in staging before applying a PHP vulnerability update. Use only the package source and branch actually installed on your system.
Vendor package status
| Branch / source | Confirmed package | PHP2Shell status |
|---|---|---|
| PHP 8.1 ubuntu-archive · 22.04 | 8.1.2-1ubuntu2.28 Source ↗ | Vendor backport confirmed Checked at 2026-10-21 15:26:08 UTC |
| PHP 8.1 ondrej-ppa | See vendor advisory Source ↗ | Status not confirmed — check vendor advisory Checked at 2026-10-21 15:26:10 UTC |
A confirmed advisory records vendor publication. It does not inspect your machine. Status not confirmed means no verified package threshold is recorded for that combination.
Which source installed your PHP?
Ubuntu archive packages and third-party repositories have different revisions. The same upstream number can refer to different patch states.
This PHP vulnerability guide does not infer package publication from a source upload, a planned update or a release-candidate tag.
PHP 8.1: update, restart and verify
ubuntu-archive · Ubuntu 22.04
The Ubuntu archive includes a backport. The upstream branch remains end-of-life.
Checked at 2026-10-21 15:26:08 UTC · Vendor source ↗
Update
sudo apt-get updateapt-cache policy php8.1-fpmsudo apt-get install -y --only-upgrade 'php8.1*' libapache2-mod-php8.1Restart
service php8.1-fpm restartservice apache2 restartVerify
dpkg-query -W -f='${Package} ${Version}\n' 'php*'php -vTested in ubuntu:22.04 container (ARM64), 2026-10-21 UTC. Run only for this source and installed branch. Commands require administrator access.
ondrej-ppa
Check the exact repository, architecture and installed package revision.
Checked at 2026-10-21 15:26:10 UTC · Vendor source ↗
Update → Restart → Verify
Untested — follow vendor docs. Executable commands are withheld because this exact environment has not been tested. Back up and test in staging, apply the vendor update, restart the PHP runtime, and compare the installed package with the advisory.
Open vendor instructions ↗If you cannot update immediately
Temporary mitigation is not a complete fix. A PHP vulnerability affecting web requests needs a verified runtime update. Have your administrator assess the availability and operational impact of these measures.
- PHP lists removing the memory limit, reducing accepted POST size, and disabling session upload progress as temporary measures. Removing the memory limit can exhaust host resources.
- For the branch covered by the advisory, PHP also lists disabling fatal-error backtraces. Correct recurring startup configuration warnings and restart all workers.
- Read the exact settings and limitations in the PHP security advisory before making configuration changes.
After the PHP security update
Test critical requests, application logs, scheduled tasks and background workers. Keep a record of the package source and revision used to resolve this PHP vulnerability. If the branch is end-of-life, plan the next supported-version migration.
Plan a supported-version migration →Common questions
Why does my PHP version still look old after updating?
Distribution vendors often backport a PHP vulnerability fix without changing the upstream version. Match the installed package revision to your vendor advisory and confirm the web runtime.
Does updating command-line PHP also update my website?
It depends on your installed runtimes. The command line, PHP-FPM and a hosting panel can use different binaries. Verify the runtime serving each website after the PHP security update.
Do I need to restart PHP workers?
Yes. Follow the vendor restart procedure for all serving workers, including PHP-FPM, Apache and long-running application workers. A package update alone does not prove every process is running the new runtime.