PHP Patch Management Process: How to Patch PHP Safely

Reviewed by the DESSS engineering team

A PHP patch management process is a repeatable routine for finding, testing, applying and verifying updates to your PHP runtime, frameworks and dependencies. In one sentence, it is how you keep PHP applications secure without breaking them. A recent event shows why it matters: on October 21, 2026, PHP released fixes for two critical vulnerabilities that could allow unauthenticated remote code execution. If your team needs outside review, our PHP consulting services in Houston can help. Otherwise, use the phases below.

Know What PHP's Release Pattern Tells You

PHP's support policy gives each branch two years of active support, followed by two years of security fixes for critical issues only. After that, the branch reaches end of life. Here is the current picture from PHP.net:

PHP 8.6 is in release-candidate testing, with general availability planned for November 19, 2026.

In a version such as 8.4.27, the last number is the patch release. These are the updates you should expect to apply routinely. The middle number marks a new branch, and moving between branches is an upgrade project rather than a patch, because it can change behavior.

The Process, Phase by Phase

Each phase below ends in something you can show an auditor or a new team member.

1. Inventory

List each application and where it runs. Record the PHP version and how it is served, such as PHP-FPM, Apache with mod_php or a container image. Include the framework or CMS version, plus plugins and themes. Remember forgotten servers, cron workers and staging sites.

php -v shows the command-line version, and this may differ from what the web server uses, so check both.

Output: an asset register with owners and versions.

2. Monitoring and alerts

Subscribe to the sources that matter: PHP.net news, your Linux distribution's security notices, your framework's advisories and the plugin vendors you use. Add composer audit to your build pipeline. Composer documents that it checks installed packages against security advisories, also reports abandoned and flagged packages, and returns a non-zero exit code when it finds something. composer outdated --direct lists updates for packages you depend on directly.

Output: a named person receives alerts, and each one opens a ticket.

3. Risk triage

Rate each update using severity, exposure and whether exploitation is known. CVSS gives a useful starting point, with CISA's Known Exploited Vulnerabilities catalog as an important second signal. Adjust based on your own situation: an internet-facing login page ranks well above an internal tool behind a VPN.

Output: a priority and a target action for each item.

4. Test environment

Keep a staging environment as close to production as you can, with the same PHP version, extensions and configuration. Use realistic data that has been properly masked, since a small, tidy dataset hides many migration and performance problems.

Output: a test environment that matches production, with the differences documented.

5. Backup and rollback plan

Before changing anything, take a database and file backup, and confirm you can restore it. Write down exactly how you would roll back: the previous package version, container image or code release. Remember that a database migration may not be reversible simply by restoring old code.

Output: a tested backup and written rollback steps.

6. Deploy

Apply the update in staging first, run tests, then schedule production. Patch one server at a time where you can. After that, restart whatever loads PHP. Files changed on disk do nothing until PHP-FPM, Apache or your container reloads them, and a container image needs to be rebuilt and redeployed.

Output: a change record showing what changed, when and who did it.

7. Verify

Confirm the running version through the web server, not just the command line. Test login, forms, payments, uploads, APIs and background jobs. Then watch the error logs. For a serious vulnerability, also review logs from before the patch for signs of compromise.

Output: a signed-off verification record.

8. Document

Close the ticket with the versions before and after, test results and anything learned. Update the asset register too. Over time, these records show which applications are painful to patch, which is a useful signal for planning.

Output: an updated register and patch history.

Patch Types and How to Test Them

Use composer update vendor/package --with-dependencies to limit a change to a chosen package and its dependencies, then commit the resulting composer.lock.

Triage by Severity

FIRST's CVSS specification maps scores to these labels: Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. Your exposure can raise or lower the priority you assign.

Pre-Patch Checklist

• ☐ The advisory or changelog has been read for this version
• ☐ Affected applications and servers are identified
• ☐ Extensions and packages are confirmed compatible
• ☐ Update has passed in staging
• ☐ Database and file backups are complete and restorable
• ☐ Rollback steps are written, and an owner is named
• ☐ Change window and contacts are confirmed

Post-Patch Verification Checklist

• ☐ The web-served PHP version shows the new release
• ☐ PHP-FPM, Apache or containers restarted as required
• ☐ Login, forms, payments and uploads work
• ☐ APIs, cron jobs and queues run normally
• ☐ Error logs show nothing new and unexplained
• ☐ composer audit is clean, or remaining items are accepted in writing
• ☐ Records and the asset register are updated

Legacy and Unsupported PHP Versions

PHP.net lists 8.1 and everything older as end of life, and warns that these releases may expose you to unpatched vulnerabilities. The October 2026 advisory did something unusual, providing minimal source backports for 7.4, 8.0 and 8.1 because of the severity. Do not count on that happening again.

Decide first how much the business depends on the application, whether it faces the internet and whether the code can realistically move. Then choose from four options:

• Upgrade. Move through the migration guides, branch by branch if necessary. This is usually the best long-term answer.
• Isolate. Restrict network access and put the application behind a gateway. This lowers exposure without removing it.
• Extended support. Some Linux distributions and long-term support vendors backport fixes, as PHP.net notes. Confirm exactly which vulnerabilities are covered.
• Rebuild. Sensible when the framework is abandoned and the application still matters. Our PHP development company in Houston page covers this kind of work.

Common Mistakes

• Patching production first. Even low-risk patches deserve a run through staging, except in a true emergency, and you should document those exceptions.
• No rollback plan. A backup nobody has tested is only a hope.
• Ignoring dependencies. Updating PHP does not touch Composer packages, and updating a package does not patch PHP.
• Skipping staging data checks. Small datasets hide slow queries and encoding problems.
• Forgetting the rest of the stack. Your MySQL database and web server need the same discipline.

When to Bring in Outside Help

Consider help when an application is stuck on an unsupported branch, when nobody understands the code or when no staging environment exists. It is also worth a call if you have had an incident, or if patching keeps getting pushed aside by other work. Ongoing care can be covered by application maintenance, and a suspected breach deserves cybersecurity consulting right away.

Frequently Asked Questions

What is PHP patch management?

It is the routine of tracking, assessing, testing, applying and confirming updates for the PHP runtime and everything around it, including frameworks, content management systems and Composer packages. The aim is to close security holes and fix bugs without disrupting users. A good routine leaves records showing what changed, who approved it and how it was verified.

Which PHP versions are supported right now?

As of November 2026, PHP.net lists 8.2, 8.3, 8.4 and 8.5 as supported. PHP 8.4 and 8.5 receive active support, while 8.2 and 8.3 receive critical security fixes only. Security support for 8.2 ends on December 31, 2026. Check the PHP.net supported versions page before planning, since this information changes over time.

Does running composer update patch PHP itself?

No. Composer manages PHP packages in your project and has no effect on the PHP runtime. The runtime comes from your operating system packages, container image, hosting provider or a source build. In the same way, updating PHP does not change your Composer packages or WordPress plugins. Each of those layers needs its own place in your routine.

How do I check which PHP version my site really uses?

Run php -v for the command-line version, but do not stop there, since the web server may use a different build. Use a protected, temporary phpinfo page, or your hosting panel, to see the version serving web requests, then remove that page immediately. Check each pool or virtual host, because one server can run several versions.

Do I have to restart anything after patching PHP?

Yes, in nearly every case. PHP-FPM and Apache with mod_php keep the old code in memory until they are restarted or reloaded. Containers need the image rebuilt and redeployed, since an old image keeps the old PHP. Confirm the result by checking the version actually serving requests, then test the key functions and review the logs.

What should we do if we cannot upgrade an old PHP version?

Record the decision and reduce the risk. Limit network exposure, remove unused features, tighten access, monitor logs and check whether your Linux distribution or a long-term support vendor offers backported fixes. Then plan an exit, even if it takes several stages. Isolation helps, but it does not make unsupported software safe, so treat it as a temporary measure.

Need a Patch Routine That Sticks?

Talk to DESSS about your PHP applications. We can review versions and dependencies, set up a safe staging and rollback routine, and help you plan any upgrade that has been put off for too long.

Sources

• PHP.net: Supported Versions
• PHP.net: Unsupported Branches
• PHP.net: News Archive 2026 (October 21 advisory, PHP 8.6 schedule)
• PHP manual: command line options
• Composer: Command-line interface
• FIRST: CVSS v4.0 specification
• CISA: Known Exploited Vulnerabilities Catalog