PHP is preparing a critical update. Get your deployment ready before it arrives. This guide explains what is known about PHP2Shell, what remains unconfirmed and how to check the PHP runtime actually serving your website.
Status checked: October 21, 2026, 02:49 UTC. This is a pre-release assessment, not confirmation that your server is affected or protected.
What PHP has confirmed and when the patch is expected
The official PHP notice announces two critical vulnerabilities, both rated CVSS 4.0 9.2. The update is scheduled for October 21, 2026 at 14:00 UTC, with an earlier release possible. PHP will publish technical details and affected and fixed versions with the release.
Our review of the official changelog did not yet find a published version confirming fixes for these two CVEs. An anticipated version number is not proof of an available patch.
PHP2Shell, CVE-2026-109618 and CVE-2026-109619: what remains unknown
The watchTowr FAQ identifies CVE-2026-109618 and CVE-2026-109619 as reported remote code execution, or RCE, vulnerabilities. The source itself says the claimed scope, PHP 5 onward, has not been confirmed by the vendor. We do not treat that report as a definitive list of exploitable deployments.
If an RCE path is confirmed for a particular configuration, an attacker could execute code within the permissions available to the vulnerable process. That can be serious without implying root access. We do not yet attribute a technical cause, a specific vulnerable configuration or an exploitation method to these flaws.
A public demonstration does not establish that every PHP website can be attacked in the same way. Assessing your environment requires its version, configuration and the conditions in the final advisory. This article is also not evidence of attacks against TERAMONT customers.
What to check now on your hosting or VPS
The following is a proposed operational preparation checklist. It is not a PHP2Shell detector or a mitigation validated specifically for these CVEs.
1. Inventory applications, not just servers
Record domains, subdomains, APIs, internal panels, Internet-accessible test environments and background processes. For each, note who maintains it, where PHP comes from and how it is updated. Include containers and older installations still receiving traffic.
In a terminal with PHP available, start with these read-only queries:
Plan your PHP application's maintenance
Compare resources for your project and establish who updates its OS, PHP and applications. A VPS does not replace that maintenance.
php --ini
php -v reports the invoked binary's version; php --ini identifies its configuration files. The command-line version may differ from the one serving your website. Also check the runtime assigned to every domain, pool or container through your environment's administration tools. Official PHP command-line reference.
Do not leave a public phpinfo() file for this check: its output can expose paths, configuration and environment variables. Use panel information or a restricted diagnostic and remove it afterward. Information exposed by phpinfo().
2. Identify who supplies and applies the update
- Shared or managed hosting: ask your provider which runtime serves your domains and how it will confirm deployment. Selecting a different version does not itself prove the fix is included.
- Self-managed VPS: the system administrator is responsible for updating the PHP installed inside it. A provider's hypervisor update does not replace this task.
- Panels such as Plesk or cPanel: check panel-managed packages and runtimes, which can coexist with the system PHP installation. Follow each installation's supported update channel.
- Docker: prepare to rebuild with a base that includes the fix and replace the running containers. Restarting the same container does not incorporate a new image. Docker image update guidance.
3. Check your branch's support status
Official PHP 8.1 support ended on December 31, 2025. PHP 8.0 and the 7.x branches are also unsupported. Do not assume they will receive another upstream patch. If you rely on them, prepare a compatible migration or obtain specific coverage confirmation from your extended-support provider. Unsupported PHP branches.
At this review date, officially supported stable branches are 8.2, 8.3, 8.4 and 8.5. Using a maintained branch does not mean you have installed a patch that is still pending. Official support schedule.
How to deploy the patch once it is confirmed
- Read the final advisory. Identify the fixed minimum or your provider's specific package. Do not install files from unknown links or testing builds as a substitute for a stable update.
- Prepare recovery and testing. Verify recoverable file and database backups, administrative access and a maintenance procedure. Test critical functions promptly without unnecessarily extending exposure.
- Update the correct component. Use the repository, panel or image corresponding to each installation. Updating WordPress, Laravel or Composer does not replace updating the PHP interpreter running them.
- Activate the new runtime. Follow the supplier's instructions to restart or replace the necessary processes. An installed package is insufficient if services are still running the previous binary.
- Verify every instance. Check the effective web and worker runtimes, then test logins, sessions, forms and essential operations. Record the package, time and outcome for each instance.
Watch for backports: a supplier may add a security fix without adopting the newest upstream PHP version number. Match the complete package revision to its security advisory rather than comparing only the upstream version. This does not confirm that a backport for these CVEs already exists. How security backports work.
What to do while waiting, and what does not prove protection
Review services that do not need public access and prepare a change window. If your risk assessment warrants temporarily restricting an application, document the impact on users and integrations. These are general exposure-reduction measures, not a guarantee against a vulnerability whose requirements remain unconfirmed.
Do not treat configuration changes or WAF rules copied from rumors as a confirmed solution. A firewall, HTTPS, password changes or plugin updates do not establish that the interpreter has been patched. If a vendor publishes a mitigation, check its scope, compatibility and limitations.
If you observe unusual activity, preserve logs and follow your incident-response procedure. Installing a patch does not by itself remove an earlier intrusion, and finding no alerts does not demonstrate that compromise never occurred.
Frequently asked questions
Should I take every PHP website offline?
The reviewed sources do not support a universal recommendation to do so. Prioritize inventory and preparation, and make containment decisions based on each service's exposure and business impact.
Does updating WordPress or Laravel fix PHP2Shell?
It does not replace a runtime update. Keep applications current too, but separately verify which PHP interpreter handles their requests.
How can I confirm my provider has finished?
Ask for the applicable advisory, the version or package revision and confirmation that it is active in the runtimes serving your domains. A scheduled update is not the same as a deployed and verified one.
Does moving to another hosting provider eliminate the issue?
Only if the new environment meets the fix requirements and the migration does not retain a vulnerable runtime. A provider's name or using a VPS does not demonstrate protection.
Your project's next step
Prepare a short list today: applications, effective runtime, owner, update channel and acceptance test. This makes it easier to act quickly once a fix is confirmed and avoids overlooking secondary installations.
If you are evaluating hosting, explore TERAMONT VPS plans. Resource choices should come with clear maintenance responsibilities. For background on that distinction, read our guide to what a VPS is and how it works.
This guide combines the linked sources with general operational recommendations. We have not executed an exploit or audited customer servers. Check official sources for the current patch status before acting.
