October 2026 PHP vulnerabilities: website checks
October 21, 2026 PHP developers have released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both are related to request processing and can lead to remote code execution under certain conditions. For the owner of a site on WordPress, 1C-Bitrix or his own PHP application, the task is to confirm the correction of the environment that actually serves visitors.
The new PHP number in the SSH console confirms the version of the called binary. The site can continue to work through another PHP-FPM, control panel package, or old container. Therefore, the check should cover the web process, background jobs and critical functions: login, applications, orders and integrations.
Information about releases and clarifications has been verified November 2, 2026. Below is the inspection and acceptance procedure for the person responsible for the site and the administrator. It does not establish whether a specific project has been hacked, nor does it replace package verification by its vendor.
Which PHP versions contain initial fixes
In official advisories out of memory error and about saving state between requests The first fixed releases of the supported branches are indicated:
| Branch | First release with fixes for two CVEs on October 21 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
The table applies to the two vulnerabilities listed. Please check your branch's latest patches and subsequent security messages before upgrading. For a distribution package, its full revision and the supplier's bulletin are also taken into account.
So, in cPanel table EasyApache and CloudLinux options are listed separately. Some patched packages retain the earlier version number of the original PHP version with the changed revision. This is an example of a backport: the vendor backports the fix to its own supported build. The presence of such a fix must be confirmed for a specific package; Just guessing the name of the OS is not enough.
Which October clarifications should be taken into account separately?
By PHP post October 26, Windows packages rebuilt with Brotli 1.2.1. Suffix -1 refers to the package build, the version of PHP itself remains the same. Therefore, for Windows, keep information about the complete installed package and its origin.
For a specific problem CVE-2026-115560 PHP published a clarification on October 23rd. A rare combination of settings and code when working with session upload progress is described. IN cPanel post updated October 28, the temporary setting is given session.upload_progress.enabled=0. Have an administrator verify that the fix is applicable and in effect; the change must be included in the required server configuration and pass the site functionality test.
For the original two CVEs, timing restrictions have incomplete coverage. Installing the patched code remains the main activity. Don't copy a random set of parameters php.ini as a universal proof of safety.
PHP update acceptance checklist
Check off the items after receiving confirmation from the person responsible for the site.
This list helps to compile the report. The applicability of patches and the state of the running environment are confirmed by the administrator or hosting provider.
First find the PHP that is serving the site
Create a list of components. Different handlers for the main domain, the old subdomain and the administrative service can coexist in one hosting account. Import of goods, generation of documents and processing of queues can work in a separate environment.
| Component | What to record | How to confirm after updating |
|---|---|---|
| Main site and API | Handler, version, package, configuration | Information about the running web process |
| Subdomains and legacy applications | Association of a domain with a specific environment | Checking each handler used |
| Cron and queues | User, PHP path, launch command | Performing an agreed diagnostic task |
| Containers | Image, base environment and running instance | Composing a new image and checking a running container |
| Hosting or panel | Package provider and domain-assigned version | Full audit and support response |
The commands below are intended to diagnose the selected CLI interpreter in sh/bash. They do not install updates or restart services:
php -v
php --ini
php -mBy PHP documentation, these options show the version, configuration files and loaded modules. Also record the path to the executable file to be called. In the same selected environment, you can get a compact summary:
php -r 'echo json_encode(["version" => PHP_VERSION, "sapi" => PHP_SAPI, "binary" => PHP_BINARY, "ini" => php_ini_loaded_file()], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;'Meaning sapi denotes the way PHP is run: for example, cli, fpm-fcgi or apache2handler. SAPI Documentation explains the differences and php_ini_loaded_file() returns the path of the loaded php.ini or false. The output of this command is relative to the current CLI call.
Check the web environment separately: through closed diagnostics, domain handler configuration, and administrator information about running processes. Full page phpinfo() You should not leave it in a public directory: it reveals unnecessary information about the environment. An agreed set of technical data without secrets is sufficient for the report.
How to confirm a fix with your hosting provider
The "update PHP" request is too vague. Submit the domain, panel used, known version and names of vulnerabilities. Please indicate:
- Which PHP package is actually assigned to the domain and whether CVE-2026-109618 and CVE-2026-109619 fixes are enabled.
- Which complete audit is installed and which supplier bulletin the confirmation is based on.
- Whether running processes were replaced and how this was verified.
- What separate actions are needed for cron, queues, containers and other versions in the account.
- Have you checked the clarifications for CVE-2026-115560 and the composition of the Windows package, if this applies to your environment?
Save the answer in the technical task card along with the date of verification. If the hosting uses its own packages, comparing only with the table of upstream versions does not give a complete answer. The applicability of fixes and the status of a supported build must be confirmed by its vendor.
Prepare the update separately from the application redesign
First, save your working configurations, current packages, and backup data. Review the recovery order and assign someone responsible for the release decision. For the store, determine how orders that appear after the copy is created will be taken into account. Simply restoring the old database can remove new transactions.
Then prepare a test environment with the target patched PHP and required extensions and settings. Restrict access to it. Disable real payments, mailings and external changes or replace them with agreed upon test scenarios. The copied data must be used according to the rules of the project.
If the current branch is supported and receiving the fixes you need, you can first check for an update within it. It is better to plan changes to the main version, database, CMS and the entire theme as separate changes with a clear reason. This makes it easier to find incompatibilities.
For PHP 8.2, please note the calendar: upstream security support ends December 31, 2026. Until this date, there is time left to prepare the transition; the requirements of the CMS, extensions and hosting provider need to be checked in advance. Contractual support for a specific vendor is considered separately from the PHP.net calendar.
For WordPress core, theme and plugins, use a separate procedure for preparing an update. Fixing PHP and changing WordPress are different items on the release sheet.
What to check on the test copy and after release
Acceptance is built around the operations in which the business operates. Define controlled accounts, email recipients, and test data in advance. A positive result of one HTTP request does not confirm the completion of the entire chain.
| Scenario | Minimum verification | Confirmation of the result |
|---|---|---|
| Public pages | Home, service, catalog, card, search | Correct HTML, images and no new errors |
| Login and sessions | Entry, exit, allowed sections | The state is preserved and rights are not expanded |
| Application | Sending, validation error, click again | One entry for the person in charge, a clear message to the visitor |
| Shop | Shopping cart and agreed test order | Order, status, letter and accounting without duplicates |
| Files | Acceptable file and intended refusal | Correct processing and access to saved results |
| Cron and queues | Job under worker user | Successful completion and expected processing |
| Integrations | Test exchange and intended failure | Acknowledgment from recipient and controlled retry |
In Bitrix, check the execution of agents and mail events separately. If emails are delayed, diagnose the chain by instructions for queue b_event, keeping notifications up-to-date. You shouldn't clear the queue just for the convenience of testing an update.
For CRM and exchange with the accounting system, check external identifiers and duplicate protection. A useful basis for such a statement is the section on integrations in material about CRM architecture. The API test response must correspond to the actual state of the recipient's record.
How to release an update and prepare a recovery
Record the contents of the verified candidate: application code, configuration, PHP package or image, extensions, and acceptance results. Before switching, double-check which services and workflows apply to this site. A universal restart of all containers or all applications on the server adds risk to third-party services.
After installation, the administrator must confirm that new requests are being processed by the patched environment. Then repeat the agreed upon checks and compare the logs to the original state. Designate a monitoring period and a person to review pending operations: some tasks are scheduled to run later than the public opening of the site.
The recovery plan must preserve security patches. Consider returning compatible code or customizations to a patched environment. If there is no such candidate, negotiate a temporary restriction of access and restoration in a controlled loop. It is impossible to return a vulnerable assembly to the public domain as a standard solution.
The update does not remove foreign code that has already been embedded. If there are signs of compromise, a separate procedure is needed: saving investigation materials, checking integrity, restoring and replacing affected accesses. For WordPress there is post-burglary action plan; the fact of infection cannot be inferred only from the old version of PHP.
What report should I request from the person in charge?
The outcome of the task should be a short statement: domains and processes, package vendor and revision, applicable patches, switchover time, script results, and remaining restrictions. List untested components separately. The wording "PHP updated" without this context leaves it unclear which part of the system has been adopted.
If your site has multiple handlers, exchanges, or legacy components, include this check in technical support of the site. To set a task, a list of domains, access to current documentation and a list of operations that should continue to work are sufficient. Passwords and configuration secrets do not need to be included in the public application.
FAQ
Is it enough to update WordPress or Bitrix?
Check server PHP separately. The CMS core, extensions, and runtime have their own versions and update procedures. The report should include those components that actually serve the site.
Why does php -v show the new version, but the site works on the old one?
The console and web server may use different binaries, packages and configurations. Associate the domain with its handler, check running processes and separately scheduled jobs. The CLI output is relative to the command called.
Is it possible to evaluate a package based on the PHP number alone?
The vendor build requires a full audit and proof of patch availability. The vendor can transfer the patch to its version. This status is verified by its bulletin for a particular package.
Does old PHP mean the site is already hacked?
No. The version indicates the need to verify corrections, and the fact of the incident is determined by a separate investigation. The absence of noticeable symptoms also does not confirm that the configuration is safe.
Sources
- PHP: October 2026 Security Messages.
- PHP: RCE via OOM corruption, CVE-2026-109618.
- PHP: RCE via stale global state, CVE-2026-109619.
- Red Hat: RHSB-2026-013.
- cPanel: critical fixes and package versions.
- cPanel: separate message about CVE-2026-115560.
- PHP: Command Line Options.
- PHP: php_sapi_name and PHP_SAPI.
- PHP: php_ini_loaded_file.
- PHP: Predefined Constants.
- PHP: Branch Support Timing.
