PHP's October 2026 security release: a guide for developers and WordPress sites

On 21 October the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Each one fixes two critical vulnerabilities that can allow remote code execution without authentication. The PHP security team gave a day's notice, rated both issues 9.2 on CVSS v4.0, and asked everyone to update immediately.

That is serious, and it deserves attention this week. It is also a problem with a clear fix. For most developers it means one package update and a restart. For most WordPress site owners it means checking a version number and, if needed, sending one message to their host.

The two vulnerabilities in plain terms

Both bugs sit in the PHP engine, not in any framework or CMS built on top of it. Your application code can be perfectly written and still be exposed.

The first, CVE-2026-109618, involves running out of memory at the wrong moment. If PHP hits its memory limit while it is still setting up internal data for a request, the cleanup that follows can treat half-built data as valid. An attacker who can push a request into that state can turn the corruption into code execution.

The second, CVE-2026-109619, is about state that outlives its request. PHP workers handle many requests in turn. Under certain conditions, internal state from one request survives after its memory has been freed, and the next request on the same worker can use it before normal initialisation resets it.

The advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as affected. In practice that covers every PHP installation that serves web requests. The PHP team considers mod_php the highest risk, because a demonstrated exploit there triggers before any application code runs.

Fixed versions

• PHP 8.5: update to 8.5.12
• PHP 8.4: update to 8.4.27
• PHP 8.3: update to 8.3.36
• PHP 8.2: update to 8.2.35

Linux distributions and LTS vendors received the patches before the public release, so updated packages from Debian, Ubuntu, Red Hat and similar sources should already be available. Distribution packages often keep an older upstream version number and add the fix as a backport, so check your vendor's security notice rather than relying on the version string alone.

If you manage your own servers

Update the PHP package, then restart every PHP process: FPM pools, Apache if you use mod_php, and any long-running workers or FrankenPHP instances. A patched binary on disk does nothing for a worker that loaded the old one last week.

Container images need rebuilding from a patched base image and redeploying. A pinned base tag such as php:8.3-fpm will pick up the fix on the next pull. A digest-pinned image will not.

Once the update is out, confirm what is actually running. php -v on the command line tells you about the CLI binary, which is not always the same build your web server uses. A phpinfo() page behind authentication, or your monitoring, gives the more reliable answer.

If you run a WordPress site

WordPress itself does not need an update for this. The fix happens one layer down, in the PHP version your hosting runs.

To check it, go to Tools > Site Health > Info in the WordPress admin and open the Server section. The PHP version is listed there. Your hosting control panel usually shows it too.

On managed WordPress hosting, the provider is very likely patching this already. On shared hosting or a VPS someone else set up, it is reasonable to ask directly. A short message is enough: "Has the PHP security release from 21 October 2026 been applied to my server?" A good host will answer with a yes and a date.

If you manage the server yourself, the section above applies to you.

Older PHP versions

PHP 8.1 and earlier no longer receive updates from the PHP project. Given the severity, the security team published minimal source backports for PHP 7.4, 8.0 and 8.1, intended for people who build PHP from source. Some distributions and LTS vendors also provide backported fixes.

For most WordPress sites on an old PHP version, the practical step is to move to a supported release. Most hosts let you switch PHP versions from the control panel. Test on a staging copy first if your theme or plugins are old, since compatibility issues usually show up there before they reach visitors.

PHP 8.2 is also close to the end of its life. It stops receiving security fixes after 31 December 2026, so a site on 8.2 should plan its next move now rather than at the next advisory.

If you cannot update today

The PHP team is clear that only updating fully resolves these issues. The mitigations below reduce exposure to specific attack paths, and they are worth applying if an update has to wait a day or two. They do not make a server safe.

; Apply in php.ini, the FPM pool or server config, then restart every worker
session.upload_progress.enabled = 0
post_max_size = 8M        ; 32M if the site needs file uploads
upload_max_filesize = 2M  ; keep below post_max_size

A few further points from the advisory:

• Setting memory_limit = -1 removes the controllable memory limit failure behind the first bug. Set it where applications cannot override it, such as php_admin_value in the FPM pool or Apache configuration. Pair it with a container or cgroup memory limit so one worker cannot exhaust the machine.
• Settings applied through ini_set() or an FPM .user.ini file are read too late to help.
• On PHP 8.5, setting fatal_error_backtraces = 0 blocks one confirmed path for the second bug.
• Hiding errors with display_errors or @ does not help. Removing deprecated per-request settings that emit diagnostics, and fixing fatal errors an attacker can trigger, does.

On shared or managed hosting you will not have access to most of these settings, so updating, or asking your host to, is the only option.

Follow-up notices

On 23 October the PHP team recommended keeping session.upload_progress.enabled = 0 until the next regular release, to cover an additional, unlikely code path. It only applies to applications that change session.serialize_handler at runtime before starting a session. If you applied the setting on the 21st, nothing further is needed.

On 26 October, updated Windows builds shipped with a fix for a separate Brotli decompression flaw. It only affects Windows installations that enable automatic decompression in cURL, which is off by default.

Keeping it in proportion

Critical PHP advisories are uncommon, and this one arrived with advance notice, coordinated vendor patches and detailed guidance. For developers, the work it asks for is routine: update, restart, confirm. For WordPress sites, it is a version check and possibly one email to a host.

The full details are in the official PHP security advisory.