Update the runtime, then make the old workers leave

01Does this apply to you?

02Steps

The sequence matters more than the command. Read the vendor note, stage the change, record the rollback, install, restart, and only then call it patched.

1. Platform engineer

   Choose the target from your branch, not from a headline

   Pick the fixed version on the branch you already run: 8.2.35 for 8.2, 8.3.36 for 8.3, 8.4.27 for 8.4, or 8.5.12 for 8.5. Moving branch is a migration decision, not a patch step.

   If you run a distribution package, the fixed version will include the distribution's own suffix. Ubuntu and Debian publish their own fixed package versions; use those, not the upstream number as a threshold.

   PHP 8.2 is in security-fix-only support until 31 December 2026. A fix on 8.2 is valid, but the branch has a short remaining life and should be in your migration plan.

   You should see A single target version and source are written down for each service, with the vendor notice that supports it.

   If it fails If the vendor has no fixed package for your suite, do not infer one from the upstream release. Record the gap and ask the vendor; use interim measures only as a temporary control.
2. System administrator

   Read the vendor's package note before you touch a server

   Distribution security notices state the exact fixed package version and the advisory identifier. They also tell you whether older releases need an extended-support subscription.

   For example, Ubuntu published USN-8948-1 and USN-8948-2 with fixed packages for 22.04, 24.04, 26.04 and 26.10; older releases are covered through Ubuntu Pro or ESM. Debian published DSA-6574-1 for trixie and DLA-4848-1 for bookworm.

   Red Hat's CVE page rated the issue Important but did not show a product impact table or fixed errata when checked. That is a reason to check the exact RHEL release and repositories, not a reason to declare it fixed or unfixed.

   You should see The fixed package name and version for each distribution are recorded next to the inventory row.

   If it fails If the only evidence is a general statement that “packages are available”, ask for the advisory identifier and the fixed version.
3. Application owner

   Stage the change and define the regression list

   Apply the update to a representative staging node or image. A staging environment that shares no configuration with production is a rehearsal, not a test.

   Write the business regression list before testing: sign-in, the primary transaction, uploads, email or queue delivery, scheduled jobs, and the administrative path. “The home page loads” is not a regression test.

   Note any extension that is loaded from a custom build. A PHP minor update can expose extension ABI or configuration differences.

   You should see A staged change and a written list of checks with an expected result for each.

   If it fails If staging cannot represent production, shorten the change window and increase the rollback readiness. Do not pretend the risk is lower.
4. Change owner

   Record the rollback before the change

   For a package, record the exact previous package version so it can be reinstalled from the repository or a local cache. For a container, record the previous image digest. For a source build, record the previous build artefact.

   Write down how the rollback will be triggered and who can authorise it. A rollback plan that exists only in someone's memory is not a plan.

   Check that the old package or image is still retrievable. Retention policies have a habit of deleting the version you need.

   You should see A rollback reference and an authorised trigger are recorded before installation.

   If it fails If the previous artefact cannot be retrieved, treat the change as higher risk and get an explicit decision before proceeding.
5. System administrator

   Install the update from the correct source

   Use the package manager for distribution packages, the official image for containers, and your normal build pipeline for source builds. Do not copy a binary from another host.

   The commands below are examples, not a universal procedure. Package names, repository pinning and service names differ between systems. Run the read-only query first and confirm what will change.

   For containers, rebuild the application image on the patched base and pin the base by digest. Pulling a new tag does not replace a running container.

   Example: inspect the candidate package (Debian/Ubuntu) Copy

   apt-cache policy php8.4-fpm   # read-only: confirm candidate and installed versions first

   You should see The package or image is updated on the target node, and the installed version matches the vendor notice.

   If it fails If the package manager offers an older candidate than the vendor notice, check repository pinning and the security suite. Do not add arbitrary third-party repositories to close the gap.
6. Platform engineer

   Restart the service so the new binary is in memory

   For PHP-FPM, a package upgrade replaces the binary on disk. A graceful reload asks the existing master to re-read configuration and restart workers, but workers forked from an old master can still use the old code. Use a full service restart, then confirm the master and workers have new start times.

   For Apache with mod_php, restart Apache rather than assuming a configuration reload replaced the loaded module. For containers, replace the containers; restarting a container that still references the old image does not help.

   After the restart, check that no worker from before the installation is still serving. Process start time is the simplest evidence; a worker started before the install did not load the new binary.

   Example: restart and inspect FPM start times Copy

   sudo systemctl restart php8.4-fpm && ps -eo pid,lstart,cmd | grep '[p]hp-fpm'

   You should see Every master and worker process started after the package installation.

   If it fails If old workers remain, find the supervisor, container or service unit that owns them. Killing individual workers is not a durable fix; the supervisor will recreate them from the old master.
7. Platform engineer

   Apply interim measures only where the patch is not complete

   PHP's advisory lists measures that reduce specific attack paths. They are not a substitute for the update. If you cannot patch a system today, use them deliberately and record the residual risk.

   For the OOM path, memory_limit=-1 set administratively removes the controllable limit, but an underlying allocation failure can still reach the vulnerable code. Keep post_max_size conservative and enforce request limits at the proxy or web server.

   For the stale-state path, set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration, then restart every worker. Do not use ini_set() or .user.ini for this. On PHP 8.5, fatal_error_backtraces=0 removes the demonstrated fatal-backtrace path only.

   PHP's 23 October note says the session upload progress issue can affect patched releases. If you applied session.upload_progress.enabled=0 on 21 October, keep it until the next regular bugfix release.

   You should see Each interim setting is recorded with its scope, its limit and the date it will be removed.

   If it fails If an application overrides the setting at runtime, the administrative value may not hold. Check the effective value from the web SAPI, not from the CLI.
8. Change owner

   Record the change and hand it over

   Record the package or digest, the restart time, the rollback reference, the regression result and any residual settings. Use the technical handover template if the next person is not in the room.

   Do not close the change as “patched” until verification has evidence from the running service. Installation is an action; verification is a conclusion.

   You should see A handover record that another engineer can audit without asking you what happened.

   If it fails If the record is incomplete, write down what is missing. A vague record is worse than an honest gap because it looks like evidence.

03What usually goes wrong

05Where to go next

06Sources and revision

Every operational claim on this page was checked against the documents below on 23 October 2026. This page was last substantively changed on 23 October 2026.

See the full revision log for what changed on this site.