SiteGround PHP2Shell status: what it says and how to confirm

SiteGround says it applied mitigations on its servers before the PHP fix shipped on 21 October 2026 and applied the official fixes afterwards. Its post, last updated 22 October, tells customers to do nothing. That is SiteGround describing its own fleet. For your domain, ask support for the fixed build and the worker restart time.

What does SiteGround actually say about PHP2Shell?

SiteGround published a post on its own blog titled "SiteGround moves early to protect customers ahead of critical PHP security release". At our check on 26 October 2026 the post said the following, in our words:

• Mitigation rules were in place before PHP published the fixes, and the official fixes were applied across all SiteGround servers after the release on 21 October.
• The affected functions were disabled on all supported PHP versions.
• Customers do not need to update, change settings or switch PHP versions.
• People running PHP elsewhere need to update to a fixed version themselves or check with their host.

The post also carries staff replies. One dated 22 October says patches and mitigations are applied across supported PHP versions, and that customers can keep their current PHP versions. One dated 23 October says sites on a manually selected PHP version, including 7.4, are covered by the server-level mitigations. These are SiteGround's own statements and we have no independent check of them.

So SiteGround does state its coverage: all of its servers, and supported PHP versions whether chosen manually or through Managed PHP. That is a claim about the fleet. The post names no build, no package and no restart time for your domain, which is why evidence for a specific domain has to come from support.

Who needs to check more than the blog post?

Anyone who needs evidence for a specific domain, and these cases most of all:

• A manually pinned PHP version. SiteGround's PHP Manager lets you choose a version, and SiteGround does not change it for you. A staff reply on the post says manual selections are covered. If you pinned a version, ask support to confirm that exact runtime in writing.
• Client sites you are accountable for. An agency answers to the client, not to a host blog post, and how liability splits between agency and host is worth settling before something goes wrong.
• PHP you run yourself or on another provider. SiteGround's post tells people running PHP elsewhere to update on their own, so its statement does not cover that runtime.
• Anyone who saw an old PHP version on the site after 21 October. See the next section.

Why can a "patched" host still show an old PHP version?

Three things make the number on screen a weak signal. They apply to any host.

1. Fixes can ship without a new version number. PHP's notice says Linux distributions and LTS vendors received the patches in advance, and that some provide backported fixes for PHP 8.1 and older. Our guide to the two PHP flaws explains how to read package changelogs.
2. The panel shows the branch. SiteGround's PHP Manager, under Devs in Site Tools, is where the PHP version is set and its management status shown. It does not show the build behind it.
3. Mitigation is not the fix. PHP's notice says mitigations reduce exposure to specific attack paths but do not make an installation safe, and that only an update is a complete solution. SiteGround says it did both: mitigations first, official fixes after.

For the fixed releases by branch, see the fixed versions table.

How do I confirm my SiteGround site?

What does the panel show?

• Sign in to Site Tools for the site.
• Open Devs, then PHP Manager, as SiteGround's guide describes, and note the PHP version shown and whether it is set to managed or pinned.
• Write the date and time you looked. A screenshot with a timestamp helps if you need to show a client.

Menu names can change. Use what you see in your own Site Tools.

What do I ask support for?

Send this through the support chat or a ticket and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP workers serving it have been restarted or replaced since the fix was applied, and say whether I need to change a setting, including because I chose my PHP version manually.

• Reply names a build, package or backport, not only "no action needed".
• Reply gives a restart or deploy time after the fix.
• Reply covers your domain and your PHP setting, pinned or managed.
• You stored the reply with its date.

If you also run a site on another host, the same question works there. We have pages for Kinsta and WP Engine, and for Bluehost and Hostinger, with the rest in the other host status guides.

Am I affected? A three-state self-test

Was anything exploited before the fix?

AWS reported honeypot attempts from 17 October, four days before disclosure, and broader attempts after public proof-of-concept code appeared. AWS says it is unclear whether the early attempts would have worked on real systems, and that is vendor telemetry. Our exploitation page tracks the sources. SiteGround's post does not say any customer site was affected.

If you want an outside read of what your site exposes, the free scan lists the technologies and versions it serves. Your own server holds the evidence of whether something was planted: unexpected PHP files in upload directories, scheduled tasks you did not create, and new administrator accounts. AWS also recommends reviewing web server logs and looking for unexpected processes started by the web application server.

What is the bug, without the exploit?

PHP's notice says both CVEs can allow unauthenticated remote code execution. It describes CVE-2026-109618 as out-of-memory handling that can interrupt PHP while request data is partly initialised. It describes CVE-2026-109619 as request state that survives after its memory is freed and is used by a later request on the same worker. We do not reproduce exploit material or proof-of-concept code. You do not need them to fix a site.

A separate 23 October php.net notice says CVE-2026-115560 is handled in the regular release cycle, with a full advisory to be published with the next release. It suggests setting session.upload_progress.enabled=0 until then, and says the issue needs an unusual combination of configuration and application code. It is a different issue from the two above, and we will cover it once the advisory is published.