If you run a WordPress business website, the useful question is whether your hosting's PHP runtime is patched and whether there are signs of an existing compromise. News of a vulnerability does not mean your website has been hacked.
Advisory reviewed: 22 October 2026. This article is guidance for planning a response, not a vulnerability scan or confirmation of your site's status.
What has been confirmed?
On 21 October, the PHP team released fixes for CVE-2026-109618 and CVE-2026-109619, which can permit unauthenticated remote code execution. The advisory covers PHP installations handling web requests. It identifies updating PHP as the complete solution; temporary mitigations only reduce particular attack paths. Read the official PHP advisory and release information for current technical details.
A WordPress core or plugin update does not update PHP itself. Hosting providers and operating-system vendors may supply patched packages, including backports. A public version string alone is therefore insufficient to establish patch status.
1. Ask your host for evidence
Start with a specific request rather than asking whether the hosting is generally secure. You can send this:
Please confirm whether the PHP runtime serving my website has fixes for CVE-2026-109618 and CVE-2026-109619. Please provide the installed package/build or vendor advisory, confirm the web workers are running the updated build, and identify any remaining action needed for my account.
On an agency portfolio, keep one row per site with the host, runtime, patch evidence, owner and verification date. Record an unknown status explicitly so it can be followed up.
2. Plan the update around your business functions
Our suggested workflow is to agree access and scope, preserve backups and available logs, establish rollback options, and then coordinate the update with the hosting owner. Compatibility concerns are a reason to organise the work carefully, not to leave an exposed runtime indefinitely.
- Check customer login and administrator access.
- Submit a clearly labelled test enquiry and verify both delivery and the visible confirmation.
- For WooCommerce, test cart, checkout and payment callbacks using an appropriate test mode.
- Check uploads, scheduled jobs and integrations relevant to the site.
- Document the result and any functions that could not be tested.
3. Treat suspicious activity as a separate investigation
If you see redirects, unexpected administrator accounts, unfamiliar files or repeated reinfection, tell the recovery team before changes overwrite evidence. These symptoms warrant investigation but do not identify the entry point by themselves.
Installing a patch does not remove an existing backdoor. Recovery may involve reviewing files, databases, scheduled tasks, accounts, credentials and neighbouring sites. If the hosting environment itself is compromised, rebuilding in a trusted environment may be more appropriate than editing individual files.
4. Make the handover useful
Ask for a written record of the verified build, the actions taken, the functions tested and the unresolved limitations. A malware scan alone is not proof that every persistence mechanism has been removed.
For a practical example of why persistence matters, read our 263-site agency recovery case study. It concerns prior recovery work; it is not evidence that those sites were affected by PHP2Shell.
Need help checking or recovering your website?
WebAdish offers PHP exposure assessments, coordinated patching and WordPress recovery. We agree scope and pricing before paid work starts.
Request PHP Security HelpSources
Found this helpful?
Protect your WordPress site
Get a Security AssessmentRelated resources
Continue with the pages buyers usually visit next after reading this topic.
Need Professional WordPress Security?
Our team of WordPress security experts protects 800+ sites. Let us protect yours.