Check a php -v output against PHP2Shell
Runs in your browser with the same rules as the command-line tool. Nothing you paste leaves this page.
Package line from one of: dpkg-query -W 'php*' · rpm -qa 'php*' · apk info -v | grep php · cat /etc/os-release
This page sees only what you paste. A server usually has several PHP builds, and running workers may still use old code. sudo bastion scan checks all of them, including containers and images, and reports which interim mitigations are in place.
Upgrade guide
Per environment. Whatever you upgrade, restart every PHP worker afterwards and check again.
Upgrade every package of your PHP branch, then restart the services that run it.
sudo apt update sudo apt install --only-upgrade 'php8.3*' # use your branch: php8.1, php8.2, php8.4 … dpkg-query -W 'php8.3*' # compare with the table below sudo systemctl restart php8.3-fpm apache2 # whichever you run
Ubuntu 20.04 and older receive the fix through Ubuntu Pro only (sudo pro attach). Debian 11 is outside Debian LTS.
Red Hat published fixes for RHEL 8 (php:7.4, php:8.2), RHEL 9 (php 8.0, php:8.2, php:8.3) and RHEL 10 (php, php8.4). Rebuilds such as AlmaLinux and Rocky follow; their changelogs name the CVEs.
sudo dnf upgrade --refresh 'php*' rpm -q php-cli # compare with the table below rpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]' # rebuilds: no output = not fixed sudo systemctl restart php-fpm httpd
Alpine's security database records the fix only for edge (php83 8.3.36-r0, php84 8.4.27-r0, php85 8.5.12-r0). Stable branches carry no backport: move to a release that ships the fixed upstream version, or use the official php images.
apk update && apk upgrade php83 php83 -v | head -1 # needs 8.3.36 or later
Official php images are built from upstream releases. Rebuild on a fresh base and redeploy; running containers never update themselves.
docker pull php:8.3-fpm # tags now resolve to 8.3.36+ docker build --pull -t myapp . # --pull refreshes FROM php:… sudo bastion scan --image myapp:latest # verify before deploying
Panel-managed PHP lives in /www/server/php/<ver> and is built from upstream sources, so the version number is reliable.
- App Store → Installed → update each PHP version to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, then restart PHP.
- aaPanel's notice covers 8.2–8.5 only. Move sites on PHP 8.1 and older to 8.2 or later and apply the interim mitigations until then.
Both ship their own PHP builds. Update through the panel's package channel.
# cPanel EasyApache 4 (EOL ea-php: confirm the CVE in the changelog) sudo dnf upgrade 'ea-php*' rpm -q --changelog ea-php81-php-cli | grep -E 'CVE-2026-10961[89]' # Plesk: 7.4/8.0/8.1 were rebuilt on 21 Oct 2026 with unchanged versions plesk installer --select-release-current --upgrade-installed-components /opt/plesk/php/8.1/bin/php -v | head -1 # built: Oct 21 2026 or later
Build the fixed release from php.net; Windows binaries are on the same downloads page. For 7.4, 8.0 and 8.1 the PHP team published minimal backport branches.
git clone --depth 1 -b PHP-8.1-CVE-2026-109618-109619 https://github.com/php/php-src # also: PHP-8.0-CVE-2026-109618-109619, PHP-7.4-CVE-2026-109618-109619
Builds from these branches keep their old version string. Record that you built them; no tool can tell from outside.
| Release | Package | Fixed in | Advisory |
|---|---|---|---|
| ubuntu 26.10 | php8.5 | 8.5.9-0ubuntu2.1 | USN-8948-1 |
| ubuntu 26.04 | php8.5 | 8.5.4-0ubuntu1.5 | USN-8948-1 |
| ubuntu 24.04 | php8.3 | 8.3.6-0ubuntu0.24.04.13 | USN-8948-1 |
| ubuntu 22.04 | php8.1 | 8.1.2-1ubuntu2.28 | USN-8948-1 |
| ubuntu 20.04 | php7.4 Ubuntu Pro (ESM) | 7.4.3-4ubuntu2.29+esm5 | USN-8948-2 |
| ubuntu 18.04 | php7.2 Ubuntu Pro (ESM) | 7.2.24-0ubuntu0.18.04.17+esm14 | USN-8948-2 |
| ubuntu 16.04 | php7.0 Ubuntu Pro Legacy | 7.0.33-0ubuntu0.16.04.16+esm22 | USN-8948-2 |
| ubuntu 14.04 | php5 Ubuntu Pro Legacy | 5.5.9+dfsg-1ubuntu4.29+esm18 | USN-8948-2 |
| debian 13 | php8.4 | 8.4.27-1~deb13u1 | DSA-6574-1 |
| debian 12 | php8.2 | 8.2.35-1~deb12u1 | DLA-4848-1 |
| RHEL 10 | php | 8.3.36-1.el10_2 | RHSA-2026:87070 |
| RHEL 10 | php8.4 | 8.4.27-1.el10_2 | RHSA-2026:87071 |
| RHEL 9 | php | 8.0.30-8.el9_8.1 | RHSA-2026:87151 |
| RHEL 9 | php php:8.2 module | 8.2.35-1.module+el9.8.0+25111+a1450321 | RHSA-2026:87072 |
| RHEL 9 | php php:8.3 module | 8.3.36-1.module+el9.8.0+25109+6886e21a | RHSA-2026:87079 |
| RHEL 8 | php php:7.4 module | 7.4.33-8.module+el8.10.0+25117+30337cca | RHSA-2026:87080 |
| RHEL 8 | php php:8.2 module | 8.2.35-1.module+el8.10.0+25110+f67151d2 | RHSA-2026:87073 |
- Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor's patched package). This is the only complete fix.
- Restart every PHP worker after updating (php-fpm, Apache, LiteSpeed). Updated files on disk do nothing for workers that are still running the old code.
- If you cannot update yet: set session.upload_progress.enabled=0 in php.ini or the FPM pool (not via ini_set or .user.ini) and restart workers.
- On PHP 8.5 that cannot be updated, set fatal_error_backtraces=0 and restart workers.
- Reduce exposure: enforce memory_limit=-1 administratively (php_admin_value), keep post_max_size low (8M without uploads, 32M with), and cap request size, part count and header count at the web server or proxy. These narrow known paths but do not make an installation safe.
- Do not use RLIMIT_AS / RLIMIT_DATA as a memory boundary; they can cause the vulnerable allocation failure. Use cgroup/container limits instead.
From the official PHP advisory. These reduce exposure to known paths; they do not make an installation safe.