A WordPress dashboard showing “all plugins are up to date” does not tell you whether the server is patched for PHP2Shell. The immediate fix belongs to PHP, the software that runs WordPress on your hosting server.
On October 21, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, commonly called PHP2Shell. Under the right conditions, an attacker can exploit them to run code on a vulnerable server without logging in. The PHP Foundation’s explanation describes the defects and the release.
Start by asking your host to confirm that the PHP runtime serving your website contains both fixes. If the update cannot happen promptly, have the host reduce public exposure while it works. A firewall can provide additional protection during that process; it should not delay the patch.
Once the immediate exposure is addressed, the next task is to review the plugins and custom code running on the site. That review helps you identify unnecessary access, unsupported software, and update problems before the next security alert.
What happened, and why WordPress sites need to act
A WordPress site has several independently maintained parts: WordPress core, its themes and plugins, and the PHP runtime provided by the host. Updating a plugin changes that plugin’s code. It does not usually change the PHP installation underneath it.
The two PHP2Shell vulnerabilities concern memory handling when PHP encounters errors or retains internal state between requests. The maintainers document them in the out-of-memory advisory and stale-state advisory. Depending on the server and application, a specially crafted request can reach the vulnerable behavior.
This is why checking plugins alone is insufficient. WordPress’s security notice directs site owners to update PHP and confirms that a WordPress core release is not the remedy for these issues.
Treat an unpatched installation as an urgent problem. Its exposure does not, by itself, prove that the site has been breached. Establishing patch status and checking for compromise are separate jobs, and both deserve a clear answer from whoever manages the server.
Update PHP and verify the fix
For most site owners, the hosting provider is the first point of contact. If an agency manages your website, ask it to coordinate the work with the host. You should not need to edit server configuration to establish whether your site has received a security update.
Check the version your website actually uses
Open Tools → Site Health → Info → Server in the WordPress dashboard and find PHP version. Your hosting control panel may show it too. WordPress documents this path in its security notice above.
The October 21 releases containing the fixes are:
PHP branch
Release containing the PHP2Shell fixes
8.2
8.2.35
8.3
8.3.36
8.4
8.4.27
8.5
8.5.12
Use the latest applicable security release, rather than treating these numbers as permanent targets. A hosting vendor or Linux distributor may also backport the fixes, meaning it applies the security changes to an older package without adopting the same upstream version number. PHP’s update guidance describes these vendor options.
Send the host a request it can answer precisely:
Message to your hosting provider
Please confirm that the PHP runtime serving our domain is patched for CVE-2026-109618 and CVE-2026-109619. Include the package or build version, confirmation that the running PHP processes use the fixed build, and whether our other PHP sites and subdomains are covered. If any are still exposed, please explain how public access is being restricted until they are patched.
A reply saying “WordPress is updated” does not answer that request. Ask for confirmation covering both CVEs. If you manage your own infrastructure, check separate websites, containers, and PHP pools too. A terminal’s php -v command may inspect a different installation from the one handling website requests.
Choose the quickest supported update path
If your site already runs a supported PHP branch, its security update may address the immediate problem without a larger migration. For example, a site using PHP 8.3 should receive a fixed 8.3 build or an appropriate newer supported release. Moving every site straight to a different branch can introduce compatibility work that an in-branch patch avoids.
For PHP 8.1 or earlier, ask the host which maintained remediation path it provides. Routine upstream security releases have ended for those branches, although vendors may supply fixes and PHP has provided limited source backports for this incident. A site owner should obtain a patched hosting environment rather than attempt to apply source patches through WordPress. Plan a supported-version migration even if a vendor fix resolves the immediate exposure.
Before changing PHP, confirm that files, the database, and relevant configuration can be restored. Check the compatibility of the theme, essential plugins, and custom code. WordPress’s general PHP update guide covers backup and compatibility preparation. For this incident, use the specific fixed releases above, even if a general guide describes your PHP branch as current.
Use staging, a private test copy of the website, for a focused compatibility check where it is available. If compatibility testing will take time, restrict the vulnerable production service while it proceeds. An emergency patch should not sit behind an open-ended redesign or plugin replacement project.
Confirm the running site is patched and working
The host or administrator needs to verify that the web-serving processes use the fixed PHP build, including replacing or restarting old workers as required. Site owners can then check the parts of the website that generate enquiries, orders, and customer access.
Check
What a successful result looks like
Runtime
The host confirms both CVEs are fixed in the build handling live requests.
Pages and administration
Important page templates load, and an authorized administrator can sign in.
Forms and uploads
A test submission reaches its destination; required uploads complete successfully.
Commerce and integrations
Where applicable, a checkout in test mode, payment confirmation, or connected workflow completes as expected.
Errors
The administrator checks PHP and web-server logs for new failures during these tests.
A working homepage is only one check. A PHP change can expose a compatibility problem in a less frequently used form or scheduled task. Test the functions your business actually depends on and record any failures.
If something breaks, keep the affected service isolated while it is repaired. Restoring public access on a known-vulnerable PHP build would also restore the security problem.
If the update is delayed, reduce public exposure
Compatibility problems, unavailable hosting packages, or limited server access can slow an update. While those are being resolved, the practical question is which requests can still reach the vulnerable PHP installation. Handle that alongside the update, rather than waiting until testing is finished.
Restrict access before requests reach PHP
The UK National Cyber Security Centre’s advisory recommends considering taking a system offline when temporary mitigations cannot be applied or would take too long. Ask your host to assess this against the site’s exposure and the available patch.
Depending on the setup, containment could mean stopping the affected service, restricting access at the network or reverse proxy, or serving a static maintenance page without running WordPress while blocking public access to the PHP backend. Keep a protected server-management route available so the administrator can finish the work.
A WordPress maintenance plugin does not establish that PHP is isolated. It may execute PHP to display the maintenance page, while other routes remain accessible. The PHP Foundation describes a demonstrated mod_php attack that can trigger before application code runs. The restriction needs to operate early enough to prevent that exposure.
Have the administrator check alternate hostnames and direct access to the hosting server as well. Removing a DNS record alone does not block someone who already knows the server’s address. Explain the expected interruption to the business: forms, checkouts, and webhooks may stop working while access is restricted.
Check Cloudflare or another external WAF
A web application firewall, or WAF, filters traffic to an application. An external WAF sits between visitors and your hosting server, where it can inspect requests before they reach PHP.
Cloudflare reports deploying PHP2Shell protections for customers using its free and paid WAF services. Its incident response post also tells customers to apply the PHP update. Treat the WAF as an additional control while patching and monitoring continue.
For an existing Cloudflare setup, verify three things with the person managing it:
The affected web hostnames are proxied. Cloudflare’s proxy-status documentation explains the difference between proxied web traffic and DNS-only records. A domain using Cloudflare DNS does not automatically mean its web traffic passes through the WAF.
The relevant protections are active. Check managed rules, exceptions, and security events. Cloudflare asks paid-plan customers to confirm that the relevant managed ruleset is deployed in blocking mode.
The hosting server cannot be reached around the protection. The origin is the server behind Cloudflare. If it accepts direct requests from anyone, attackers may bypass the edge controls. Have the host apply appropriate origin protection without breaking legitimate integrations.
If you are onboarding a new service, account creation and a DNS change are only part of the work. Routing, TLS, rules, and origin restrictions still need checking. Keep an exposed service contained while setup proceeds. With another WAF provider, ask explicitly about coverage for both CVEs; a generic CDN or security badge does not answer that question.
Have the administrator assess temporary configuration changes
PHP’s maintainers describe configuration changes that reduce exposure to particular attack paths. For example, disabling session.upload_progress.enabled in the appropriate administrative configuration and restarting every worker blocks confirmed session-related paths. PHP 8.5 has an additional setting for the confirmed fatal-backtrace path. The stale-state advisory explains their scope and limitations.
These are server-administration decisions. A setting added inside a WordPress plugin can take effect too late, and changes to upload handling or memory limits can disrupt normal service. The maintainer guidance also distinguishes different PHP deployment types, so a copied configuration snippet may not fit your host.
Ask the administrator to record what was changed and which exposure it addresses. Those records help the team review temporary restrictions after the patch is installed. None of the configuration workarounds replaces the complete PHP update.
Check whether the site was compromised before it was patched
Once the runtime is fixed, there is still a question to answer about the period before the update. Patching prevents exploitation through the repaired defects; it does not remove a backdoor that an attacker may already have installed.
The NCSC advisory above recommends compromise assessment where immediate updating or disabling was not possible. Preserve the relevant web-server, PHP, hosting, and firewall logs. Ask the host or security team to investigate unexpected administrator accounts, modified files, unfamiliar scheduled tasks, or unusual server activity. These are leads to examine, rather than proof of PHP2Shell exploitation.
For plugins distributed through WordPress.org, developers can use WP-CLI’s checksum verification to compare files against the published package. A mismatch needs investigation; a match does not prove that the version has no vulnerabilities or that the rest of the server is clean. Commercial and custom plugins need their own trusted comparison sources.
If compromise is suspected, involve the host or an incident response specialist before deleting files or restoring service. Preserve evidence, establish a trusted recovery point, and rotate affected credentials from a clean environment. An incident snapshot can help an investigation, but should not automatically become the backup used to restore production.
That distinction carries into everyday maintenance: knowing which files should be on the site makes both investigation and recovery more manageable. A useful plugin inventory is the next place to start.
How to choose and maintain safer WordPress plugins
Plugins deserve ongoing scrutiny because they add executable code to the website. Some handle payments, customer records, uploads, or administrative settings. Others connect the site to an external service. The review should reflect what each plugin can access and what would happen if it failed.
WordPress’s hardening guidance recommends trusted distribution sources, prompt updates, and removing unused plugins. Turn that advice into a small, repeatable process instead of judging a plugin by its star rating alone.
Review each plugin’s installed version, access, and update path. AI-generated illustration.
Check the maintainer and the exact version
Download from WordPress.org or the developer’s official channel. Avoid cracked or “nulled” copies of commercial plugins, which leave you relying on an untrusted package and update path.
Read the changelog, compatibility information, and recent support responses. Look for evidence that the maintainer handles problems and explains security fixes. A long interval between releases is a reason to investigate, not proof that a plugin is unsafe. Frequent releases are not proof of security either.
Then search for the exact plugin name or slug, its identifier in the directory URL, in a vulnerability database such as Wordfence Intelligence, alongside the developer’s security notices. Compare your installed version with the advisory’s affected range and fixed version. The important question is whether your installation contains an unresolved issue. Finding no published advisory cannot establish that the code is vulnerability-free.
Understand access, data, and dependencies
Before activating a plugin, identify the job it needs to perform and the access that job requires. An analytics integration, payment connector, and code-snippet manager have different responsibilities. A plugin that writes files or executes administrator-supplied code warrants closer technical review than its settings screen may suggest.
For external services, check which information leaves WordPress, where credentials are configured, and who can change the connection. Review the service’s privacy and retention terms against the data you intend to send. Test with non-sensitive information before connecting customer records or business systems.
Keep an inventory with the plugin’s purpose, installed version, update source, responsible person, and recovery instructions. Ask the developer to include must-use plugins, which load automatically, and custom integrations that a routine dashboard review may miss. Review the purpose and maintainability of each component rather than setting an arbitrary plugin-count target.
Make updates and removal part of the process
Automatic updates can help when you have reliable backups, monitoring, and someone responsible for failures. WordPress’s plugin-management documentation explains how to enable them for individual plugins.
For a plugin that handles checkout, memberships, or another critical workflow, decide in advance who tests and deploys urgent releases. Keep the tests focused on that plugin’s business function so a security update can move promptly. If a serious vulnerability has no fix, assess disabling or replacing the plugin and any provider-recommended containment.
Delete plugins you no longer use after checking whether uninstalling them removes settings or business data. Deactivation leaves the files installed, so it should not become permanent storage for abandoned software. Before deleting anything during a suspected breach, preserve the evidence needed for the investigation.
Test connected plugins before launch
A plugin that connects WordPress to another service needs a functional test as well as a review of its permissions. Use staging and non-sensitive test data to check that it connects to the intended account, sends only the information you expect, and handles a failed connection without exposing sensitive details to visitors.
Test the workflow from the visitor’s side too. Does a submitted enquiry reach the right destination? Can an unauthorized user see information they should not have? If a customer-facing assistant cannot answer a request, can the visitor reach a person? Choose tests that reflect the plugin’s actual job.
Keep the results with the installed version and configuration. Record how to disconnect the service and who owns that decision. After an update, the team can repeat the same checks instead of relying on the settings page to say that everything is connected.
Use AI code review for the code you maintain
Plugin inventory and advisory checks work well for published software. Custom plugins, theme modifications, and private integrations need another layer of attention because their defects may never appear in a public database. AI can help a developer examine that code once immediate exposure is contained and patching is underway.
Start with a narrow scope: a public form, upload handler, import feature, or administrative action. Give the reviewer the relevant files and enough context to trace a request through the application. Ask it to explain what an unauthenticated visitor or lower-privileged user can do, which checks run, and where untrusted data reaches a sensitive operation.
Use a prompt that asks for evidence rather than a general assurance:
Prompt for your developer’s AI review
Review this custom WordPress plugin for security defects. Trace public REST routes, AJAX handlers, uploads, imports, and settings changes. Check authentication, capability checks, nonce use, input validation, output escaping, database queries, and attacker-triggered fatal errors. For each finding, provide the file and line, reachable entry point, required permissions, impact, supporting evidence, and a proposed fix with a regression test. Separate confirmed findings from questions that need investigation. Do not modify production.
Use an approved environment and exclude credentials and customer records. Have a developer verify each finding, inspect the proposed change, and test both legitimate requests and requests that should be rejected. GitHub’s documentation describes the risk of missed issues, false positives, and insecure suggestions in AI code review.
The resulting work should be a set of findings and tested fixes. A “no issues found” response cannot establish that the server is patched or uncompromised. Those conclusions still depend on deployment evidence and the incident investigation.
Conclusion
For PHP2Shell, the first priority is a confirmed fix to the PHP runtime serving your website. Ask your host for the patched build and deployment confirmation, then test the functions your business depends on. If the update is delayed, have the hosting team contain the exposure while it works. A maintenance screen or firewall dashboard alone cannot establish that the underlying problem has been resolved.
After the immediate response, use what you learned to improve everyday maintenance. Keep a current plugin inventory, remove software the site no longer needs, and assign responsibility for urgent updates. For custom code, use AI to help a developer find and investigate defects, with testing before changes reach production.
Keep the patch confirmation and test results with your maintenance records. The next security alert will be easier to handle when the team already knows what runs on the site, who can update it, and how to verify that the fix is live.
Rajni is a senior content writer at Delta4 Infotech covering AI agents, automation, and no-code tools. She writes across the AI space, from chatbots and customer support to MCP and agent workflows, focused on how businesses actually put these tools to work.
