There is no official PHP 8.1, 8.0 or 7.4 release that fixes CVE-2026-109618, because those branches are end of life and the PHP project no longer ships updates for them.
As our PHP security update guide explains, your three options are a backported package from your Linux distribution or LTS vendor, the minimal source backports from the PHP security team, or an upgrade to PHP 8.2 or newer.
Fastest fix for CVE-2026-109618 on PHP 7.4, 8.0 or 8.1
The quickest safe route depends on who supplies your PHP binaries. Most servers get PHP from the operating system, so the vendor package is the first place to look.
- Run
php -von the server to confirm the branch you run (7.4, 8.0 or 8.1). - Check your Linux distribution's or LTS vendor's security notice for a CVE-2026-109618 fix for that PHP package.
- If a fixed package exists, install it with your package manager and restart every PHP worker.
- If no vendor package exists and you build PHP yourself, apply the PHP security team's source backport for your branch and rebuild.
- If neither route works, upgrade the site to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
Mitigation settings reduce exposure while you work through these steps, but php.net is clear that only an update is a complete solution.
Are PHP 8.1, 8.0 and 7.4 affected?
The php.net advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team built source backports for 7.4, 8.0 and 8.1, which only makes sense because those branches carry the flaw too.
The PHP critical RCE security update shipped for supported branches only, on 21 October 2026.
| Vulnerability | ID | What goes wrong |
|---|---|---|
| RCE via OOM corruption | CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) | Out-of-memory handling can interrupt PHP while request data is only partly initialized, and request cleanup then treats the invalid data as valid. |
| RCE via stale global state | CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) | Request-owned state can survive after its memory is freed, and a later request on the same worker may use it. |
php.net rates the risk highest for mod_php, where a demonstrated exploit triggers the attack from an unauthenticated request before any application code runs. Both flaws were announced as CVSS v4.0 9.2.
PHP 7.4, 8.0 and 8.1 fix options compared
| Your situation | Best option | Why |
|---|---|---|
| PHP comes from Ubuntu, Debian, RHEL or another distro package | Vendor backported package | The vendor received the patches in advance and keeps your current version number |
| You pay for an LTS or extended-support PHP service | LTS vendor update | php.net names LTS vendors as a source of backported fixes |
| You compile PHP from source | PHP security team source backport | Provided for 7.4, 8.0 and 8.1 for people building from source |
| You use rpms.remirepo.net | Switch to distro packages or build from source | php.net says the repo will not have updates on release day |
| Shared hosting with a PHP version picker | Select PHP 8.4 or 8.5 | You cannot patch the host's binaries yourself |
| Your code already runs on PHP 8.2 or newer | Upgrade now | Supported branches get the full fix and future fixes |
Get a fix from your Linux distribution or LTS vendor
php.net states that Linux distributions and LTS vendors received the patches in advance, and that some provide backported fixes for PHP 8.1 and older. A backported package keeps the old version number, so check the PHP version and package rather than judging it by php -v alone.
Package version numbers differ per release, so take the fixed version from the vendor's security notice.
- Open your vendor's security notice or tracker and search for CVE-2026-109618.
- Note the fixed package version listed for your release and PHP branch.
- On Debian or Ubuntu, run
sudo apt updateand thensudo apt upgrade. - On RHEL, Fedora, AlmaLinux or Rocky Linux, run
sudo dnf upgrade. - Compare the installed PHP package version with the fixed version from the notice.
- Restart PHP-FPM, Apache or your PHP server so every worker loads the patched code.
If you would rather move off the old branch entirely, you can update PHP to 8.4.27 or 8.5.12 from the same package manager or the official builds.
PHP security team source backports for 7.4, 8.0 and 8.1
Given the severity, the PHP security team provided minimal source backports for PHP 7.4, 8.0 and 8.1. They are aimed at people who build from source or have no LTS vendor. They are minimal by design: they address these vulnerabilities, not the other fixes those branches missed after end of life.
- Read the 21 October 2026 security advisory on the php.net news page, which announces the backports, and obtain the one for your branch.
- Check out the source tree of the exact PHP version you run, such as 7.4.33, 8.0.30 or 8.1.34.
- Apply the backport patch to that tree.
- Rebuild PHP with the same configure options you used before.
- Install the rebuilt binaries and restart every PHP worker.
- Test the site, then schedule the move to a supported branch.
Upgrade from PHP 7.4 or 8.1 to a supported version
An upgrade removes the dependency on backports for this and every later flaw. php.net publishes a migration guide for each step, so move one branch at a time and read each guide's backward-incompatible changes.
PHP 8.2 reaches end of life on 31 December 2026, so aim for PHP 8.4 or 8.5 if your code allows it.
| Current branch | Migration guides to read on php.net | Fixed release to install |
|---|---|---|
| PHP 7.4 | 7.4 to 8.0, 8.0 to 8.1, 8.1 to 8.2, then onward | 8.2.35 at minimum; 8.4.27 or 8.5.12 preferred |
| PHP 8.0 | 8.0 to 8.1, 8.1 to 8.2, then onward | 8.2.35 at minimum; 8.4.27 or 8.5.12 preferred |
| PHP 8.1 | 8.1 to 8.2, then onward | 8.2.35 at minimum; 8.4.27 or 8.5.12 preferred |
Windows builds of the fixed releases are on windows.php.net; the PHP 8.4.27 download for Windows and PHP 8.5.12 download list what changed.
PHP supported versions and end-of-life dates
| Branch | Security support ends | Last or fixed release | Status on 21 Oct 2026 |
|---|---|---|---|
| 7.4 | 28 Nov 2022 | 7.4.33 | End of life |
| 8.0 | 26 Nov 2023 | 8.0.30 | End of life |
| 8.1 | 31 Dec 2025 | 8.1.34 | End of life |
| 8.2 | 31 Dec 2026 | 8.2.35 | Security fixes only |
| 8.3 | 31 Dec 2027 | 8.3.36 | Security fixes only |
| 8.4 | 31 Dec 2028 | 8.4.27 | Active support until 31 Dec 2026 |
| 8.5 | 31 Dec 2029 | 8.5.12 | Active support until 31 Dec 2027 |
php.net supports each branch for two years of active support plus two years of critical security fixes, then ends it.
Mitigations while you plan the upgrade
php.net lists measures that reduce exposure to specific attack paths but do not make an installation safe. Apply them in php.ini, the FPM pool or server configuration, then restart every PHP worker.
| Flaw | Mitigation from the advisory | Limit |
|---|---|---|
| CVE-2026-109618 | Set memory_limit=-1 with php_admin_value so applications cannot override it |
An underlying allocation failure can still reach the bug |
| CVE-2026-109618 | Set post_max_size = 8M (or 32M if uploads are needed) and keep upload_max_filesize below it |
Also enforce request limits at the web server or proxy |
| CVE-2026-109618 | Use a container or cgroup memory limit | Do not use RLIMIT_AS or RLIMIT_DATA instead |
| CVE-2026-109619 | Set session.upload_progress.enabled=0 |
Blocks the confirmed session paths only; not via ini_set() or .user.ini |
| CVE-2026-109619 | Remove invalid or deprecated per-request settings and fix attacker-reachable fatal errors | Hiding errors with display_errors or @ does not help |
The fatal_error_backtraces=0 mitigation applies to PHP 8.5 only. Each setting is explained step by step in the PHP CVE-2026-109618 mitigations guide.
How to check PHP 7.4 or 8.1 is patched for CVE-2026-109618
- For a vendor package, compare the installed package version with the fixed version in the vendor's notice;
php -vstill shows 7.4.33, 8.0.30 or 8.1.34. - For an upgrade, run
php -vand confirm 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. - Load a
phpinfo()page through the web server to confirm the web SAPI, not only the CLI, runs the patched build. - Delete the
phpinfo()page as soon as you have checked it.
PHP end-of-life CVE-2026-109618 fix problems
No update appears for PHP 7.4 or 8.1 from remirepo
php.net says rpms.remirepo.net will not have updates on release day.
- Switch to your distribution's PHP packages, or build from source with the backport.
- Restart every PHP worker after the change.
The vendor notice shows no fix for your PHP 8.0 package
Not every vendor still covers every end-of-life branch.
- Contact the vendor, as php.net recommends, to ask about a backport.
- If none is planned, upgrade to a supported branch and apply the mitigations meanwhile.
The site still runs the old build after updating
Running PHP-FPM or Apache workers keep the old code in memory.
- Restart PHP-FPM or Apache, or the container running PHP.
- Repeat the
phpinfo()check through the web server.
PHP 7.4, 8.0 and 8.1 CVE-2026-109618 FAQ
Is there a PHP 7.4.34 or 8.1.35 release for CVE-2026-109618?
No. The PHP project no longer releases updates for PHP 8.1 and older. The fix for those branches comes as vendor backports or the PHP security team's minimal source backports, and the version number stays at 7.4.33 or 8.1.34.
Is PHP 7.4 still safe to use?
No. PHP 7.4 reached end of life on 28 November 2022 and php.net warns that unsupported releases may expose you to unpatched security vulnerabilities. Even with a backport for this flaw, other fixes are missing.
What is PHP 8.1's end-of-life date?
PHP 8.1 reached end of life on 31 December 2025, and its last official release is 8.1.34. It receives no further fixes from the PHP project.
Which PHP version should I upgrade to from 7.4?
Upgrade to PHP 8.4.27 or 8.5.12 if your code supports it. PHP 8.2.35 also fixes the flaw, but the 8.2 branch reaches end of life on 31 December 2026.
Do the mitigations make PHP 7.4 safe?
No. php.net says the measures reduce exposure to specific attack paths but do not make an installation safe. Only an update or a backported fix removes the vulnerabilities.
Is PHP 8.2 affected by CVE-2026-109618?
Yes, and PHP 8.2.35 fixes it. It is the oldest branch with an official fixed release from the PHP project.
Does CVE-2026-109618 affect PHP on Windows?
The advisory covers all PHP installations serving web requests, whatever the operating system. Windows binaries of the fixed releases are published by the PHP project; older 7.4, 8.0 and 8.1 Windows builds get no official fix.
Bottom line: should you patch or upgrade PHP 7.4, 8.0 and 8.1?
Install a vendor backport or the PHP security team's source patch today, then upgrade to PHP 8.4 or 8.5. The backports close CVE-2026-109618 and CVE-2026-109619 on an end-of-life branch, but only a supported branch keeps getting fixes for the next flaw.
