Critical PHP Flaws Fixed: Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 Now

Updated 21 October 2026: the fixes are out. This post now covers the fixed versions and PHP’s interim mitigations.

PHP has released fixes for two critical vulnerabilities, both rated CVSS v4.0 9.2, that can allow unauthenticated remote code execution. Update now.

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The vulnerabilities

• CVE-2026-109618 (RCE via out-of-memory corruption): out-of-memory handling can interrupt PHP while internal request data is only partly set up. Request clean-up can then treat that invalid data as valid.
• CVE-2026-109619 (RCE via stale global state): internal state belonging to one request can survive after its memory has been freed. A later request handled by the same worker can use that stale state before it is reset.

Who is at risk

Every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The risk is highest for mod_php. PHP says an exploit has been demonstrated where a single unauthenticated request triggers the attack before any application code runs. Your application’s own security makes no difference.

PHP has not said whether either flaw is being exploited in the wild.

How to update

• Supported branches: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source and Windows builds are on the PHP downloads page.
• Linux distributions: distributions and LTS vendors received the patches in advance. Install your vendor’s updated packages. Debian, Ubuntu and RHEL often backport fixes without changing the version number, so check the package changelog for the CVE IDs.
• Remi repository users: if you use rpms.remirepo.net (common on RHEL, Alma and Rocky), PHP says it will not have updates today. Switch to distribution packages or build from source.
• PHP 8.1 and older: no longer updated by the PHP project. Some vendors offer backported fixes. The PHP security team has published minimal source backports for 7.4, 8.0 and 8.1 if you build from source. The real fix is moving to a supported version.
• Restart afterwards: restart PHP-FPM or the web server so the patched binary is actually loaded.

PHP 8.2 reaches end of life on 31 December 2026. If you are on 8.2, patch today and plan your upgrade.

WordPress, Moodle and other PHP platforms

This is a flaw in the PHP runtime, not in an application. That matters for anything built on PHP: WordPress, Drupal, Joomla, Magento/Adobe Commerce, Moodle, Nextcloud, phpMyAdmin, Laravel and Symfony apps, and plenty of vendor web consoles.

• A WordPress or Moodle update won’t fix it. Core, plugin and theme updates don’t touch the PHP interpreter. The fix comes from whoever manages the server.
• Managed hosting: the provider patches PHP. Ask them to confirm they have, and when.
• Self-hosted or VPS: you patch PHP yourself, through your OS packages or container image.
• Old PHP versions: sites stuck on unsupported PHP, often because of an ageing plugin or theme, are the most exposed. Upgrade, use a vendor backport, or take them offline.

If you can’t update immediately

PHP is clear that only updating is a complete fix. These settings reduce exposure but do not make an installation safe. Set them in php.ini, the FPM pool or server config, not in ini_set() or .user.ini, then restart every worker.

; php.ini / FPM pool (applies before request parsing)
memory_limit = -1
post_max_size = 8M            ; 32M if file uploads are required
upload_max_filesize = 8M      ; must stay below post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0    ; PHP 8.5 only

• CVE-2026-109618: set memory_limit=-1 so applications can’t override it (for example, php_admin_value in the FPM pool or Apache config). Yes, that removes PHP’s memory limit; it is what PHP recommends here. Use a container or cgroup limit as the availability boundary instead, not RLIMIT_AS or RLIMIT_DATA. Enforce request-size, field-count, part-count, header-count and nesting-depth limits at the web server or proxy.
• CVE-2026-109619: disable session.upload_progress.enabled. On PHP 8.5, also set fatal_error_backtraces=0. Remove invalid or deprecated per-request settings, and fix any fatal errors or timeouts an attacker can trigger.

NCSC guidance

The UK’s National Cyber Security Centre has issued an alert confirming the issue is fixed and advising organisations to:

• Identify all PHP systems, running any version, prioritising internet-facing ones
• Monitor internet-facing PHP systems for malicious activity
• Update to the latest version of PHP and continue to monitor for future updates
• Keep checking for updates from third-party vendors, including appliances and services that bundle PHP

Where immediate remediation isn’t feasible, the NCSC says to consider taking the system offline until it can be fully mitigated. CERT-EU’s Security Advisory 2026-018 gives similar advice.

What to do now

1. Patch internet-facing PHP first, then everything else.
2. Confirm the patch is live. Check the running version or package changelog after restarting, not just that the update installed.
3. Chase your supply chain. Ask hosting providers, MSPs, SaaS and appliance vendors running PHP when they will patch.
4. Watch your logs. Monitor internet-facing PHP systems for signs of malicious activity.
5. Deal with what you can’t patch. Apply PHP’s interim settings, and isolate or take offline anything left on an unsupported version.

The technical details are now public, so expect working exploit code soon.

Bottom line

Two unauthenticated RCEs in PHP itself, with a demonstrated exploit against mod_php. If you run PHP, or a site built on it, update today and confirm it took.

Sources

• PHP.net: Security advisory and release announcements
• NCSC: Critical security issue affecting PHP
• CERT-EU Security Advisory 2026-018