Critical PHP Vulnerabilities: How to Fix, Patch, Mitigate & Stay Secure

In October 2026 the PHP project shipped an out-of-band security release for every supported branch. It closes two bugs in the way PHP sets up and tears down each web request. Because that code runs for every request, the weakness sits underneath your framework, CMS and plugins. A clean Laravel or WordPress codebase is still exposed if the PHP runtime below it is unpatched.

What makes this release urgent is the combination: attackers need no account, the bugs can lead to full remote code execution, and exploitation attempts are already being seen against live servers. Researchers also showed the flaws can leak chunks of PHP worker memory, which may contain database passwords, session tokens and API keys.

Any PHP installation that answers web requests is at risk. How easy it is to exploit depends on how PHP is plugged into your web server:

Upgrade to at least the version listed for your branch. Newer patch releases include the fix too.

Not sure where you stand? Use the instant PHP version checker at the top of this guide.

Using a Linux distro package? Vendors like Debian, Ubuntu and Red Hat often backport fixes while keeping an older version number. Search their security tracker for the two CVE IDs to confirm.

Servers often have several PHP binaries side by side. The CLI version is not always what your website uses, so check the one behind your web server too.

php -v                         # CLI version
php-fpm8.3 -v                  # FPM binary (adjust branch)
apachectl -M | grep php        # is mod_php loaded?
docker exec <container> php -v # inside a container

No shell access? Log in to your hosting panel: cPanel shows it under MultiPHP Manager, Plesk under PHP Settings. In WordPress, go to Tools → Site Health → Info → Server.

Pick your environment below. Always take a backup or snapshot first, and restart PHP afterwards so the patched binary is actually loaded.

sudo apt update
sudo apt install --only-upgrade 'php8.3*'   # change 8.3 to your branch
php -v
sudo systemctl restart php8.3-fpm            # PHP-FPM
sudo systemctl restart apache2               # mod_php

sudo dnf clean all
sudo dnf upgrade 'php*'
php -v
sudo systemctl restart php-fpm httpd

apk update
apk upgrade php83 php83-fpm   # use php84 / php85 for newer branches
php83 -v

# Dockerfile: pin the patched tag
FROM php:8.3.36-fpm

# rebuild without cache and redeploy
docker build --pull --no-cache -t my-app .
docker compose up -d --force-recreate

:: 1. Download the patched build from windows.php.net
:: 2. Back up C:\xampp\php\php.ini
:: 3. Replace the php folder, restore php.ini
C:\xampp\php\php.exe -v
:: 4. Restart Apache from the XAMPP Control Panel

# as root on the server
dnf update 'ea-php*'      # or: yum update 'ea-php*'
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd

These settings close the known attack paths while you plan the update. They are a bridge, not a fix. Restart PHP-FPM or Apache after changing them.

; ---- Temporary hardening until PHP is patched ----
; Blocks the session-lifecycle path (CVE-2026-109619)
session.upload_progress.enabled = 0

; Shrinks the out-of-memory window (CVE-2026-109618)
post_max_size = 8M          ; 32M if you need uploads
upload_max_filesize = 6M    ; always below post_max_size
max_input_nesting_level = 32

; PHP 8.5 only
fatal_error_backtraces = 0

# Nginx: reject oversized bodies before PHP sees them
client_max_body_size 8m;

# Apache: same limit in bytes
LimitRequestBody 8388608

# PHP-FPM pool (e.g. /etc/php/8.3/fpm/pool.d/www.conf)
php_admin_value[session.upload_progress.enabled] = 0
; optional, costs performance: fresh worker per request
; pm.max_requests = 1

The most common mistake is updating the package but never restarting the running workers. Confirm what the web server is actually using:

# Version of every installed PHP binary
php -v
php-fpm8.3 -v

# Confirm the mitigation is live (CLI)
php -i | grep -E "session.upload_progress.enabled|post_max_size"

# FPM/Apache can use a different php.ini: check via a temporary file
echo "<?php phpinfo();" | sudo tee /var/www/html/_check.php
# open https://your-site/_check.php, then delete it immediately
sudo rm /var/www/html/_check.php

• phpinfo() shows the patched version for the web SAPI
• All PHP-FPM pools and app servers were restarted
• Docker images were rebuilt and every container recreated
• Staging, cron and queue workers run the same version
• The temporary phpinfo file has been deleted

If a vulnerable server faced the internet, assume secrets in memory could have leaked and look for signs of a break-in.

1. Rotate secrets. Database passwords, API keys, SMTP and payment credentials, OAuth secrets. For WordPress, regenerate the salts in wp-config.php. For Laravel, rotate .env secrets (rotate APP_KEY carefully, as it invalidates encrypted data and sessions).
2. Invalidate sessions. Force all users and admins to log in again.
3. Hunt for web shells and unexpected file changes using the commands below.
4. Review accounts: new admin users, SSH keys, cron jobs and scheduled tasks.
5. Check outbound traffic for unusual connections from your web servers.
6. Restore from a clean backup if you find anything you can’t explain.

# PHP files changed in the last 7 days (look for web shells)
find /var/www -name "*.php" -mtime -7 -ls

# Suspicious functions often used by backdoors
grep -rlE "eval\(base64_decode|assert\(\$_|system\(\$_" /var/www

# Large multipart POSTs in the access log
awk '$6 ~ /POST/ && $10 > 5000000' /var/log/nginx/access.log

# New cron jobs and users
crontab -l; ls -la /etc/cron.*; tail -n 20 /etc/passwd