PHP2Shell and Shared Hosting: Questions to Ask Your Hosting Provider

When a serious vulnerability in PHP is made public, customers using shared hosting have to deal with a real problem since they rely on software that they cannot control directly.

You could perhaps carry out a WordPress update, install a plugin, or modify a setting in your hosting control panel; nevertheless, your hosting provider will be in charge of the underlying PHP packages, worker processes, and server configuration.

It means that communication plays a vital role in protecting your website.

With regard to PHP2Shell, you must obtain specific confirmation that the PHP runtime which is serving your websites includes the relevant fixes. A mere assertion that the hosting platform is secure does not prove that your account is up to date with the patches.

The announcement by PHP identifies the two initial vulnerabilities—CVE-2026-109618 and CVE-2026-109619—as possible means of achieving unauthenticated remote code execution.

The guide outlines the questions you should ask, what acceptable answers are, and how to keep track of work that remains unresolved. The incident-specific information is based on the advisories available on October 30, 2026.

Why Shared Hosting Changes the Conversation

What shared hosting usually involves is several customers' websites using facilities that are run by a hosting company.

The setup changes from one customer to another. Some have different PHP versions. Others use different execution settings, access permissions, or service plans.

The first problem for the website owner is to work out which responsibilities belong to the provider and which stay with the customer.

The developer could be in charge of the application while the provider looks after the PHP. Alternatively, a different service might handle the backups or monitoring.

If the duties are not clearly divided, then each party might think that someone else has carried out the update.

The first step is to find one person who is in charge of gathering the responses and monitoring the matter as it goes through the verification process.

Question 1: Is My Account Using a PHP Deployment That Is Affected?

Request that the provider evaluate the real services that are being used on your websites.

A useful request is:

Could I get a review of the PHP deployments for my account and find out if they were impacted by CVE-2026-109618 and CVE-2026-109619?

Send the relevant domains and account identifier via the provider's authenticated support channel.

It would be a mistake to think that a public status announcement includes all of the legacy plans, additional domains, or applications that are separately configured.

The response must state the scope of the review; if the provider has only evaluated your primary domain, then the other services should still be open to review.

Question 2: Which PHP Package Is Actually Being Run?

The dashboard label 'PHP 8.4' might not include the full package revision required to verify a security update.

Ask:

Which PHP version or patched package revision is currently being used for each of my websites?

The word 'actively' is important; the package that has been installed, the dashboard option that has been selected, and the service that is running all have to refer to the same deployment.

Also find out if different domains make use of different PHP installations.

An appropriate response should associate each website with the corresponding runtime and provide sufficient package information so that one can check the security coverage.

Store your maintenance records rather than depending on your memory.

Question 3: Does the update include both of the original CVEs?

Use both identifiers explicitly:

• CVE-2026-109618
• CVE-2026-109619

Request that the provider verify its update includes both.

The Canadian Centre for Cyber Security lists these releases containing the original fixes:

Reference points of a specific nature are provided and you should check for any further applicable updates; the advisory also states that certain distributors and long-term support vendors offer backported fixes.

Ask the vendor for the advisory and the package revision that support the use of a backport.

You shouldn't call a package unpatched just because its version string is different from the upstream release.

Question 4: When did the fix become active?

Request the date and time at which the update came into effect, including the time zone.

There differs the act of announcing an update, the process of installing it, and that of verifying the service which is running.

A useful request is:

When was the updated PHP package activated for my account, and how did you confirm that the appropriate workers and instances were using it?

This information serves to define the end of the possible exposure period.

This also helps the person who maintains your application to know when to look at the errors or carry out compatibility checks.

If the provider is unable to give the exact time, then ask them to provide the evidence that is available together with an indication of the uncertainty.

Question 5: Is my website using PHP-FPM or mod_php?

The announcement from PHP covers a number of web-serving environments that are within the scope of the risk assessment and identifies mod_php as the most risky configuration.

Find out from the provider which PHP handler is used for your websites.

The answer won't replace patch verification; it will instead help to improve your inventory.

A reply stating that "we use PHP-FPM" must still make it clear whether the current runtime includes both fixes.

Do not request support to alter the server architecture unless you have a clear understanding of the impact on the application and its maintenance. Set up the current protection first and then look at any more extensive migration as a separate project.

Question 6: Does My Question Concern All of My Domains and Also the Earlier Installations?

Provide a list of relevant services:

• Main website.
• Additional domains.
• Subdomains.
• Customer portals.
• Staging websites.
• Those older installations which are still accessible.

Request that the provider point out any exceptions.

For instance, an account could include a main WordPress website together with an older application which has its own settings, and a confirmation pertaining to one of them should not fail to close the task for the other.

Use a simple record:

After your normal procedure, turn off any services that you no longer need, making sure to keep any necessary records.

Question 7: Who is responsible for making changes in the Hosting Dashboard?

Inquire instead as to whether the provider has already applied the fix or if you need to choose a supported PHP version.

The official advice from WordPress states that it is the hosting companies that decide which versions of PHP are available and that a number of them let customers make their own choice.

It would be wrong to suppose that either of those arrangements applies to your account.

A good response should specify the action that is required of the customer, indicate the domains that are affected, and outline the procedure to be followed.

If no action is needed, request confirmation that the statement refers to the currently active deployment and not just the versions listed in the dashboard.

Question 8: Have you had a look at the separate PHP session advisory?

On October 23 PHP issued a further notice with regard to CVE-2026-115560. This notice outlines an unusual combination of configuration and application behaviour and suggests that session upload progress be disabled until the next regular bugfix release as a measure to protect against that vulnerability.

Find out from your provider if they have looked at that notice and whether your deployment requires any action.

Keep this separate from the confirmation of the two original fixes.

It would be wrong to assume that one finished maintenance ticket provides protection against all later PHP problems.

If it is necessary to make adjustments, the operator who is responsible should apply them and check that they are correct in the relevant context.

Question 9: Are You Relying on Patches or on Temporary Filtering?

A provider can refer to firewall rules, request filtering, or temporary restrictions.

Find out what those controls are for and what still remains unresolved.

PHP considers updating to be the only way of solving the original vulnerabilities, while configuration measures help to eliminate specific attack paths without making the installation completely safe.

A useful follow-up is:

Does your confirmation indicate that the runtime has been patched or that the temporary controls are merely filtering the selected traffic? If the temporary controls still need to remain in place, when will the runtime update be finished?

Leave the patch task open until the condition intended for its completion is achieved.

Question 10: What Is the Method of Separating Customer Accounts?

Customers using shared hosting should find out how the provider restricts access between accounts.

Ask for a simple explanation of the boundaries relating to files, process identities, configuration, and credentials.

PHP-FPM does allow the use of pools that have different operating-system identities and settings, but the fact that FPM is present does not show how a particular provider set those boundaries.

Find out which one applies to your plan.

It would be wrong to suppose that the breach of one customer's information automatically affects all the other customers. Likewise, the term "isolated" should not be accepted as a full explanation of the controls that are in place.

The provider is not allowed to make known any sensitive implementation details, but it can explain the scope and limitations of the protections it offers to its customers.

Question 11: Could My Account Have Been Exposed Before the Patch Was Applied?

Get the best assessment that is currently available regarding the earlier deployment.

Ask:

• At what time was the package that was affected being used?
• Was the service accessible to the public?
• Were the restrictions temporary?
• Do there exist gaps in the deployment history?

Exposure does not mean someone has broken in successfully.

Yet the confirmation from the current patch does not deal with all the questions concerning the period before the fix came into effect.

Take the provider's assessment and record it separately from the present runtime status.

If the dates are still uncertain, then find out which records could reduce the window.

Question 12: Have you looked into any suspicious activity?

Inquire of the provider as to whether they have looked at the relevant activity or whether they have merely installed the update.

The advisory from Canada suggests that the relevant logs be examined and that any unexpected processes, commands, files, accounts, or outgoing connections linked to PHP or web services be investigated.

An answer that is useful includes a description of the systems, the time period concerned, the sources of evidence, and the limitations examined.

The statement "no evidence found" has meaning only within that scope.

One must not take this as evidence that an attack did not take place anywhere or at any time.

If the provider doesn't provide investigation support as part of your plan, find out what information it can give to your security adviser.

Question 13: Which Logs Are Available and for How Long Are They Retained?

Inquire as to the records available for your account and those of the underlying environment.

Make it clear if you have the ability to access web requests, application errors, authentication activity, deployment history, or any other pertinent records.

Also ask for the retention periods and the time-zone information.

If it turns out that an investigation is needed, request that the provider keep the records until the standard retention procedures would otherwise delete them.

Use secure support channels to share incident material. Do not post full logs or configuration files in public.

If it is the case that some records are missing, then note that limitation. You cannot use logging that is currently enabled to reconstruct events that were never recorded.

Question 14: What kind of recovery support is provided?

Find out what the provider will do should compromise be confirmed.

Clarify who handles:

• Preserving relevant evidence.
• Containing unauthorized access.
• Evaluate the files and accounts that are affected.
• To rebuild or restore the services.
• Reviewing exposed credentials.
• Testing recovery.
• Presenting the final results.

Find out if those services are included, charged separately, or beyond the provider’s scope.

It is particularly important when the responsibilities of a website owner, an application developer, and a hosting company are all different.

It is better to have already decided how the work is to be divided than to find out the boundaries while dealing with an urgent incident.

Question 15: What measures will we take to deal with compatibility problems?

Inquire into the testing procedure for the update and find out what will occur if an older plugin, theme, or custom feature ceases to function.

It is recommended by WordPress that you take steps to prepare for changes to PHP by carrying out backups, maintaining your application, and reviewing compatibility.

The list of practical tests should show the business functions of the website.

According to necessity, check account access, completed forms, uploads, orders, notifications, and all other important workflows.

When a problem arises, designate an owner and carry out the necessary correction. Do not allow compatibility work to become a reason for indefinitely leaving the exposure unresolved.

How to Evaluate the Provider’s Answer

Instead, look for evidence and a clearly established scope rather than just relying on reassuring language.

"Everything is secure." – Which domains, packages, and CVEs did you check?

Does the currently used runtime include both the fixes?

“Your website appears all right.” – What records were looked at regarding an earlier compromise?

They follow-ups serve to turn a support conversation into a reviewable result.

That doesn't provide a basis for rejecting a provider who uses different technical terminology, and you should ask for clarification if the meaning is unclear.

A Support Message You Can Send

Hello Support Team,

Could I have the PHP deployments for my account with regard to CVE-2026-109618 and CVE-2026-109619 please reviewed?

Could you please confirm what the current PHP version is or what patched package revision it is, when the fixes came into effect, and whether all of my relevant domains and instances are included?

Could you also explain if temporary filtering is being used, whether you have looked at the advisory regarding the upload progress of the separate session, and if any action is needed from me?

If it is possible to have earlier exposure, then please keep the records that are available and specify what kind of investigation and recovery support is provided in my plan.

Please point out any items that have not yet been resolved together with the dates on which they are expected to be completed.

Thank you.

You should only provide your domain list and account details via the provider's authenticated channel.

What if the provider is unable to give a clear answer?

Ask the team that looks after PHP packages or server operations to look into it.

Stick to a factual and specific approach and ask for an owner as well as a completion deadline.

If the update is still being blocked, you should discuss the temporary restrictions. The Canadian advisory suggests that it be considered to isolate internet-facing applications in the case where immediate remediation is not possible.

If there are ongoing problems with support or maintenance, it is advisable to consider alternative hosting arrangements involving a planned migration. You should check the application's compatibility, the data transfer process, the backups, the DNS changes, and the retirement of the old deployment.

The fact that you move the website does not by itself answer questions regarding a previous intrusion or about credentials that were exposed.

Frequently Asked Questions

Can shared hosting provide protection against PHP2Shell?

Check out the real provider and the way in which their system is deployed. Make sure that the patched runtime is covered, that the responsibilities are clear, and that the appropriate operational controls are in place.

Does updating WordPress fix the hosting server?

A WordPress update doesn't indicate whether the PHP runtime is patched; you should ask the provider to check this separately.

Do I need root access to reply?

Verification can be coordinated and the request for evidence made without the need to take direct control of the server. It is the responsible operator who carries out the infrastructure work.

Does the fact that another customer has been compromised show that my account has been hacked?

Not at all—request that the provider examine the appropriate boundaries and the available evidence concerning your account.

Is having a backup sufficient?

While a backup can be used for recovery planning, it does not carry out the task of patching PHP or ensure that the saved content is trustworthy.

Should I switch providers right away?

Start by carrying out specific verification and escalation; if the provider is unable to deal with the substantial gaps, then plan the migration while at the same time managing the existing exposure and any incident concerns.

Keep the Answers With Your Maintenance Records

The aim is to keep a clear account of what benefits your website, which fixes are currently in effect, who has verified them, and what issues remain open.

Keep the provider’s responses together with your notes on domain inventory and application maintenance.

You thus have a practical basis for taking action at the moment and a more clear starting point when the next urgent security advisory comes along.

Sources

1. PHP security advisory: CVE-2026-109618 — RCE via OOM corruption.
2. PHP security advisory: CVE-2026-109619 — RCE via stale global state.
3. CISA: Known Exploited Vulnerabilities Catalog.
4. Canadian Centre for Cyber Security: AL26-026 — Critical vulnerabilities impacting PHP.
5. WordPress: Updating PHP.
6. PHP: FastCGI Process Manager (FPM).