PHP Will Ship Emergency Fixes for Two Critical Vulnerabilities Tonight

Update (Oct 22, 11:52 PM PHT): AlmaLinux, the last major holdout, has published fixed PHP packages for CVE-2026-109618 and CVE-2026-109619. AlmaLinux 10 gets php 8.3.36 (ALSA-2026:87070) and php8.4 8.4.27 (ALSA-2026:87071). AlmaLinux 9 gets fixed php:8.2 and php:8.3 module streams (ALSA-2026:87072, ALSA-2026:87079). AlmaLinux 8 gets a fixed php:7.4 stream (ALSA-2026:87080); its php:8.2 stream has no advisory yet. On Fedora, 44 is fixed, while the Fedora 43 and 45 updates are still in testing. The bugs are still not in CISA's Known Exploited Vulnerabilities catalog, even though attacks in the wild have been reported since Oct 21. If you run PHP on AlmaLinux, run dnf upgrade php* and restart PHP-FPM.

Update (Oct 22, 8:22 PM PHT): Rocky Linux 8 now has a fixed php:8.2 module stream: RLSA-2026:87073 ships php 8.2.35 and fixes CVE-2026-109618 and CVE-2026-109619. Rocky 8 users on the php:8.2 stream should update now with dnf upgrade php\* and restart PHP-FPM or the web server. Rocky 8 php:7.4 and the Rocky 9 and 10 fixes shipped earlier today. AlmaLinux still has no PHP errata, and the Fedora 43 and 45 updates are still in testing. CISA has not added the CVEs to its Known Exploited Vulnerabilities catalog yet.

Update (Oct 22, 9:45 AM PHT): TuxCare says all of its fixed PHP packages are now released. That covers its Extended Lifecycle Support builds of older PHP versions (alt-php 5.2 to 8.5), the distributions' own PHP packages on ELS systems such as CentOS 6, 7 and 8, RHEL 7, Oracle Linux 6 and 7, Debian 10 and 11, and Ubuntu 16.04 and 18.04, plus PHP for Windows. On CentOS 7 ELS, for example, the fix is php 5.4.16-48.el7.tuxcare.els21 (CLSA-2026:1792615126). CloudLinux has also moved fixed alt-php 5.2 to 8.5 into its regular stable repositories for CloudLinux OS 7, 8 and 9, so the separate ELS repository step is no longer needed (CloudLinux status page, TuxCare CVE tracker). Security advisory metadata isn't published yet, so security-only updates such as yum --security won't list these packages. Run a regular update and restart PHP-FPM or the web server. AlmaLinux is still the main distribution without fixed PHP packages.

Update (Oct 22, 8:15 AM PHT): Rocky Linux has published fixed PHP packages for Rocky Linux 8, 9 and 10 that cover both CVE-2026-109618 and CVE-2026-109619. The advisories are RLSA-2026:87070 (php) and RLSA-2026:87071 (php8.4) for Rocky Linux 10, RLSA-2026:87079 (php:8.3), RLSA-2026:87072 (php:8.2) and RLSA-2026:87151 (php) for Rocky Linux 9, and RLSA-2026:87080 (php:7.4) for Rocky Linux 8. Run dnf upgrade, then restart PHP-FPM and the web server. Backported packages keep their old version numbers, so check the package changelog for the two CVE IDs (Rocky Linux errata). AlmaLinux hasn't published PHP errata yet, and the Fedora 43 and 45 updates are still pending.

Update (Oct 22, 6:50 AM PHT): CloudLinux says fixed alt-php packages for CloudLinux OS 7, 8 and 9 are now available, but only from the separate ELS ALT PHP repository, not the regular CloudLinux repositories. Servers must be registered with CLN, install the els-php-release package, then update alt-php and restart Apache, PHP-FPM or LiteSpeed. CloudLinux OS 10 already uses that repository and only needs a regular update. CloudLinux recommends checking each package's changelog for both CVE IDs to confirm the fix (CloudLinux status page).

Update (Oct 22, 6:25 AM PHT): CloudLinux has corrected its earlier package status. The fixed alt-php packages it announced at 19:00 UTC went to the TuxCare ELS alt-php repository, not the CloudLinux repositories, so CloudLinux 7, 8 and 9 servers did not have them yet at that point. CloudLinux 10 installs alt-php from the TuxCare ELS repository, and fixed alt-php 7.4 is confirmed there. Fixed ea-php packages for cPanel EasyApache 4 (ea-php52 through ea-php85) are released, and Imunify360 rulesets 8.84 and 8.85 add blocking rules, including on LiteSpeed (CloudLinux status page, CloudLinux blog).

Update (Oct 22, 3:50 AM PHT): TuxCare has started shipping fixes for PHP versions that php.net no longer supports. Its ELS for Runtimes post, updated at 19:42 UTC on October 21, says PHP 7.4 builds are already out on nearly every supported Linux platform, and the other end-of-life branches are still rolling out, with timing varying by branch and platform. The builds install through the usual yum, dnf or apt update and sit alongside other PHP versions under /opt/alt/, so restart every PHP worker after updating (TuxCare).

Update (Oct 22, 1:00 AM PHT): Fedora has started shipping. Fedora 44's php-8.5.12-1.fc44 update, which fixes both CVEs, went to stable at 12:43 AM PHT, so Fedora 44 users can update with dnf upgrade now (FEDORA-2026-a9eba4bbc3). The Fedora 43 and 45 updates are still pending. CloudLinux and TuxCare have also released fixed PHP for CentOS 8.4 ELS (php 7.4.6) and Ubuntu 16.04 and 18.04 ELS (php 7.0.33 and 7.2.24) (CloudLinux status page). Neither CVE is in CISA's Known Exploited Vulnerabilities catalog so far.

Update (Oct 22, 12:25 AM PHT): A new public exploit repository, 3em0/php2shell, claims remote, HTTP-only code execution against PHP 8.4.26 running under Apache prefork with mod_php, with ASLR bypassed and no file written to the target. The code is public but hasn't been independently tested. Canonical has extended its fix to older Ubuntu releases through Ubuntu Pro ESM: php5 on 14.04, php7.0 on 16.04, php7.2 on 18.04 and php7.4 on 20.04 (USN-8948-2). The PHP project has published GitHub advisories for both bugs (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Update (Oct 21, 11:25 PM PHT): Both vulnerabilities are now being exploited in the wild. watchTowr's FAQ lists CVE-2026-109618 and CVE-2026-109619 as exploited, based on activity its honeypot network saw on October 21 (watchTowr). Cloudflare says it saw attack traffic against its customers after the details leaked, and that attackers kept changing their payloads to get past its rules. Its managed WAF rules have protected Free and paid plans by default since 3:02 AM UTC on October 21 (Cloudflare). Precursor Security reports exploit attempts that use multipart/form-data requests with boundary values such as B7kQpoc618 and B7kQpoc619. Those are worth searching for in web server and WAF logs (Precursor Security). The CVEs aren't in CISA's Known Exploited Vulnerabilities catalog yet.

Patched packages keep arriving. Fedora has submitted php 8.5.12 updates for Fedora 44, 45 and 46 and php 8.4.27 for Fedora 43. They're headed to updates-testing and aren't installable yet (Fedora Bodhi). CloudLinux expects patched alt-php builds for PHP 5.2 through 8.5 within about five hours. It says cPanel's ea-php74 to ea-php85 are scheduled for EasyApache4 v25.91 and TuxCare ELS PHP packages are in testing (CloudLinux status). Rocky Linux and AlmaLinux haven't published PHP errata yet.

If you run PHP on a public web server, patch tonight. If you can't, turn off session.upload_progress, apply PHP's memory_limit and post_max_size guidance, and put the site behind a WAF until you can.

Update (Oct 21, 11:10 PM PHT): TuxCare PHP ELS for Plesk

Plesk's stock PHP 8.2 through 8.5 handlers are patched, but 7.4, 8.0 and 8.1 are still waiting on Plesk builds (Plesk KB). For EOL PHP that Plesk no longer patches on its own, the path is TuxCare Extended Lifecycle Support for PHP, installed through the Plesk extension (versions 5.6, 7.0 to 7.4, 8.0 and 8.1). As of CloudLinux's status update at 14:55 UTC, patched TuxCare ELS PHP packages are in testing and have not been released yet. Until they land, sites stuck on those handlers still need the interim mitigations (isolate the app or set session.upload_progress.enabled = Off).

Update (Oct 21, 10:55 PM PHT): Ubuntu and Plesk have now shipped fixes, and NVD has published both CVEs.

• Ubuntu: USN-8948-1 fixes CVE-2026-109618 and CVE-2026-109619 in php8.1 8.1.2-1ubuntu2.28 (Ubuntu 22.04 LTS) and php8.3 8.3.6-0ubuntu0.24.04.13 (Ubuntu 24.04 LTS), plus the php8.5 packages in Ubuntu's newer releases. Run sudo apt update && sudo apt upgrade, then restart PHP-FPM or Apache.
• Plesk: the Plesk Obsidian change log lists a PHP update dated October 21 that moves Plesk's PHP 8.5, 8.4, 8.3 and 8.2 handlers to 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older handlers and the operating system's own PHP are not covered by this update.
• CloudLinux: per its status page, alt-php and ea-php builds are in progress, with fixes targeted by 19:00 UTC (3 AM PHT, Oct 22). alt-php74 is already out for EL6 and EL10.
• NVD: CVE-2026-109618 and CVE-2026-109619 are now listed (awaiting NVD analysis).
• Still waiting: Fedora, Rocky Linux, AlmaLinux and TuxCare ELS for PHP have not published fixed packages yet.
• There are still no public reports of exploitation in the wild, and the CVEs are not in CISA's Known Exploited Vulnerabilities catalog. GitHub is filling up with repositories claiming to be exploits for these bugs. None has been independently verified, and some fake PoCs run code on the machine of whoever runs them, so don't run them.

Update (Oct 21, 7:15 PM PHT): A new third-party research repository, 9bie/php2shell-bypass-aslr-exp (created around 11:11 UTC on October 21), claims a standalone, pure-HTTP remote code execution path against a stock session_start() page with no application include or require file-inclusion sink, via the session.upload_progress multipart handler on PHP 8.4.26 with Apache prefork and mod_php. The writeup reports a two-request chain with ASLR off and a full chain with ASLR on (heap leak through Set-Cookie, libphp base leak, then zif_system), with lab success rates and accompanying tool scripts. This is independent research, not an official PHP Project confirmation. CVE-2026-109618 and CVE-2026-109619 remain unpublished on NVD and CVE.org, and php.net still shows only the October 20 advance notice with fixed builds due at 14:00 UTC (10:00 PM PHT). Treat trojanized or incomplete proof-of-concept code as common; do not run unverified exploit code against systems you do not own.

Sources: 9bie/php2shell-bypass-aslr-exp; php.net; NVD and CVE.org (no records yet for those IDs).

Update (Oct 21, 4:55 PM PHT): In Security Advisory 2026-018, CERT-EU advises organisations to prepare for immediate patching and, "where immediate patching is not feasible," to "consider isolating internet-facing applications from public networks until a fix is available."

Update (Oct 21, 11:40 AM PHT): Ahead of PHP's scheduled fixes (14:00 UTC / 10 PM PHT today), several public GitHub repositories appeared this morning with proof-of-concept and trigger code tagged to CVE-2026-109618 and CVE-2026-109619, along with detailed source-level writeups. The repositories do not agree on what the underlying bug is. One describes a use-after-free in PHP's session upload-progress handling, but calls it only "conceptually validated" against the PHP 8.4 source and says a full memory-corruption or code-execution reproduction is still incomplete. Another explicitly disputes the use-after-free theory and instead demonstrates a cookie-less session-fixation and session-poisoning chain on a stock PHP 8.4.4 Docker image, which reaches code execution only when the target application also has a separate file-inclusion flaw (an include() or require() that loads an attacker-controlled path). So far, no one has publicly shown a standalone, unauthenticated remote code execution from these flaws alone.

As of this update, PHP has not yet published patched versions (the latest releases are still from September 24), neither CVE ID is listed on NVD or CVE.org, and there are no confirmed reports of exploitation in the wild. Treat the circulating proof-of-concept code as unverified community research until PHP publishes its official fixes and advisory tonight. One defensive step from the public writeups: setting session.upload_progress.enabled = 0, or at least keeping session.upload_progress.cleanup = On (the default), weakens the session-poisoning technique.

Sources: GitHub repositories Zer061/CVE-2026-109618 and 19h/CVE-2026-109618; PHP releases; NVD.