What to Do After a PHP Security Advisory Is Published

The first hour: understand what was released

PHP security fixes usually arrive as coordinated patch releases across all supported branches, announced on the PHP releases page and described in php-src security advisories. Before touching a server, collect these facts:

Question	Where to find the answer
Which CVE IDs are involved?	Release announcement, ChangeLog, advisory
What is fixed in each branch?	Per-branch fixed version, for example 8.3.36
How severe is it?	CVSS score and vector in the advisory or NVD
What conditions are required?	SAPI, OS, extension, function or configuration
Is it being exploited?	Advisory notes, vendor and security community reports

Throughout this guide we use the 2026-10-21 release as an example. PHP published 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, two remote code execution vulnerabilities scored 9.2 under CVSS v4.0, affecting PHP 5.4 through 8.5.11. Branches 8.1 and older, being end of life, received no fix.

If the range notation is unfamiliar, read understanding PHP CVEs and affected version ranges first.

Step 1: Decide how urgent this is for you

A simple triage helps you avoid both panic and complacency.

Signal	Raises urgency	Lowers urgency
Impact	Remote code execution, authentication bypass	Local-only, minor information leak
Preconditions	Default configuration, common SAPI	Rare platform or disabled extension
Exposure	Public websites, upload forms, APIs	Internal tools behind a VPN
Exploitation	Public proof of concept, active attacks	No known exploit

Critical RCE issues affecting default configurations, such as the October 2026 pair, should be treated as same-day or next-day work for internet-facing systems. Lower-severity issues with narrow preconditions can usually wait for your next scheduled maintenance window, as long as that window exists and is not months away.

Step 2: Build an inventory of affected runtimes

You cannot patch what you do not know about. List every place PHP runs:

Web servers and their PHP-FPM pools or Apache modules
CLI interpreters used by cron jobs, queue workers and deployment scripts
Container images, including base images in CI pipelines
Staging, development and forgotten legacy servers
Shared hosting accounts and managed WordPress sites

For each, record the exact version and its source (upstream build or distribution package). On servers you control:

php -v
ls /usr/sbin/php-fpm* 2>/dev/null
dpkg -l | grep -E '^ii\s+php'     # Debian / Ubuntu
rpm -qa | grep -i '^php'          # RHEL family

For containers, check the image tag and the version inside it:

docker run --rm your-image:tag php -v

For sites without shell access, WordPress Site Health (Tools → Site Health → Info → Server) or the hosting panel shows the version. The PHP version checker tells you quickly whether each upstream version falls inside the affected ranges, and the how to check your PHP version guide covers each method in detail.

Step 3: Patch in order of exposure

Work from most exposed to least exposed: public production sites first, then internal systems, then development environments.

Upstream builds and hosting panels

Move to the fixed patch release in the same branch. This is a low-risk change; patch releases within a branch are intended to fix bugs and security issues without breaking compatibility. For the example release, that means:

Current branch	Target release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

On managed hosting, the provider usually rolls out patch releases. If your panel still shows an older patch version a few days after the release, open a ticket and ask for a specific date.

For containers, rebuild images on the updated base image and redeploy. Updating the tag in a Dockerfile without rebuilding and redeploying changes nothing in production.

Distribution packages

Install updates through the package manager:

sudo apt update && sudo apt upgrade        # Debian / Ubuntu
sudo dnf upgrade --security                # RHEL family

The package version will not necessarily match the upstream fixed release, because distributions backport fixes. Confirm the specific CVE IDs are addressed using the steps in checking whether a PHP security patch is installed. If your distribution has not yet published a fix, record that, apply mitigations, and check again.

End-of-life branches

If a server runs 8.1, 8.0 or 7.x, there is no upstream patch release to install. Unless your vendor provides a backported fix and you have verified it for these CVE IDs, the only real remedy is upgrading to a supported branch. That is a larger change, so:

Apply mitigations now (Step 4).
Start a compatibility-tested upgrade immediately, following PHP upgrade planning.
Set a firm date and track it.

Step 4: Mitigate where you cannot patch yet

Mitigations reduce risk; they do not replace the fix.

Restrict access. Put admin panels, staging sites and internal tools behind authentication, IP allow-lists or a VPN.
Disable unused components. If the vulnerability lives in a SAPI or extension you do not use, remove or disable it.
Use a web application firewall rule if your provider publishes one for the specific CVE, and test that it does not break your site.
Reduce information leakage. Set expose_php = Off so the X-Powered-By header stops advertising your version, and remove any leftover phpinfo() files. This does not fix anything, but it makes you a less obvious target for automated scans.
Increase monitoring. Watch web server and PHP error logs for unusual requests, crashes and new files in writable directories.

; php.ini
expose_php = Off

Step 5: Verify the fix is live

The most common failure after patching is a service that was never restarted.

Restart PHP-FPM or the web server:
```
sudo systemctl restart php8.3-fpm
```
Confirm the version the web server uses, not just the CLI: check Site Health, the hosting panel, or a short-lived phpinfo() page that you delete immediately afterwards.
Run the result through the CVE checker or your vendor’s tracker.
Recheck the public site with the website security checker for exposed version headers and similar issues.

Step 6: Record what you did

A few lines per system is enough. An illustrative log for three hypothetical servers:

2026-10-22  web-01  PHP 8.3.35 -> 8.3.36 (upstream)   FPM restarted 14:10 UTC   verified
2026-10-22  web-02  distro php package   CVE IDs checked in changelog   result recorded
2026-10-22  legacy  PHP 8.1.34 (EOL)   no fix   restricted to VPN   upgrade ticket due 2026-11-15

This record helps you answer questions from clients or auditors, and shows which systems keep falling behind. Systems that appear on every advisory list are the ones to prioritise for an upgrade or retirement.

Prepare for the next advisory

Keep the inventory from Step 2 current instead of rebuilding it each time.
Subscribe to PHP release announcements and your distribution’s security notices.
Stay on supported branches, so every future fix has somewhere to land.
Automate patch-level updates where your tooling allows, with monitoring to catch regressions.