PHP published fixes for supported branches. Distribution and hosting packages may include backports with different version strings; check the vendor advisory before deciding that an installation is still vulnerable.
What PHP disclosed and why it matters
On October 21, 2026, the PHP project released fixes for CVE-2026-109618 and CVE-2026-109619, two critical runtime flaws. Under specific conditions they can allow unauthenticated remote code execution on PHP installations serving web requests. PHP advises treating web-serving installations as at risk until their version and vendor patch status are checked.
CVE-2026-109618 concerns corruption of internal state during out-of-memory handling. CVE-2026-109619 describes global state that can retain references to memory from an earlier request. You do not need to reproduce or test an exploit to manage the patch: this guide focuses on a controlled update and checking that the application still works.
The PHP advisory highlights particular risk for Apache with mod_php. It also lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Actual exposure depends on the runtime, configuration and application paths; do not assume every deployment has the same exploit scenario.
Affected and fixed versions
This table summarizes upstream releases published by PHP on October 21, 2026. “Fixed from” is the first upstream release in that branch with the official fix. For operating-system packages, provider images or managed PHP hosting, also check the vendor advisory: a backport may be applied without changing the upstream version shown by a command.
PHP 8.2 security support is scheduled to end on December 31, 2026. Updating to 8.2.35 addresses these CVEs on that branch according to the upstream release, but plan a move to a branch that remains supported. PHP says 8.1 and older no longer receive regular project releases; it published minimal source backports for 7.4, 8.0 and 8.1, and some distributions/LTS vendors may maintain their own patches. Confirm the exact package you receive and follow your provider’s guidance.
| Upstream branch | Vulnerable before | Fixed from | Security support |
|---|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 | Supported |
| 8.4 | < 8.4.27 | 8.4.27 | Supported |
| 8.3 | < 8.3.36 | 8.3.36 | Supported |
| 8.2 | < 8.2.35 | 8.2.35 | Until Dec 31, 2026 |
| 8.1, 8.0 and 7.4 | Affected; EOL branches | Minimal source backport or vendor package | Confirm availability and support with provider |
| 7.3 and earlier | Affected; EOL branches | No upstream release listed in the advisory | Migrate; consult provider and do not assume a patch |
Read the cutoff within each branch: versions before the listed release need patch verification. Distribution packages may use backports and a different version string.
Before updating: inventory and preparation
Find every way PHP reaches production: host packages, containers, base images, hosting panels, runtimes bundled with products, workers and staging environments. A site may run multiple versions. Identify which service receives traffic and which team controls each update.
Record the version and package source, operating system, web server, runtime, image if applicable, application, environment, owner and the plan for restoring the previous version if something fails. Do not publish `phpinfo()`; it can reveal sensitive configuration. Use internal inventory, provider consoles or commands approved by the environment owner.
Read vendor notes and migration guides if the change crosses a PHP branch, rather than applying a same-branch patch only. Prepare a maintenance window, recoverable backup, rollback criteria and a decision owner. For managed services, request written confirmation of the patch and any required worker restart or redeploy.
A controlled update sequence
- Prioritize Internet-facing services and check whether the provider has published the fixed package.
- Update a representative environment using the operating system, hosting or image provider instructions.
- Rebuild and deploy containers from a fixed image; updating the host does not automatically change PHP inside an image.
- Restart or replace PHP processes according to the provider’s procedure so workers load the updated runtime.
- Confirm the version and package in the environment that actually receives traffic, not just from another terminal.
- Run the basic checks and prioritized regression tests.
- During the agreed window, review application errors, logs and metrics.
- If something critical fails, pause the deployment, record what happened and restore the previous version according to the agreed plan. A WAF rule or temporary mitigation does not replace the patch: PHP says the complete fix is to update.
- 01Inventory runtimes
- 02Apply provider patch
- 03Confirm active process
- 04Run regression
- 05Review evidence and risk
- 06Decide deployment
How to build the regression plan
Post-patch regression looks for unintended effects in the product and its integrations. It does not prove that the runtime is free from vulnerabilities, and does not replace security scanning, dependency analysis or configuration review. Keep those objectives separate, with their own tools and owners.
Scope the change: runtime and old/new versions, services, configuration, extensions, dependencies and environments. Map which flows pass through PHP and what could share workers, sessions, cache, files or queues. Prioritize by business impact, exposure and recovery difficulty. Record unknown dependencies as open risks instead of assuming they do not exist.
Split execution into three layers: smoke tests for availability and essential functions; focused regression for changed or dependent paths; and a broader suite for high-impact components. Results should retain build/release, runtime, environment and data so a difference can be investigated and repeated.
Suggested test case catalog
Adapt these examples to the system’s actual architecture and rules. They are not a universal test pack: remove what does not apply and add your own flows, extensions and integration contracts. Use test accounts and synthetic data, never real secrets or personal information.
| Area | Example case | What to check | Useful evidence |
|---|---|---|---|
| Availability | Startup, health check and primary route | Healthy process; expected response and available dependencies | Build, environment, time, HTTP status and redacted log |
| Authentication | Sign in, sign out and session expiry | Valid session, revocation and expected redirect | Fictional account, steps and outcome; never password/cookie |
| Authorization | Allowed and denied access by role | Effective permissions and response to unauthorized access | Role, resource, expected/actual outcome and request ID |
| Forms and flows | Create/edit entity or critical business flow | Validation, persistence, messages and business rules | Synthetic data, steps, redacted capture and related record |
| API and integrations | Success, error and timeout contracts | Status, schema/fields, auth and failure handling | Sanitized request/response, version and dependent service |
| Files | Authorized upload, read and download | Allowed type/size, storage and permissions | Synthetic file, metadata, outcome and logs without sensitive content |
| Async work | Queue, scheduled task and retry | Expected execution count, final state and error handling | Task ID, timestamps, state and redacted output |
| Data and sessions | Persistence across requests and workers | Consistency, user isolation and session continuity | Fictional IDs, request sequence and before/after state |
When is the regression complete?
Define deployment blockers before execution. At minimum, do not promote if authentication, authorization, a critical operation, data integrity or an essential contract fails; if the fixed runtime cannot be confirmed; or if new errors remain unexplained. A case blocked by environment or data is not a pass.
To close, review coverage against scope, failed/blocked/pending results, evidence, linked defects, residual risk, decision and owner. An all-green suite only describes the cases that ran: it does not prove every PHP component was covered or that every server has the patch.
Closeout checklist
- Inventory includes PHP bundled in hosts, containers and providers.
- The package source and advisory used to verify the patch are recorded.
- Processes serving traffic were restarted/redeployed per provider guidance.
- Build, environment, runtime and synthetic data are recorded for each run.
- Failures, blockers, pending work and residual risks have an owner.
- Captures, logs and payloads were checked for secrets and personal data.
Keep regression reviewable as QA evidence
Treseko can organize cases, suites, builds, executions, results, bugs and attachments so a team can review what it checked and which risks remain open. A regression example must be configured and run by the team in its own environment: Treseko does not install the patch, automatically discover every PHP instance or certify a CVE fix.
Official sources and resources
- PHP official security advisory
- CVE-2026-109618 advisory (PHP/GitHub)
- CVE-2026-109619 advisory (PHP/GitHub)
- Supported PHP branches
- Official PHP downloads
- PHP 8.5 migration guide
This is educational QA material, not incident-response advice, and does not replace instructions from PHP, an operating system, container or hosting provider. Last reviewed: October 21, 2026.