# PHP2Shell: What to Ask Your Host to Confirm Your Website Is Patched URL: https://insight.trigenys.com/en/posts/editorial-os-1daa001329ad168d9108 Language: en Authors: AgenStudio Published: 2026-10-28 Updated: 2026-10-28 Desk: Information Systems, Tech & AI Publisher: Trigenys Insights > Patches are available. A business needs to identify who deploys them, which runtime actually serves its website and what evidence records the intervention. ## Key takeaways - The vulnerabilities concern the PHP runtime; updating a theme or plugin does not necessarily address that layer. - Useful evidence identifies the corrected package and the web service running it after workers restart. - PHP’s October 23 note adds a specific precaution; follow the official advice applicable to the actual environment. Your web host says the site is ‘up to date’. Does that mean the application, its plugins—or the PHP runtime affected by PHP2Shell? A vague answer may leave a business with false confidence. A shop, school or small company should request the running PHP version, the patch applied, the deployment date and the checks completed. This guide explains what to ask for; it is not a remote security audit of any particular website. ## What the official advisories establish On October 21, 2026, PHP announced two critical vulnerabilities that can allow unauthenticated remote code execution under certain conditions. CVE-2026-109618 and CVE-2026-109619 concern distinct memory and internal-state problems. The listed corrected releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP’s general advisory urges web-serving installations to update and highlights particularly high risk for Apache mod_php. This does not establish that every website has been compromised. It does justify prompt correction appropriate to the environment. ## A message website owners can send If an agency or host administers the site, ask for a confirmation such as: “Hello, does [domain] use an environment affected by CVE-2026-109618 and CVE-2026-109619? Please confirm the PHP service handling its web requests, the complete corrected package or image version, the applicable vendor advisory, deployment timing and restart of the relevant workers. Please also identify functional checks completed and whether any indicators require investigation.” This is Insight’s suggested message; it was not sent for this article. It connects the response to an identifiable website and intervention. A general assurance that servers are secure does not document those details. Request the missing evidence. ## Follow the runtime that actually serves requests The technical inventory should connect each application with its server, container or managed service. Less visible environments, including exposed staging systems, also need consideration. A command-line check can help, but php -v identifies the binary invoked in that context. The web server may use another one. Follow the request-serving configuration and confirm that relevant workers were renewed after updating. Avoid creating a public diagnostic page exposing the full server configuration. Required information can be checked through administration and retained in the intervention record. ## A short version number may be incomplete evidence A vendor may integrate a fix without adopting the expected upstream number. Check its documentation, complete package version and build date where relevant. Plesk provides an example: its table distinguishes corrected builds for certain older Linux branches while retaining the PHP version number. This must be established for the relevant vendor, rather than assumed for an old installation. Useful evidence therefore links the installed package to an applicable correction advisory. ## The additional October 23 note PHP’s session upload progress note recommends temporarily disabling session.upload_progress.enabled against an unusual scenario pending a forthcoming fix. It describes a particular combination of configuration and runtime changes to the session serializer. The technical team should read the note and assess its environment. This precaution does not replace the October 21 patches. ## Check functionality and preserve the record Important payment, authentication and form journeys should still work after the intervention. Technical staff should retain deployment information and review relevant logs through their security process. Patching and determining whether compromise occurred are separate tasks. A vulnerable installation does not prove intrusion; an absence of alerts does not automatically close the investigation. The business owner’s useful deliverable can be a short record: scope checked, correction applied, service restarted, functions tested and any follow-up. That turns a general concern into an accountable action. Documentary guide checked on October 24, 2026 against PHP, its two vulnerability advisories and Plesk. No third-party server was tested, and no hosting service is certified by this guide. ## Frequently asked questions ### Does a vulnerable PHP version prove my website was hacked? It establishes exposure, rather than proof of compromise. Patch the environment and work with the technical team to determine whether evidence warrants investigation. ### Is php -v enough to establish that the site is patched? It identifies the command-line interpreter being invoked. The web service may use another binary, package or container, so verify the runtime that actually serves requests. ### Which releases fix the two October 21 vulnerabilities? The advisories list PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some vendors backport fixes; their advisory and complete package identity are then needed. ## Sources - PHP Security Advisory: Critical remote code execution vulnerabilities, update now — PHP Group — https://www.php.net/archive/2026.php#2026-10-21-5 - PHP informational advisory: Session upload progress — PHP Group — https://www.php.net/archive/2026.php#2026-10-23-1 - PHP2Shell vulnerabilities and Plesk patched versions — Plesk — https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-PHP2Shell-Remote-code-execution-in-PHP-shipped-with-Plesk - PHP — CVE-2026-109618 : RCE via OOM corruption — The PHP Group — https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w - PHP — CVE-2026-109619 : RCE via stale global state — The PHP Group — https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp