PHP2Shell is the name being used for the critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619. Server administrators should identify exposed PHP applications, prepare to install vendor-confirmed fixes, and decide whether temporary access restrictions are necessary. This guide covers PHP websites on shared hosting, virtual and dedicated servers, and container-based deployments.
Updated: 21 October 2026, after the PHP security release. Fixed upstream releases are now available. Repository delivery is a separate step: confirm the exact package supplied by your operating system, control panel or image maintainer.
PHP2Shell Patched Versions
The PHP security announcement identifies these corrected releases for both CVE-2026-109618 and CVE-2026-109619:
| PHP branch | First fixed upstream release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
A distribution backport may retain an older PHP version string. Verify the full package release against its vendor advisory. Installing a new PHP version in another directory does not replace the runtime serving a website.
Minimal source backports also exist for PHP 7.4, 8.0 and 8.1. These are source changes for package builders, not automatically installed RPM/DEB updates or renewed upstream support.
How Could a PHP Remote Code Execution Attack Work?
At a general level, an unauthenticated web-facing RCE allows an attacker to submit crafted input to a reachable service and cause execution outside the application’s intended behavior. A PHP runtime vulnerability may affect applications even when their own code, plugins and passwords are up to date.
WordPress Web Hosting
Starting From $3.99/Monthly
The official advisories now describe two distinct defects: out-of-memory corruption involving partially initialized request data, and stale global state that can survive into a later request. This is a runtime problem, not a requirement for a vulnerable WordPress plugin. Exploitability depends on the execution environment; “every website gives root with one request” is not a justified conclusion.
If code executes inside a PHP worker, the initial impact depends on that worker’s operating-system identity and permissions. Potential consequences include reading application configuration, obtaining database credentials, modifying writable website files or creating persistence. Execution as a website account is not automatically execution as root. Shared credentials, excessive permissions or additional vulnerabilities can nevertheless increase the damage.
This distinction matters on shared servers: separate subscription users and restricted filesystem access can limit the impact of an incident, but they do not repair the PHP vulnerability itself.
Which Websites and Servers Need Attention?
Inventory internet-facing PHP workloads across WordPress, WooCommerce, WHMCS, Laravel applications, custom APIs, webmail and other PHP-based services. Include production, staging, forgotten subdomains, alternate ports and containers. A site that receives little traffic can still expose an outdated runtime.
On a self-managed VPS or dedicated server, establish who maintains the PHP packages. On managed hosting, ask the operator which package build serves your account and whether that build includes fixes for both CVEs. A statement that the hosting panel is updated is not sufficient evidence about the runtime.
Do not infer safety from the major version alone. PHP 8.2 or 8.3 is a branch, not proof that a particular build has been patched. Conversely, some vendors backport security fixes without adopting the newest upstream version number, so the package release and vendor security notice also matter.
Cheap VPS Server
Starting From $2.99/Monthly
What Can You Do Before a Verified Patch Is Available?
CERT-EU recommends considering isolation of internet-facing PHP applications when immediate patching is not possible. The objective is to stop untrusted requests before they reach the vulnerable runtime. Choose a control that matches the business impact and verify that it covers every route to the application.
| Temporary action | What it achieves | Operational consequence |
|---|---|---|
| Allow only trusted IPs or VPN access at the web server or network boundary | Prevents unapproved clients from reaching the protected application when all entry points are covered | Public customers and external integrations may lose access |
| Serve a static maintenance page and block public PHP routing | Keeps a public notice available without sending visitor requests to PHP | Login, checkout, APIs and other dynamic features stop |
| Keep the application public with existing filtering and monitoring | Preserves availability and may reduce some malicious traffic | Residual exposure remains; this is not a verified fix |
A WordPress maintenance plugin still runs through PHP. Restricting only /wp-admin/, the WHMCS administrator directory or the Plesk login port does not remove exposure through the public application. If using a static response, ensure that front-controller routes, direct PHP URLs and alternate virtual hosts cannot bypass it.
For sites behind a reverse proxy or CDN, check direct-origin access as well as the public hostname. Apply restrictions consistently to IPv4, IPv6 and alternate listening ports. Test from an unapproved external connection, not only from the administrator’s allowed address.
Temporary PHP Configuration Mitigations
PHP now confirms that disabling upload progress blocks the known session-related paths, but not every variant. Set this in the loaded server-level PHP configuration or FPM pool before request parsing:
session.upload_progress.enabled = OffFor PHP 8.5, also set:
fatal_error_backtraces = OffRestart every relevant worker. An application-level ini_set() or FPM .user.ini is not sufficient for this purpose. Check pool and virtual-host overrides. These measures reduce specific exposure; they do not replace the corrected binary.
Windows VPS Hosting
Remote Access & Full Admin
The OOM advisory discusses memory_limit=-1 with external memory controls. Do not deploy that change blindly across shared hosting: removing PHP’s limit can create resource exhaustion, and underlying allocation failures remain possible. Request-size limits must fit application requirements. See the official OOM advisory before designing this mitigation.
Can Cloudflare, a WAF or DDoS Protection Replace the Patch?
A vendor-validated rule may provide temporary protection against a known request pattern, but simply enabling a WAF does not demonstrate coverage for both CVEs. A rule can also fail to help if traffic reaches the origin by another route.
Network availability protection and runtime patching solve different problems. Our guide to DDoS-protected VPS features and limits explains the availability side; a PHP RCE still requires its own remediation. Keep existing controls enabled, but do not turn their presence into a claim that PHP2Shell is resolved.
How to Patch PHP on Servers and Websites
First verify that the package provider has released a build explicitly addressing both CVEs. Upstream release time and availability in a hosting-panel repository are separate milestones. A successful update with no new packages installed does not close the incident.
- Prepare recovery: confirm a recent restorable backup and retain the current package and configuration inventory. Avoid replacing the only known-good backup.
- Match the provider: distinguish operating-system packages, control-panel runtimes, third-party packages and container images.
- Install the corrected packages: prefer an update within the existing supported branch when suitable, rather than an untested major-version migration.
- Replace running vulnerable processes: follow the vendor’s restart instructions for the relevant PHP-FPM services, web-server modules or application pools.
- Verify every affected workload: compare installed package builds with the advisory and confirm the runtime actually serving each domain.
Choose the Update Method for Your Hosting Environment
| Environment | Remediation approach | What to verify |
|---|---|---|
| Self-managed Linux or Windows server | Install the corrected PHP build from the provider responsible for the existing installation. | The package or binary build, web-server integration and running processes. |
| Shared or managed hosting | Ask the hosting operator to apply the corrected runtime to the account. | Confirmation covering both CVEs and the PHP build serving the website. |
| Hosting control panel | Follow that panel vendor’s package advisory and supported update procedure. | Every active PHP version and its domain assignments. |
| Containers | Build or obtain a corrected image and redeploy the running workloads. | The image and PHP build in each running instance. |
| Custom source build | Rebuild from a vendor-confirmed corrected release using the required extensions and configuration. | That the web service uses the new binary rather than an older installation. |
There is no single update command that safely covers all these environments. Installing the operating system’s default PHP package may leave a separately installed runtime unchanged. Similarly, installing a corrected image on a container host does not replace already-running containers.
Coordinate updates with application owners and test the functions that depend on PHP. When several versions coexist, treat each one as a separate remediation item.
Linux Patch Commands: Inspect, Update, Restart, Verify
Run the appropriate commands on an authorized host after checking backups and a maintenance window. These examples use existing repositories and installed packages. They do not switch PHP module streams or add an external repository. Review the proposed transaction before accepting it.
AlmaLinux, Rocky Linux and RHEL with DNF
rpm -q php-common php-cli php-fpm
dnf --refresh check-update 'php*'
dnf --refresh upgrade 'php*'check-update returns 100 when updates are available; that is not a failed update. For a planned whole-host update instead of PHP only, use dnf --refresh upgrade. Review skipped or excluded packages and dependency conflicts. Do not remove extensions with --allowerasing merely to force the transaction. DNF command reference.
Ubuntu and Debian with APT
sudo apt-get -o APT::Update::Error-Mode=any update
dpkg-query -W 'php*'
apt-cache policy php8.2-common php8.2-cli php8.2-fpm
sudo apt-get --only-upgrade install php8.2-common php8.2-cli php8.2-fpmThis example is for an existing PHP 8.2 FPM installation. Substitute the actual installed branch and include its installed extension packages; an Apache module deployment needs its corresponding package too. For a planned general update, sudo apt-get --with-new-pkgs upgrade updates installed packages and allows new dependencies without removing packages. Holds and dependency constraints can still leave packages pending. See the APT documentation.
Restart the Runtime Actually Serving Requests
For a standard RPM PHP-FPM service:
sudo php-fpm -t && sudo systemctl restart php-fpm
systemctl is-active php-fpmFor a standard Debian/Ubuntu PHP 8.2 FPM service:
sudo php-fpm8.2 -t && sudo systemctl restart php8.2-fpm
systemctl is-active php8.2-fpmAdapt the binary, configuration path and service name for custom pools or hosting panels. Apache mod_php needs Apache workers replaced after a successful configuration test. Restart long-running PHP application workers as appropriate. A PHP update alone does not normally require rebooting the entire machine; other updated components may require a separately planned reboot.
Confirm What the Update Actually Installed
php -v
php --ini
systemctl --failed --no-pagerThese checks are a starting point, not proof of every domain’s runtime. Verify the full RPM/DEB build, the running web SAPI and all pool overrides. “Nothing to do” only describes available updates in the configured repositories. Missing CVE text in a local changelog is not, by itself, definitive evidence either way.
Containers and Vendor Applications Need Their Own Patch Path
Host package updates do not replace PHP inside a container image. Inventory containers, obtain the vendor-confirmed fixed image, then recreate the workload with its persistent volumes and deployment configuration intact. Pulling an image alone does not replace a running container. Docker documents these separately as compose pull and compose up.
For a product-managed deployment such as SolusVM, use its supported updater and verify every PHP-bearing service, including API and workers. Do not treat a manual package installation inside an ephemeral container as durable remediation. For native Passbolt, patch its host PHP packages while retaining required extensions such as GnuPG, then run its health check and test authentication and password access. For containerized Passbolt, follow the image update path.
Control Panel Example: PHP2Shell on Plesk
Example: Checking PHP on Plesk
The Plesk advisory lists Linux hosting PHP fixes for 8.2–8.5. At this review, its PHP 7.4/8.0/8.1 and Windows packages remain in development, while panel sw-engine fixes are planned for 18.0.80#11 and 18.0.81#4. Check the live advisory before acting; a planned release is not an installed fix.
Inventory website handlers separately from the panel engine:
sw-engine -v
plesk versionDo not replace sw-engine with a website PHP binary or change its symlink. Use Plesk’s supported updates.
List the PHP Handlers on Plesk for Linux
Run these read-only inventory commands over an authorized SSH session:
plesk version
plesk bin php_handler --listRecord each handler’s identifier, PHP version and executable path. Then list the domains using a specific handler:
plesk bin php_handler --get-usage -id HANDLER_IDReplace HANDLER_ID with an actual identifier from the list. These commands follow the Plesk PHP handler documentation. Checking only php -v can miss the issue because the command-line default may differ from the runtime selected for a website.
Create a small inventory containing domain, handler ID, package provider, installed build, application owner and remediation status. Include PHP-based auxiliary services and containers that are not represented by ordinary website assignments.
Update Plesk-Managed PHP Packages
For Plesk-managed component updates, the official interface is Tools & Settings → Updates → Update Components. The documented command-line alternative is:
plesk installer updateThis is a change command: it installs available Plesk updates and may restart updated components. Review the Plesk update instructions and your maintenance requirements before running it. It cannot install a fix that the configured repositories do not yet provide.
After PHP binaries have been upgraded, refresh Plesk’s handler information where needed:
plesk bin php_handler --reread
plesk bin php_handler --listRefreshing the handler inventory is not a substitute for restarting affected workers.
What About PHP 7.4, WordPress and WHMCS?
The PHP support schedule lists 8.2, 8.3, 8.4 and 8.5 as supported branches at the time of this review. PHP 7.4 is outside upstream support. A legacy installation therefore needs either a tested migration to a supported, corrected build or an explicitly verified security backport from its package vendor.
Do not switch an older WHMCS installation directly from PHP 7.4 to an arbitrary PHP 8.x release. Check the application’s compatibility matrix, ionCube Loader requirements, commercial modules and custom hooks first. Where immediate migration is impractical and no verified backport is available, access restriction remains an operational option.
For WordPress, updating core, plugins and themes remains useful maintenance, but it does not replace a PHP runtime update. Test administration, media uploads, scheduled tasks and checkout after changing PHP. For WHMCS, also test client login, orders, payment callbacks, ticket attachments, provisioning and the cron job’s own PHP executable.
How to Verify Remediation and Check for Compromise
Close remediation only when you have evidence for the installed fix and the running service. Record the advisory, package build, installation time, worker restart and application checks. Use an authenticated or local diagnostic to verify the web runtime; do not leave a public phpinfo() page exposing configuration.
Review web-server and PHP logs alongside process, file-integrity and account activity. Unexpected shell processes launched by a web worker, unfamiliar scheduled tasks, newly modified PHP files or unusual outbound connections warrant investigation. These are general incident indicators, not published signatures proving exploitation of these particular CVEs.
If compromise is suspected, isolate the workload, preserve evidence and determine which credentials were accessible. Rebuilding from a trusted baseline and rotating exposed secrets may be necessary. Installing a patch does not remove an existing web shell or invalidate stolen credentials.
Frequently Asked Questions
Is PHP2Shell a WordPress plugin vulnerability?
The advisories concern PHP itself. A WordPress plugin update does not repair the underlying runtime. Assess the PHP build serving the site.
Is PHP 8.2 automatically safe?
No. A supported branch can still contain a vulnerable build. Confirm the corrected package release against the vendor advisory.
Do I need to shut down the entire server?
Not necessarily. It may be possible to restrict individual web applications or stop public PHP execution while keeping unrelated services running. Validate the scope before applying a broad network rule.
Does HTTPS prevent this attack?
HTTPS encrypts transport. It does not establish that the server safely processes the decrypted application request, so it is not a replacement for a runtime fix.
Can I confirm safety using an online scanner?
A scanner result has limits, especially before reliable detection is available. Prefer package provenance, vendor confirmation and verification of the live runtime. Do not run untrusted exploit tools on production systems.
When should public access be restored?
Restore access after the relevant runtimes are verified as patched, affected processes have been replaced, essential functions pass testing and any suspected compromise has been addressed. Recheck callback delivery and queued business operations after a restriction is removed.
Administrator Action Checklist
- Inventory every PHP runtime and the applications it serves.
- Track both CVE identifiers in the PHP and package-vendor notices.
- Choose temporary exposure controls where patching is unavailable.
- Install a verified corrected build for every affected runtime.
- Restart the relevant processes and test the actual web applications.
- Investigate suspicious activity separately from the patching task.
The priority is a documented path from exposed runtime to verified corrected service. Until a fix is available for your package source, make the availability and access-control decision explicitly rather than treating an unverified configuration tweak as protection.
