# Your server says PHP 8.3.6. Is it fixed for PHP2Shell?

You read the PHP2Shell advisory. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. You log in to your Ubuntu 24.04 server, run `php -v`, and it says `PHP 8.3.6`. That is thirty patch releases below 8.3.36.

Is the server exposed? Maybe not. This article shows how to get a real answer in about five minutes.

## Why the number can lie

PHP2Shell (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2) is a pair of flaws in PHP itself, not in WordPress, Laravel or any other app. The PHP project published the fixes on 21 October 2026 ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)). The research is on [php2shell.com](https://php2shell.com/).

Linux distributions do not jump to a new upstream release in a stable branch. They take the fix, apply it to the version they already ship, and add a build number to the package version. So the upstream number stays the same, and only the package version changes:

| Distribution | Package | Fixed package version |
| --- | --- | --- |
| Ubuntu 24.04 LTS | php8.3 | `8.3.6-0ubuntu0.24.04.13` |
| Ubuntu 22.04 LTS | php8.1 | `8.1.2-1ubuntu2.28` |
| Ubuntu 26.04 LTS | php8.5 | `8.5.4-0ubuntu1.5` |
| Debian 13 trixie | php8.4 | `8.4.27-1~deb13u1` |
| Debian 12 bookworm | php8.2 | `8.2.35-1~deb12u1` |
| RHEL 9 (default stream) | php | `8.0.30-8.el9_8.1` |
| RHEL 10 | php | `8.3.36-1.el10_2` |
| Alpine v3.23 and newer | php83 | `8.3.36-r0` |

These are the versions published by each vendor as of 22 October 2026. Vendors add and change entries, so confirm on your vendor's security tracker before you decide.

The important part: `php -v` and the `X-Powered-By` header both show only `8.3.6`. Neither shows the `-0ubuntu0.24.04.13` part. To know, you have to read the package.

## Step 1: find the PHP that serves your site

`php -v` answers for the command-line PHP. Your site runs on PHP-FPM, Apache `mod_php` or `php-cgi`, and that can be a different install. Find the one that serves requests first.

```bash
# PHP-FPM services that are running
systemctl list-units --type=service 'php*'

# Apache with mod_php?
apachectl -M 2>/dev/null | grep -i php
```

On Debian and Ubuntu, each branch has its own FPM binary:

```bash
php-fpm8.3 -v
```

On RHEL, AlmaLinux and Rocky it is `php-fpm -v`. If you are still not sure, put a `phpinfo()` page on the site, read the **Server API** line, and delete the page right after.

More than one branch on the box is common, for example 8.1 for an old site and 8.3 for the rest. Every branch that serves a site counts.

## Step 2: read the package version

Debian and Ubuntu:

```bash
dpkg-query -W -f='${Package} ${Version}\n' 'php*-fpm' 'php*-common' 'libapache2-mod-php*' 2>/dev/null
```

RHEL, AlmaLinux and Rocky:

```bash
rpm -q php-common php-fpm
dnf module list php   # the enabled stream is marked [e]
```

Alpine:

```bash
apk info -v | grep '^php'
```

## Step 3: compare it with the fixed build

Do not compare by eye. Let the package manager do it. On Debian and Ubuntu:

```bash
installed=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$installed" ge "8.3.6-0ubuntu0.24.04.13" \
  && echo "at or above the fixed build" \
  || echo "older than the fixed build: update"
```

Put your own package name and your release's fixed version in the command. On RPM systems, `rpmdev-vercmp` (from `rpmdevtools`) does the same job.

Two traps:

- **AlmaLinux and Rocky have their own build strings.** AlmaLinux builds end in `.alma.1`, and Rocky module builds have their own suffix. Compare with your distribution's string, not with Red Hat's.
- **Ubuntu 20.04 and older** get the fix through Ubuntu Pro (ESM). Without Pro, `apt upgrade` does not install it.

## Step 4: update, then restart

If the package is older than the fixed build, update it:

```bash
# Debian / Ubuntu
sudo apt update && sudo apt upgrade

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade 'php*'

# Alpine
apk update && apk upgrade
```

Then restart. This is the step people forget. Running PHP processes keep the old code in memory until they stop, so a new package on disk changes nothing yet.

```bash
sudo systemctl restart php8.3-fpm   # use your branch
sudo systemctl restart apache2      # or httpd on RHEL
```

Restart queue workers, Laravel Octane, Symfony Messenger consumers and any other long-running PHP process too. Then repeat Step 1 and Step 2 to confirm what is running now.

## Containers

`docker restart` keeps the old PHP, because the PHP is in the image. Pull the updated base image, rebuild your image and recreate the container. Official `php` images use upstream releases, so look for 8.2.35, 8.3.36, 8.4.27 or 8.5.12 there. Images built on a distribution's own PHP packages follow the distribution table above.

## PHP 7.4, 8.0 and 8.1

The PHP project ships no new release for these branches. Its security team published source patches for 7.4, 8.0 and 8.1, for people who build PHP themselves. Everyone else needs a fixed build from a distribution, host or LTS vendor (for example Ubuntu 22.04's `8.1.2-1ubuntu2.28`, or RHEL 8's php:7.4 stream), or a move to 8.2 or newer. Note that 8.2 itself reaches end of life on 31 December 2026.

## What the outside view can and cannot tell

From outside, the only version hint is the `X-Powered-By` header, which PHP adds when `expose_php` is on:

```plaintext
X-Powered-By: PHP/8.3.6
```

That one line is useful. `PHP/8.3.12` on branch 8.3 is clearly below 8.3.36, and no distribution ships that number as a fixed build. But `PHP/8.3.6` can be either the old Ubuntu build or the fixed one, because the header never shows the package suffix. And a missing header tells you nothing at all. Hiding it with `expose_php = Off` is fine hardening, and it does not fix PHP2Shell.

A header is a hint, not proof. Use it as a quick first look at your own sites, then confirm on the server with the steps above. Our team built a free checker that reads the header and knows these distribution builds. It answers "not fixed", "fixed release", "check the package" or "cannot tell": [php2shell.fyi](https://php2shell.fyi/?ref=hashnode).

## Checklist

1. Find every PHP that serves a site (FPM pools, `mod_php`, containers).
2. Read the full package version, not `php -v`.
3. Compare it with your vendor's fixed build using the package manager.
4. Update, then restart PHP-FPM, Apache and long-running workers.
5. On 7.4, 8.0 or 8.1, get a vendor build or plan the move.
6. After the update, rotate the secrets PHP could read on hosts that ran an affected version. The flaws can leak server memory.

---

*This article was drafted with AI assistance and checked by the php2shell.fyi team. php2shell.fyi is unofficial and not affiliated with PHP or* [*php2shell.com*](http://php2shell.com)*. Package versions are as published by each vendor on 22 October 2026.*