PHP2Shell: website host and compatibility check
Prepared 22 October 2026 by Turing Websites
Editable planning record. Use with your hosting provider or developer.
This is not a security clearance or evidence that remediation has occurred.

WEBSITE AND OWNERSHIP
Public website URL:
Platform/CMS and version, if known:
Host and hosting plan:
Hosting support ticket/reference:
Person authorised to approve runtime changes:
Developer responsible for application compatibility:
Customer journeys to check (enquiry, login, booking, checkout):

1. ASK THE HOST TO CONFIRM THE RUNNING WEB RUNTIME
Reported web-serving PHP version and handler, if known:
Host-confirmed installed package/build:
Vendor notice covering CVE-2026-109618 AND CVE-2026-109619:
Confirmation date, time and timezone:
Has the supported package been applied to this specific site?
Have required worker restarts/replacements completed?
Is any action still required from the website owner?

Upstream fixed releases: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
Use a fixed release or a later maintained release on that branch.
An older-looking distribution/LTS package may contain a vendor backport.
Obtain vendor confirmation for both CVEs and the actual installed build.
PHP 8.1 and older have no routine upstream security releases. Exceptional
source backports do not restore routine upstream support.

WordPress: Tools > Site Health > Info > Server shows a reported PHP version.
A WordPress core/plugin/theme update does not apply the PHP runtime fix.
Ask the host to verify this site's serving runtime, not only a CLI version.

2. AGREE COMPATIBILITY AND CHANGE RESPONSIBILITIES
Dependencies/extensions requiring compatibility checks:
Isolated staging environment, if available:
How staging is disconnected from live payments and customer email:
Code recovery point and location (reference only, no secrets):
Database recovery point and location:
Uploaded-file recovery point and location:
Hosting/runtime owner and agreed update action:
Website developer and agreed application action:
When and how the running package will be verified:

3. RECORD CUSTOMER-JOURNEY CHECKS
Use authorised dummy records and provider-supported payment test mode.
Agree handling of test records and notifications before testing.

Action and tested URL:
Environment and time/timezone:
Expected result:
Observed result:
Saved record or order reference (redacted):
Confirmation/notification destination and result (redacted):
Checker and outstanding action:

Repeat for each agreed journey. A working homepage does not establish that
forms, bookings or checkout work. These checks do not establish absence of
compromise. Security investigation needs the appropriate specialist.

4. IF THE UPDATE IS BLOCKED OR COMPROMISE IS SUSPECTED
Ask the host to follow the current official mitigation guidance. PHP says
temporary measures are incomplete. A WAF or isolated setting is not a fix.
If the host cannot update and cannot apply temporary mitigations promptly,
UK NCSC advice includes considering taking affected systems offline until
fully mitigated. Ask hosting security support or an NCSC-assured incident-response
provider to handle suspected compromise, preserve evidence and use a secure channel.

5. PREPARE A REDACTED ENQUIRY
Website URL:
Host/platform:
PHP version or host's package confirmation:
Customer actions requiring compatibility checks:
Authorised code/hosting access available (describe, do not send passwords):
Requested scope or question:

Enquiry: https://turingwebsites.com/contact?enquiry=website-repair#enquiry
Guide: https://turingwebsites.com/blog/php2shell-php-security-update-help
Keep passwords, API keys, raw logs and customer records out of the form.

CURRENT PRIMARY GUIDANCE
PHP release and mitigation guidance:
https://www.php.net/archive/2026.php#2026-10-21-5
WordPress owner guidance:
https://wordpress.org/news/2026/10/critical-php-security-release/
UK NCSC advice and incident-response route:
https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php