PHP 8.3 branch, security release
PHP 8.3.36: a security-only release for PHP2Shell
PHP 8.3.36 fixes PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on the PHP 8.3 branch and changes nothing else. It came out on 21 October 2026. Ubuntu 24.04 and some Red Hat channels deliver the same fix under an older 8.3 number, so on those servers judge the package build, not the headline version.
Last reviewed against php.net, Ubuntu, Red Hat and its rebuilds and the official Docker image.
About 8.3.36
One fix, nothing else
PHP 8.3 passed out of active support at the end of 2025. Under php.net's policy a branch in that stage only gets releases for critical security issues, made as needed, which is exactly what 8.3.36 is.
| Release date | 21 October 2026 |
|---|---|
| What it fixes | CVE-2026-109618 and CVE-2026-109619 (PHP2Shell), through one Core change |
| Anything else? | No. The ChangeLog entry has that single line and nothing more |
| Earlier 8.3 release | 8.3.35, from 24 September 2026 |
| Windows build | 8.3.36-1, Visual Studio 2019 (VS16), rebuilt 26 October 2026 |
| 8.3 support stage | Security fixes only since 31 December 2025; security support ends 31 December 2027 |
The ChangeLog line, and its date
The whole 8.3.36 entry reads: Core, fixed GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, "Avoid state corruption via bailout". With no other change listed, moving up from 8.3.35 adds nothing else to test against.
That entry is dated 22 October 2026. The php.net announcement, the source downloads and the advisories all carry 21 October, when the coordinated release went out, and that is the date used here.
Why 8.3 matters for PHP2Shell
PHP 8.3 is the default PHP in two long-term server releases: Ubuntu 24.04 LTS's php metapackage installs it, and it is the standard php package on RHEL 10. Both CVEs affect every 8.3 release before 8.3.36, and the PHP project's confirmed attack routes include session upload progress, which is switched on by default.
Read the PHP2Shell advisoryPackage status on 27 October 2026
Getting the 8.3.36 fix from your vendor
Several vendors added this fix to older 8.3 builds, so read the version column with care. Rows marked backport are patched despite a number below 8.3.36.
| Source | Package, stream or tag | Patched version | Reference |
|---|---|---|---|
| php.net source | php-8.3.36 tarballs (gz, bz2, xz) with signatures | 8.3.36 | php.net downloads, 21 Oct 2026 |
| php.net Windows | VS16 x64 and x86 zips, Thread Safe and Non Thread Safe | 8.3.36-1 | PHP 8.3 Windows builds, 26 Oct 2026 |
| Official Docker image | 8.3.36 plus -fpm, -apache, -cli or -zts, on trixie, bookworm, alpine3.24 and alpine3.23 (apache only on Debian); the 8.3 tags are aliases | 8.3.36 | Docker Hub php |
| Ubuntu 24.04 LTS | php8.3 (php8.3-fpm, php8.3-cli, libapache2-mod-php8.3 and the rest) | 8.3.6-0ubuntu0.24.04.13 (backport) | USN-8948-1, 21 Oct 2026 |
| RHEL 10 | php, the default PHP 8.3 packages | 8.3.36-1.el10_2 | RHSA-2026:87070, 21 Oct 2026 |
| RHEL 9 | php:8.3 module stream | 8.3.36-1.module+el9.8.0+25109+6886e21a | RHSA-2026:87079, 21 Oct 2026 |
| RHEL 10.0 EUS | php on the 10.0 Extended Update Support channel | 8.3.19-1.el10_0.2 (backport) | RHSA-2026:88561, 23 Oct 2026 |
| RHEL 9.6 EUS | php:8.3 stream on the 9.6 Extended Update Support channel | 8.3.19-1.module+el9.6.0+25160+f8b750a4.3 (backport) | RHSA-2026:89111, 26 Oct 2026 |
| AlmaLinux 9 and 10 | php:8.3 stream on 9, default php on 10 | 8.3.36-1.module_el9.8.0+330+fdc30075 (9), 8.3.36-1.el10_2 (10) | ALSA-2026:87079 and 87070, 22 Oct 2026 |
| Rocky Linux 9 and 10 | php:8.3 stream on 9, default php on 10 | 8.3.36-1.module+el9.8.0+40396+4e680bb7 (9), 8.3.36-1.el10_2 (10) | RLSA-2026:87079 and 87070, 22 Oct 2026 |
| Amazon Linux 2023 | php8.3, in repository version 2023.12.20261021 | 8.3.36-1.amzn2023.0.1 | ALAS2023-2026-3302, 22 Oct 2026 |
| packages.sury.org | php8.3-* for Debian 12 and 13 and Ubuntu 22.04 to 26.04 | 8.3.36-1+0~20261021.88 with a release suffix | packages.sury.org/php |
| Ondřej Surý PPA | php8.3-* for Ubuntu 22.04 and 24.04 | 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 (24.04) | ppa:ondrej/php |
| Remi's repository | php:remi-8.3 stream or the php83 collection | 8.3.36-1 | Remi, 22 Oct 2026 |
| cPanel EasyApache 4 | ea-php83, from 8.3.35 in release 25.91 | 8.3.36 | cPanel EA4 change log, 21 Oct 2026 |
| Plesk | PHP 8.3 component | 8.3.36; 8.3.36-1 on Windows from 27 Oct | Plesk change log |
| LiteSpeed repository | lsphp83 | 8.3.36-1 | rpms.litespeedtech.com |
Reading the backported numbers
Some distributions add a security fix to the version a release was built around rather than moving to the new upstream release. Ubuntu kept 24.04 on 8.3.6; Red Hat kept its 10.0 and 9.6 Extended Update Support channels on 8.3.19. Ubuntu's own documentation warns that tools comparing upstream version numbers report such packages as vulnerable when they are not.
AlmaLinux's day-one builds
AlmaLinux backported the fix itself on 21 October, ahead of a
Red Hat build it could rebuild. Those packages kept 8.3.33 with
an .alma.1 suffix, for example
php-8.3.33-1.el10_2.alma.1. The
8.3.36 rebuilds in the table followed on 22 October and replace
them on the next update.
Debian has no row: Debian 12 and 13 use PHP 8.2 and 8.4, and its tracker lists no php8.3 package for these CVEs. For Debian 12 and 13, packages.sury.org carries 8.3.36.
Which applies to you
Updating PHP 8.3, platform by platform
Find the platform your 8.3 install came from. The guide behind each card has the full commands and the restart step.
Ubuntu 24.04 LTS
PHP 8.3 is noble's default, and the fixed packages read 8.3.6-0ubuntu0.24.04.13. That is the build to look for: Ubuntu never moved 24.04 to 8.3.36. An ordinary apt upgrade from the security pocket brings it in; restart php8.3-fpm afterwards.
Ubuntu 24.04 update steps
RHEL 9 and 10, AlmaLinux, Rocky Linux
PHP 8.3 is RHEL 10's standard php and a module stream on RHEL 9. Main channels got 8.3.36 builds; the 10.0 and 9.6 Extended Update Support channels got 8.3.19 builds with the fix added. Both are patched.
RHEL, AlmaLinux and Rocky steps
cPanel and Plesk
EasyApache 4's ea-php83 package and Plesk's PHP 8.3 both reached 8.3.36 on release day. If MultiPHP Manager or the Plesk PHP page shows a domain on 8.3, it is the host's package update that patches it, not a setting the site owner changes.
PHP updates in Plesk
Images on php:8.3
Tags such as 8.3-fpm and 8.3-apache now resolve to 8.3.36. Builds that pin an older patch tag or a digest stay where they are until you change them. Pull, rebuild without stale layers and redeploy.
Rebuilding php:8.3 imagesAlso on 8.3: cPanel and WHM, Debian with packages.sury.org, Amazon Linux 2023 and Windows Server with IIS, where the file to fetch is the 8.3.36-1 VS16 Non Thread Safe zip.
Confirming the fix
Is this server on a patched 8.3 build?
Pick the check that matches where PHP came from. The answer is a package build on a distribution and a plain version number everywhere else.
# Ubuntu 24.04: patched means 8.3.6-0ubuntu0.24.04.13 or higher
dpkg-query -W php8.3-fpm php8.3-cli libapache2-mod-php8.3
# RHEL, AlmaLinux or Rocky: installed build, then the matching advisory
rpm -q php-common
dnf updateinfo list --cve CVE-2026-109618 --installed
# Upstream builds (php.net, Docker, Remi, Ondřej Surý): want 8.3.36
php -r 'echo PHP_VERSION, PHP_EOL;' Once the build is right, restart the PHP-FPM service (php8.3-fpm on Ubuntu, php-fpm on the RHEL family) or Apache, then read the version the web server reports using one of the version check methods. Platform-by-platform steps are in the PHP update guides.
Next for PHP 8.3: plan the move during 2027
php.net supports 8.3 for security until 31 December 2027, so there is no need to change branch in a hurry. Use the time to test on PHP 8.4 or PHP 8.5, starting from the upgrade guides. If your distribution supplies PHP, its own life cycle can run longer than php.net's; the end of life page sets out php.net's dates. Still on PHP 8.2? Its fix is 8.2.35.
If an 8.3 server has to wait
Switch off session upload progress in php.ini or the FPM pool and restart PHP. The PHP project lists further limits on request size and multipart input, all partial; they are collected under interim settings. A server that can neither be patched nor mitigated soon is the case covered by should I take my website offline?
Quick answers
PHP 8.3.36, answered
Is PHP 8.3.36 safe?
For PHP2Shell, yes: 8.3.36 is the version both GitHub advisories name as patched on the 8.3 branch. php.net still suggests session.upload_progress.enabled=0 until its next regular bugfix release, because of a separate, unlikely session issue (CVE-2026-115560) described on 23 October. And patching cannot remove a backdoor planted while the server was exposed.
Does Ubuntu 24.04 have PHP 8.3.36?
Ubuntu 24.04 does not ship the 8.3.36 release; it ships PHP 8.3.6 with the PHP2Shell fix applied. USN-8948-1 lists 8.3.6-0ubuntu0.24.04.13 as the fixed build. A server on that build or later is patched even though its number is far below 8.3.36. The upstream 8.3.36 is available for 24.04 from the Ondřej Surý PPA if you specifically need it.
What changed in 8.3.36?
Only the security fix. The 8.3.36 ChangeLog entry is a single Core line, "Avoid state corruption via bailout", tagged with the two GitHub advisory identifiers. PHP 8.3 has been in its security-only stage since the end of 2025, so ordinary bug fixes no longer reach this branch.
Why does my patched RHEL or AlmaLinux server show PHP 8.3.19 or 8.3.33?
Both can be fixed builds. Red Hat patched its Extended Update Support channels at their existing versions: 8.3.19-1.el10_0.2 for RHEL 10.0 (RHSA-2026:88561) and an 8.3.19 php:8.3 build for RHEL 9.6 (RHSA-2026:89111). AlmaLinux's own day-one builds kept 8.3.33 with a .alma.1 suffix before its 8.3.36 rebuilds of Red Hat's packages arrived on 22 October. Check the advisory for your channel rather than the number.
When does PHP 8.3 stop getting security fixes?
php.net ends security support for 8.3 on 31 December 2027. Vendors set their own dates: Red Hat's Application Streams life cycle shows a May 2029 retirement for the php:8.3 stream on RHEL 9, and lists PHP 8.3 on RHEL 10 as a full life cycle stream.
Know your exposure
Find every PHP server you run
Patching the server you know about is the easy part. A vulnerability scan finds the forgotten staging site, the old microsite and the appliance with PHP inside, then tells you which ones are still exposed.