PHP Security Update October 2026: How to Verify Your Web App Is Patched

The PHP security update October 2026 needs more than a successful package-install message. Check the PHP runtime that serves your web app, match its build to the fix, and keep evidence that the new runtime is in use. A terminal check alone may describe a different installation.

Checked 25 October 2026. PHP’s October 21 release addresses two critical vulnerabilities. A separate October 23 session advisory adds a configuration review. Our four-branch comparison also shows why patching PHP 8.2 and planning its migration are different tasks: upstream security support ends in 67 calendar days.

This report is for US coding learners, junior web developers and instructors managing their own apps. It combines official release data with an original evidence-register template. We did not scan sites, test exploit code or inspect any reader’s deployment. The five visuals separate published facts, date calculations and practical checklists.

PHP security update October 2026: which releases contain the fixes?

The PHP Security Team’s first advisory identifies the fixed releases for CVE-2026-109618. Its second advisory covers CVE-2026-109619. The four supported branches received releases on October 21. Check the branch first; a larger final number in a different branch is not a useful comparison.

PHP’s release notice covers installations serving web requests and identifies Apache mod_php as its highest demonstrated risk. It also includes PHP-FPM and other web handlers in the affected scope. Do not assume that using a different handler removes the need to update.

Older branches need particular care. A distribution or long-term-support vendor may backport a fix without using the upstream release number shown above. In that case, keep the vendor notice, exact package build and installed-package evidence together. Ask your hosting provider to identify the build serving your site when that information is outside your control.

Why a patch does not remove the PHP 8.2 migration deadline

PHP’s supported-versions table separates active maintenance from security-only support. As of the check date, 8.2 and 8.3 are in the security-only phase. PHP 8.4 and 8.5 have later active-support dates. A security release for 8.2 does not extend its upstream end date.

The calculation is December 31, 2026 minus October 25, 2026: 67 elapsed calendar days, excluding the starting date. We used the same method for every branch. This lets an instructor explain two work items clearly: install the current fix, then choose and test a supported migration path. It does not imply a 67-day grace period for patching.

For a portfolio app, start with a copy of the project and a clear recovery plan. Record the PHP target, required extensions and framework constraints. Then check the app’s supported-version guidance. Treat compatibility work as a planned task rather than a reason to leave an exposed runtime unreviewed.

Check the runtime that actually handles web requests

A machine can have a terminal executable, a web-server handler and a long-running worker using different runtimes. Containers can add more copies. Therefore, begin with a list of the execution paths that your application actually uses. Keep local development, staging and production as separate entries.

The official phpversion() documentation explains how to identify the running PHP version. The php_sapi_name() documentation identifies the interface between PHP and the web server or calling process. Together, they help you describe which runtime produced a result.

For example, a terminal result may identify the CLI interface, while a protected application diagnostic identifies a web handler. That difference is a prompt to investigate the deployment path. It is not, by itself, proof of a failed update. Match each observation to the intended service, package and configuration.

Keep these diagnostics private. Use an approved administrative view, a restricted diagnostic route or internal logs appropriate to your project. Avoid publishing a general configuration page. Record the facts needed for verification without copying credentials, environment secrets or unrelated server details into a shared worksheet.

Review the October 23 session advisory as a separate check

PHP’s October 23 informational advisory describes an unusual combination of session settings and application behavior. It is separate from the two October 21 fixes. The notice suggests setting session.upload_progress.enabled=0 until the next regular bugfix release. If you already applied that setting, keep it in place as advised.

The notice distinguishes applications that never change their session serializer at runtime. Do not turn this into a claim that every updated installation has the described exposure. Ask the application owner to review both configuration and code, then record the result and any unresolved question.

Use the ini_get() reference when checking a configuration value in the relevant runtime. A file you edited is not necessarily the configuration that a given service loaded. Keep the observed value with the service identity and verification date. Have the responsible operator apply any needed production change through the normal deployment process.

Build a patch-evidence record you can explain

A useful handover answers three questions: what changed, where it runs and what evidence remains. Our blank CSV register provides one row per application or service. Keep an entry open when evidence is missing. A check box without a package build or runtime observation is not a substitute for that evidence.

After the normal update and restart procedure, check the service again. For a multi-instance deployment, ask how the rollout verifies every intended instance. A response from one instance should not silently stand in for an entire fleet. Keep that scope explicit even on a small teaching project.

Next, run the app’s normal regression checks. Cover the paths that matter to the project, such as authentication, sessions, file handling and background work. Record which checks ran and which did not. Passing tests supports application behavior; it does not establish that a particular security patch is installed.

For broader context, our software security practices guide explains how reviews, updates and monitoring fit together. Our older PHP application-vulnerability guide is background reading. Neither replaces the current PHP runtime advisories linked here.

Downloads, method and limitations

Download the PHP branch and support data (CSV), or use the blank patch-evidence register (CSV). The data file contains four branches, their first October 21 fixed releases, security-support end dates and elapsed days from October 25. The register has a header and one empty template row; it contains no audited deployments.

Our analysis transcribes official release and lifecycle information, then subtracts calendar dates. The evidence map and checklist are original editorial tools. We did not measure exposure, exploitation, patch adoption or test success. No charts show a national or US-specific vulnerability rate. US readers use the same upstream releases while checking their own vendor and hosting arrangements.

These advisories can change. Recheck PHP and your package vendor before acting on a version reference. If you suspect an incident, involve the person responsible for security response and preserve relevant evidence. This guide provides a verification workflow; it cannot certify an unseen system as secure.

Suggested citation: Learn Coding USA, “PHP Security Update October 2026: How to Verify Your Web App Is Patched,” checked October 25, 2026. Cite the PHP advisories for the security findings and this report for the calendar-day calculation and reusable register.