Articles
development

Two critical PHP vulnerabilities (October 2026): what to patch and how

Two critical PHP flaws (CVSS 9.2) allow unauthenticated remote code execution, and proofs of concept are circulating. Affected versions, fixes and interim mitigations.

In short: on 21 October 2026 the PHP project released fixes for two critical vulnerabilities (CVSS 9.2 each) that can lead to remote code execution. One unauthenticated HTTP request can trigger an attack before any application code runs, so it does not matter which framework you use. Proofs of concept are already public. If you run PHP 8.2 or newer, update today. If you run anything older, read on.

This is a summary of CERT-EU Security Advisory 2026-018 and the official PHP announcements. It reflects the information available on 22 October 2026. Check the linked sources for updates.

Am I affected?

PHP branch Vulnerable Fixed in
8.5 before 8.5.12 8.5.12
8.4 before 8.4.27 8.4.27
8.3 before 8.3.36 8.3.36
8.2 before 8.2.35 8.2.35
8.1 and older (end of life) yes no official release; minimal backports exist for 7.4, 8.0 and 8.1

To check the version your web server actually runs, look at phpinfo() or your hosting panel. Don't rely on php -v alone: on many servers the CLI and PHP-FPM are different versions. Products that bundle PHP (appliances, control panels, Docker base images) may also be affected.

What the vulnerabilities are

CVE-2026-109618: memory corruption on out-of-memory

When a request exceeds memory_limit, PHP aborts it. If that happens while a file upload form is being parsed, the cleanup step can free memory that was never initialised and may contain attacker-controlled data. That is a classic route to code execution. (GHSA-w8hw-w9fx-j79w)

CVE-2026-109619: stale state between requests

After certain failures, such as a fatal error, some request state can outlive the memory it points to. The next request on the same worker process may then use that state before it is reset. (GHSA-6wmf-4rv5-p3rp)

What to do

  1. Update now. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, preferably from your Linux distribution or LTS vendor. Then restart PHP-FPM (or Apache with mod_php) so that no old worker keeps running.
  2. Using the Remi repository? CERT-EU notes that rpms.remirepo.net would not have packages on release day. Use your distribution's packages or build from source until it does.
  3. On PHP 8.1 or older? Upgrade to a supported branch, or ask your vendor for a backported fix. If you have no vendor, build from source with the published backports. Treat this as the push to plan the upgrade you've been postponing.
  4. Can't patch right away? Take internet-facing systems off the public network until the fix is installed and verified.

Temporary mitigations (not a fix)

These settings reduce the attack surface while you prepare the update. CERT-EU is clear that only an update fully fixes these vulnerabilities.

For CVE-2026-109618:

  • Set memory_limit=-1 so that applications can't override it, for example with php_admin_value in the FPM pool. Cap memory at the container or cgroup level instead. Don't use RLIMIT_AS or RLIMIT_DATA.
  • Set post_max_size to 8M if you don't need uploads, or 32M if you do, and keep upload_max_filesize below it.
  • Enforce limits on request size, header size, field count and multipart parts at the web server or reverse proxy.

For CVE-2026-109619:

  • Set session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart all workers.
  • On PHP 8.5, also set fatal_error_backtraces=0 and restart.
  • Remove invalid or deprecated per-request settings, and fix fatal errors and timeouts that visitors can trigger. Hiding errors with display_errors, error_reporting or @ does not help.
; PHP-FPM pool: interim hardening until the update is installed
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only
php_admin_flag[fatal_error_backtraces] = off

Sources

Stuck on an old PHP version?

Patching is easy when you're on a supported branch. It gets hard when an application is still on PHP 7.x or 8.0. I help teams move legacy PHP and Laravel applications to supported versions without a big-bang rewrite. See how a PHP/Laravel upgrade works, or start with a legacy audit to find out where you stand.

Back to all articles