PHP Security Vulnerabilities October 2026: How to Fix Them

On 21 October 2026 the PHP project shipped emergency releases for two critical remote code execution bugs, and two days later it published an informational advisory about a third, still-unpatched issue. Laravel also published two framework advisories on 19 October. This guide covers the php security vulnerabilities october 2026: what is affected, the exact versions that fix them, and step-by-step commands to patch Ubuntu servers, PHP-FPM, Apache mod_php, Docker images and Laravel apps. Every CVE and version below was checked against the official PHP 2026 news archive, the php-src security advisories and the Laravel framework advisories.

Problem: Critical PHP Security Vulnerabilities in October 2026

CVE-2026-109618: RCE via OOM corruption

Advisory GHSA-w8hw-w9fx-j79w, rated critical (CVSS 4.0 score 9.2). PHP uses longjmp() to abort a request on out-of-memory errors. If an allocation fails while request memory is only partly initialized, the request shutdown can later read or branch on that invalid memory. The advisory says several out-of-memory strategies, including multipart parsing problems, can trigger this reliably and lead to remote code execution.

CVE-2026-109619: RCE via stale global state

Advisory GHSA-6wmf-4rv5-p3rp, also critical with a CVSS 4.0 score of 9.2. Some request-owned global state (error, session, object and extension state) can survive after its memory is freed. The next request handled by the same worker can touch that stale state before initialization resets it, which is a use-after-free that can be turned into code execution.

CVE-2026-115560: session upload progress (not yet patched)

Announced on 23 October as an informational advisory. PHP describes it as an "unlikely RCE vector" that needs an unusual setup: the application sets session.serialize_handler to php_binary or php_serialize, then switches it to php with ini_set() before session_start(), while session upload progress is still enabled. PHP will publish the full advisory and fix in the next regular release. Until then it recommends session.upload_progress.enabled=0.

Who Is Affected

• Every PHP install that serves web requests and is below the fixed versions. The PHP team names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest risk, with a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs.
• Fixed releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those branches is vulnerable.
• PHP 8.1 and older no longer get releases from the PHP project. The security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship backported packages. Otherwise, upgrade.
• Laravel apps are affected through the runtime. Middleware and authentication don't protect you from a bug in the PHP engine, because the attack can happen before your code runs.

Laravel framework advisories (19 October 2026)

• CVE-2026-114509, Token-based API guard auth bypass, critical (CVSS 4.0 score 9.2). With Laravel's built-in TokenGuard and some MySQL/MariaDB configurations, a crafted non-string credential can make the lookup match the wrong user. Fixed in 12.68.0 and 13.29.0.
• CVE-2026-114508, Unauthorized data destruction, moderate (CVSS 3.1 score 6.5). A crafted relationship-inclusion request to a read endpoint can trigger a destructive operation on a related table. It affects 12.45.0 up to 12.67.x and 13.x before 13.27.0. Fixed in 12.68.0 and 13.27.0.
• Per the Laravel support policy, Laravel 11 security fixes ended on 12 March 2026, so it won't receive these patches.

Earlier 2026 PHP CVEs worth confirming

These were fixed in earlier releases, so the October versions already include them:

• CVE-2026-91765: SOAP unbounded recursion in server-side cleanup (high, DoS). Fixed 24 September 2026 in 8.2.34, 8.3.35, 8.4.26 and 8.5.11.
• CVE-2026-91768: IPv6 ACL bypass in FastCGI listen.allowed_clients (medium). Fixed in the same September releases.
• CVE-2026-91766: cross-origin credential leak in HTTP stream wrapper redirects (medium). Fixed in the same September releases.
• CVE-2026-17543: SQL injection in ext-pgsql via E'...' backslash breakout (high). Fixed 30 July 2026 in 8.2.33, 8.3.33, 8.4.24 and 8.5.9. This one matters for PostgreSQL-backed ERP systems.

Root Cause

Both October engine bugs come from memory lifecycle problems. Data belonging to one request is either used before it is fully set up (after an out-of-memory abort) or after it has been freed (by the next request in the same worker). Long-lived workers in PHP-FPM, mod_php and FrankenPHP reuse processes across requests, which is why a crafted request can affect what happens later. The Laravel issues are framework logic bugs: loose handling of a non-string token value, and relationship inclusion on read endpoints reaching a destructive query.

Step-by-Step Fix

Step 1: Find every PHP binary that serves traffic

The CLI, PHP-FPM and Apache can each run a different version, so check them separately.

php -v
php-fpm8.4 -v                       # adjust to your installed version(s)
ls /etc/php/                        # Debian/Ubuntu: one folder per installed version
apache2ctl -M 2>/dev/null | grep -i php
php --ini
dpkg -l | grep -E '^ii\s+php'

Step 2: Patch PHP on Ubuntu or Debian

Distributions received the patches in advance, so update from whichever repository you installed PHP from (Ubuntu's own packages or the ondrej/php PPA). Distro packages may keep an older upstream version number with backported fixes, so check the package changelog for the CVE ids rather than relying on php -v alone.

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.4*'      # repeat per installed branch
apt changelog php8.4-common | grep -E 'CVE-2026-10961[89]'

Step 3: Restart PHP-FPM and Apache

Running workers keep the old code in memory until they restart.

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2        # needed for mod_php
sudo systemctl reload nginx
systemctl status php8.4-fpm --no-pager

Step 4: Rebuild Docker images

Containers don't update themselves. Pull a fresh base image, rebuild without cache and redeploy, then confirm the version inside the running container.

docker pull php:8.4-fpm
docker compose build --pull --no-cache app
docker compose up -d app
docker compose exec app php -v

If you pin exact tags such as php:8.4.26-fpm, bump them to at least 8.4.27.

Step 5: Apply the interim mitigation

Set this in php.ini, an FPM pool or server config, not with ini_set() or .user.ini, and restart every worker. PHP says it blocks the confirmed session paths for CVE-2026-109619 and the CVE-2026-115560 vector, but it is not a substitute for patching.

; /etc/php/8.4/fpm/conf.d/99-security.ini (and apache2/conf.d for mod_php)
session.upload_progress.enabled = 0

; or in an FPM pool file
php_admin_flag[session.upload_progress.enabled] = off

If you truly can't update yet, the PHP advisory also lists partial measures for CVE-2026-109618: lower post_max_size (8M without uploads, 32M with), enforce request limits at the web server or proxy, and on PHP 8.5 set fatal_error_backtraces=0. It also describes a memory_limit=-1 option; read the advisory before using it, because it removes your per-request memory cap. None of these make the server safe.

Step 6: Update Laravel

composer show laravel/framework | grep versions
composer update laravel/framework --with-all-dependencies
composer show laravel/framework | grep versions   # expect >= 12.68.0 or >= 13.29.0
composer audit --locked
php artisan optimize:clear

Run your test suite and deploy through staging. On Laravel 11, plan an upgrade to 12 or 13; there are no more security releases for it.

Code and Commands: Quick Reference

# Version actually served over HTTP (remove the file right after!)
echo '<?php echo PHP_VERSION, " upload_progress=", ini_get("session.upload_progress.enabled");' \
  | sudo tee /var/www/html/v-check.php >/dev/null
curl -s https://your-domain.test/v-check.php
sudo rm /var/www/html/v-check.php

# Effective FPM setting
php-fpm8.4 -i 2>/dev/null | grep upload_progress.enabled

Note that composer audit checks Composer packages, not the PHP runtime. You need both checks.

Verification

• CLI, FPM and the HTTP-served version all show 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or a distro package whose changelog lists both CVE ids.
• session.upload_progress.enabled reports off for the web SAPI.
• composer show laravel/framework is at or above 12.68.0 or 13.29.0, and composer audit --locked reports no advisories.
• Every container image has been rebuilt and redeployed, including queue workers and schedulers.
• Logs show no unusual crashes, memory exhaustion or segfaults after the restart (check journalctl -u php8.4-fpm and the FPM log).

Prevention

• Subscribe to the PHP news feed and watch the php-src and Laravel advisory pages on GitHub.
• Run composer audit in CI and fail the build on known advisories.
• Rebuild Docker images on a schedule so base image patches land automatically.
• Stay on supported branches. Per php.net, PHP 8.2 security support ends 31 December 2026.
• Rotate secrets after any suspected compromise; see API key rotation.
• Keep defence in depth in your Laravel code too, such as IDOR vulnerability prevention.
• Set container memory limits as an availability boundary; see Docker exit code 137 for what happens when they are hit.

FAQs

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, or distro packages with backported fixes.

Is disabling session upload progress enough?

No. It blocks the confirmed session paths and the CVE-2026-115560 vector, but only updating PHP fixes the October engine bugs.

Are Laravel apps affected by the PHP CVE-2026 bugs?

Yes, if the server runs an unpatched PHP version. The attack targets the runtime, so Laravel middleware can't stop it.

Does composer audit detect the PHP vulnerabilities?

No. It checks Composer dependencies such as laravel/framework, not the PHP binary. Check PHP with php -v, FPM and your package manager.

Which Laravel versions fix the October 2026 advisories?

12.68.0 or later on Laravel 12, and 13.29.0 or later on Laravel 13. Laravel 11 no longer receives security fixes.

What if I'm still on PHP 8.1 or older?

The PHP project doesn't release for these branches. Use your distribution's or LTS vendor's backported packages, build from the official source backports, or upgrade to a supported branch.