# Hosting provider PHP update confirmation: how to ask about patch status

> How to get reliable confirmation of the PHP update from your hosting provider after PHP2Shell: which details count, a copy-ready template, how to judge the answer.

Source: https://phpsos.de/en/ratgeber/hoster-patch-status-erfragen/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** After PHP2Shell, the displayed PHP version alone proves little, because hosting providers often apply fixes as a backport. Request a written hosting provider PHP update confirmation instead: package status per PHP branch, time of installation and restart of all PHP processes. A copy-ready template follows below.

## Why a written confirmation matters right now

On 21 October 2026 the PHP project released the patches for two critical vulnerabilities known as PHP2Shell. Both allow remote code execution without authentication. The BSI (German Federal Office for Information Security) declared warning level 3 / orange and recommends the immediate update.

If you run your website with a hosting provider, you often cannot apply the update yourself. At the same time, as the operator you are responsible for your customers' data. A written, specific confirmation from the provider is therefore more than a formality. It is a building block of your documentation, for example towards data protection officers, insurers or management.

There is another point: a patch does not remove malware that was planted beforehand. According to media reports, a first attack attempt was already observed on 17 October. The exact time at which your server was protected is therefore important for the question of whether you need to keep checking.

## Why the displayed PHP version is not enough

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Many distributions and hosting providers, however, take over the fix as a backport into their own package. An interface such as Plesk then keeps showing 8.2.34 even though the server is patched.

Conversely, a correct version number can be misleading. New files alone do not protect you as long as old PHP processes are still running in memory. Only after a restart of all workers is the new state active. More on this in the article [Checking the PHP version and patch status correctly](https://phpsos.de/en/php2shell/php-version-pruefen/).

| Statement from the provider | What it proves | What is still missing |
|---|---|---|
| “All systems are up to date.” | little | Version or package status, date, restart |
| “PHP 8.3.36 is installed.” | Version | Date, restart, affected servers |
| “Backport in package xy, restart on …” | Patch and activation | Possibly details on PHP 8.1 and older |

## Which details you need from your hosting provider

Ask for answers to these points, preferably per website or contract:

- Which PHP branches and versions are active for your websites, including older ones that run only for individual directories?
- Do they include the fixes for CVE-2026-109618 and CVE-2026-109619, as an official version or as a backport?
- When was the update installed, and when were all PHP processes (FPM pools, Apache, LiteSpeed) restarted?
- Is `session.upload_progress.enabled` disabled because of CVE-2026-115560?
- Which operating mode does your plan use, for example PHP-FPM or Apache with mod_php? With mod_php, the PHP team sees the highest risk.
- Which access and error logs from 20 October 2026 onward are kept, and how do you get them?

If a website still runs on PHP 8.1 or older, ask about it separately. For these branches there are no official updates any more, only minimal source backports for 7.4, 8.0 and 8.1.

## Template: requesting hosting provider PHP update confirmation

Copy the text into a support ticket or an email to your hosting provider. Fill in the details in square brackets.

```text
Subject: Request for confirmation of the PHP patch status (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)

Hello,

we run the following websites / contracts with you:
[customer number, contract, domains]

In connection with the PHP vulnerabilities CVE-2026-109618 and
CVE-2026-109619 (PHP2Shell, patches of 21.10.2026) and the notice
on CVE-2026-115560 of 23.10.2026, we ask for written
confirmation of the following points:

1. Which PHP versions or package states are active for our websites?
2. Do they contain the fixes (official version or backport)?
3. Date and time of the installation.
4. Date and time of the restart of all PHP processes (FPM, Apache,
   LiteSpeed or similar).
5. Is session.upload_progress.enabled disabled on the server side?
6. Which PHP operating mode is used (e.g. PHP-FPM, mod_php)?
7. Are access and error logs retained from 20.10.2026 onwards, and
   how can we obtain them?
8. If a website still uses PHP 8.1 or older: What protection is in
   place there, and which upgrade do you recommend?

We need this information for our internal documentation.

Thank you and kind regards
[Name, company, role]
```

## Judging the answer correctly and cross-checking it yourself

A good answer names concrete states, dates and times. General wording such as “we have responded” is not enough for your records. In that case, politely ask for the missing points.

If your plan allows it, also check for yourself. With SSH access, these commands are usually enough:

```bash
# Command-line version (may differ from the web version)
php -v
# Package status on Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Package status on RHEL, Alma, Rocky
rpm -qa | grep -i php
# Since when have the PHP-FPM processes been running?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
```

If the start time of the PHP processes is before the confirmed installation date, the restart was not complete.

### If the hosting provider does not answer, or answers evasively

If no answer arrives or the decisive details are missing, you should not regard the matter as settled. The BSI recommends temporarily taking web servers off the network if an update is not immediately possible. Whether that is proportionate for your website is for management to decide, ideally in writing and with a date.

In parallel, it is worth looking for possible traces of an attack, because the time of the patch remains open. The article [Am I already compromised?](https://phpsos.de/en/php2shell/bin-ich-gehackt-anzeichen/) offers pointers. Without SSH access, the written confirmation remains your most important piece of evidence. Which duties lie with the hosting provider and which with you is explained on the page [Shared hosting: what the provider does](https://phpsos.de/en/server/shared-hosting/); for managed servers, [Managed server: clarifying responsibility](https://phpsos.de/en/server/managed-server/) helps.

> **Tip:**
> File the request, the answer and your own check results with dates in one folder. This record helps later with questions from insurers or data protection officers.

## How does PHP SOS help?

- Together with you, we draft the request to the hosting provider and assess the answer from a technical standpoint.
- Where we have access, we check the package status, the active operating mode and the restart of the PHP processes ourselves.
- If gaps remain, we implement interim measures or plan the move to a supported version.
- We record the result and the timestamps in a document you can pass on internally.

How the update with restart and proof works is described in our [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/).


## Frequently asked questions

**Is it enough if my hosting provider writes that everything is up to date?**  
For your documentation, probably not. Ask for specifics: package status or version per PHP branch, the date of installation and the date all PHP processes were restarted. Only with these can you narrow down the window of vulnerability.

**Why does my hosting interface still show PHP 8.2.34?**  
Distributions and hosting providers sometimes apply security fixes as a backport without changing the version number. Plesk may then keep showing 8.2.34 even though the server is patched. Only the provider's confirmation of the package status gives clarity.

**What do I do if the hosting provider does not respond?**  
Document your request with the date and ask again after a reasonable time. In parallel, check whether you can apply interim measures yourself, and agree with management whether the website goes offline until this is clarified, as the BSI recommends for unpatched servers.

**Does a WordPress or shop update close the vulnerability as well?**  
No. PHP2Shell sits in PHP itself. An update of the CMS or the shop software changes nothing about the PHP interpreter running on the server.

## Sources

- [php.net: security announcements](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: supported versions](https://www.php.net/supported-versions.php)
- [BSI: German Federal Office for Information Security](https://www.bsi.bund.de/)