PHP2Shell: What to Ask Your Hosting Provider Today

TL;DR: Contact the company responsible for your website today

Ask your hosting provider or IT partner to confirm whether PHP2Shell affects your website, online shop or application, whether the security updates are installed, and whether the live service is using them. You do not need to run server commands yourself. If protection cannot be confirmed, ask the provider whether access should be temporarily restricted while they fix it.

Why this matters to your business

PHP2Shell is the name given to two serious security flaws in PHP, software used to run many websites and business applications. An affected service could allow an outsider to run unauthorised instructions. Depending on the access available, this could put customer information, orders, website content and business availability at risk. These are possible consequences, not evidence that your business has already been attacked.

You may use PHP without knowing it. A website agency, software supplier or hosting company may manage it for you. Ask them to check rather than relying on the technology you see in your browser.

What you should do now

• Name one person to coordinate the response with your hosting provider, website agency and IT team.
• Ask them to check every website, shop and application they manage for you, including older sites and additional servers.
• Request a clear status, outstanding actions and a completion time. Agree when you will receive the next update.
• If nobody can confirm protection, ask the responsible technical team to assess temporary restrictions and the effect on customers and orders.

A blanket server shutdown is not a decision you need to make alone. Your provider should explain the exposure, containment options and business impact. If suspicious activity is already present, ask them to preserve evidence as they contain it.

A message you can send to your provider

Please check all websites, shops and applications you manage for us for PHP2Shell. Confirm which systems are affected, when the security updates were installed, whether the necessary services were restarted, and whether the live applications use the updated software. Please tell us whether you found signs of unauthorised access, what remains outstanding, who is responsible and when the work will be completed. If protection cannot yet be confirmed, recommend temporary measures and explain their effect on our business.

What a useful confirmation looks like

Ask for a written response naming the systems checked, the update and restart times, the checks performed and any remaining gaps. It should distinguish “protected against this vulnerability” from “no signs of compromise found in the evidence reviewed”.

“Updates are automatic” or “the website loads normally” is not enough on its own. Your provider needs to verify the software actually serving visitors. An update closes a security weakness; it does not remove an attacker who already gained access. Ask for a separate investigation if there are suspicious changes or alerts.

Need help deciding the next step?

Contact Farland Technology GmbH to discuss your website, your current provider's response and the support you need. Share the affected website addresses, the provider's written status and a contact person. Do not send passwords or other secrets through the contact form. Use the Request proposal link below to start the conversation.

Technical appendix: Ubuntu checklist for your IT team

Business owners can forward this section to the administrator. This example is for Ubuntu 24.04 LTS using Ubuntu-packaged PHP 8.3. Adapt it to the actual deployment. Arrange recovery and console access before production changes. If compromise is suspected, coordinate evidence preservation first.

1. Identify the runtime serving every application

cat /etc/os-release

php -v

dpkg -l 'php*' 'libapache2-mod-php*'

systemctl list-units --type=service --all 'php*-fpm.service'

CLI output alone does not establish the web runtime. Map each site's PHP-FPM service or Apache module and include all nodes, containers and separately supplied PHP builds.

2. Check the vendor notice and install the fixed packages

sudo apt update

apt policy php8.3-fpm php8.3-cli php8.3-common

sudo apt upgrade

Review the proposed changes and investigate held packages or errors. Compare the full package version and origin with USN-8948-1; Ubuntu backports fixes, so the upstream version alone can mislead. Consult USN-8948-2 for older releases and confirm support entitlement. Separately supplied builds and container images require their own updates.

3. Restart the relevant services

For the PHP-FPM example:

sudo systemctl restart php8.3-fpm

systemctl is-active php8.3-fpm

For Apache mod_php instead:

sudo systemctl restart apache2

systemctl is-active apache2

Choose the applicable commands. Replace every affected worker, including long-running application processes. Reloading Nginx alone does not replace PHP-FPM workers.

4. Verify the result and record the work

sudo journalctl -u php8.3-fpm --since '15 minutes ago' --no-pager

Check the installed packages against the running web service and protected application diagnostics. Do not leave a public phpinfo page. Test sign-in, forms, orders, uploads and background jobs on every node. Record versions, restarts, results and unresolved items. Patching does not establish that the system was never compromised.

Sources and review date

Published 21 October 2026. Last reviewed 22 October 2026. PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619.

• Ubuntu update guidance: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
• Fixed Ubuntu packages: https://ubuntu.com/security/notices/USN-8948-1
• Older Ubuntu releases: https://ubuntu.com/security/notices/USN-8948-2
• PHP security announcement: https://www.php.net/archive/2026.php#2026-10-21-5