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.2 debian-lts · 12 | See vendor advisory Source ↗ | Fix not yet confirmed in packages Checked at 2026-10-21 15:26:08 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?
Match the Debian release, security archive, LTS coverage and architecture. Third-party Sury packages are a separate source.
This PHP vulnerability guide does not infer package publication from a source upload, a planned update or a release-candidate tag.
PHP 8.2: update, restart and verify
debian-lts · Debian 12
The tracker still lists the available security package as vulnerable. A proposed or uploaded revision is not a confirmed fix.
Checked at 2026-10-21 15:26:08 UTC · Vendor source ↗
Update
sudo apt-get updateapt-cache policy php8.2-fpmsudo apt-get install -y --only-upgrade 'php8.2*' libapache2-mod-php8.2Restart
service php8.2-fpm restartservice apache2 restartVerify
dpkg-query -W -f='${Package} ${Version}\n' 'php*'php -vTested in debian:12 container (ARM64), 2026-10-21 UTC. Run only for this source and installed branch. Commands require administrator access.
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.