On this page
A critical PHP advisory leaves server owners with urgent questions: which package is fixed, whether their applications will still work, and whether the PHP used by their control panel has been updated too.
Our response to the October 2026 PHP security emergency has focused on answering those questions with evidence and helping customers through the work. Between 21 October and 24 October at 11:30 UTC, our support records show 50 PHP-security-specific replies across 34 distinct support tickets. Those figures describe documented support activity; verification continues on open cases.
This recap explains the work behind the updates. For current technical instructions and the evolving verification record, keep using our main PHP security status article.
We checked the advisory, then checked the actual packages
On 21 October, PHP published fixes for CVE-2026-109618 and CVE-2026-109619 in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The advisory includes web-facing LiteSpeed installations. We tracked the upstream guidance and the relevant operating-system and LiteSpeed repositories, distinguishing an upstream release from a package that was actually available for a particular server.
Our owned Ubuntu 26.04 QA environment passed a selected update across those four PHP branches. The verification included repository authentication, the hashes of 61 downloaded runtime and module packages, rollback coverage and real requests. The separate panel PHP executable was refreshed and old workers were recycled.
We also documented native, same-branch PHP 8.3.36 and 8.4.27 source-build verification on an owned Ubuntu 24.04 environment, including matching OPcache modules and upstream regression tests. These results apply to the hosts and branches tested. They are not a universal binary release or evidence that every customer server has been patched.
On 22 October, our Ubuntu 20.04/Focal work progressed from authenticated repository checks and an upgrade-and-rollback rehearsal to a live website request reporting PHP 8.3.36 with OPcache 8.3.36. The technical status article records that deployment’s scope and limitations.
We treated website PHP and panel PHP as separate checks
One of the most useful points we repeated to customers was that a server can have several PHP installations. Updating website PHP does not automatically update the separate executable used by the panel and phpMyAdmin. An OS package, a LiteSpeed installation, WebAdmin and a copied panel executable can each require separate attention.
Our checks covered the actual executable, matching affected modules such as OPcache, startup configuration and the running workers. Where access allowed, we checked real website and database-dependent application requests. We kept normal panel login and panel-to-phpMyAdmin access as explicit verification steps. A login page returning HTTP 200 alone does not complete those authenticated checks.
Support continued beyond upgrade instructions
The recorded replies included version and vendor-backport checks, compatibility guidance, backup planning and follow-up on actual customer environments. Some customers also needed access or application problems resolved before a safe PHP update could proceed.
Alongside the security work, individual customer cases included a repaired TLS chain, a production-certificate validation repair and a log-pagination fix that the customer confirmed through the final page. Access-recovery work included verified backup transfers, native archive checks, isolated restores and read-only disk inspection. We kept those recovery tasks separate from claims about PHP remediation.
Customer names, server addresses, credentials and private diagnostic output remain private. Where normal-account confirmation, management access or a deployment check is still missing, the case stays open for follow-up.
Backups and rollback were part of the response
Before changing relevant runtimes, our work included preserving configuration, matching modules and rollback packages, together with the recovery coverage appropriate to the host. In customer cases that needed deeper recovery, we checked the backup and restoration evidence before relying on it.
A completed file transfer, an archive check and a restored VM establish different things. An unquiesced VM backup also does not, by itself, prove database or application consistency. We recorded those limits so that a recovery step would not be reported as a fully tested application repair.
We kept the guidance current as PHP published more information
PHP’s 23 October follow-up described an additional, unusual session-upload-progress path, CVE-2026-115560. We updated the main status article to retain session.upload_progress.enabled=0 in startup/server configuration until the next regular bugfix release, following the upstream guidance.
The earlier fixed releases remain required for the 21 October vulnerabilities. Temporary configuration measures provide partial protection on the paths described by PHP; they do not replace a verified compatible update or an evidenced vendor backport.
The work still in progress
Several customer environments still need secure management access, application-compatibility work, a reviewed worker-update procedure or normal-account panel/phpMyAdmin confirmation. Older PHP branches need an evidenced vendor backport or a tested migration plan. These are active follow-up items.
We will continue verifying the actual customer environment before calling a remediation complete. The main security article remains the technical source of record as the response develops.
Need help with your server?
Email [email protected]. Tell us your operating system, the PHP versions involved and the exact error, with private details removed. We can help check website PHP, the separate panel/phpMyAdmin runtime and the appropriate verified update path. Please keep passwords, keys, MFA codes and session links private.
Which part of the update has been hardest on your server: finding the right package, checking extensions, or verifying the panel runtime?
About the support figures: Snapshot taken at 11:30 UTC on 24 October 2026, covering messages from 00:00 UTC on 21 October. We counted distinct tickets with support replies explicitly referring to the PHP advisories or PHP-security terms: 34 tickets and 50 matching replies. Other follow-ups and Facebook/private-message activity are excluded. These figures do not represent completed server remediations.
Sources: PHP’s October advisories and release notices; CyberPanel’s dated technical verification record; the support-message snapshot described above.
