1 Find every PHP on the server

Many servers run more than one PHP: the system package, versions installed by a control panel (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), containers and command-line builds used by cron. Each one that serves web requests must be updated.

Run php -v, list php-fpm processes with ps aux | grep php-fpm, and check your panel’s PHP selector.

2 Update to a fixed version

The fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution packages may carry the fix under an older version number — check the changelog for CVE-2026-109618 and CVE-2026-109619.

PHP 8.1 and older receive no release from the PHP project. Minimal source backports were published for 7.4, 8.0 and 8.1 for those who build from source, but the lasting fix is moving to a supported branch.

Debian / Ubuntu (distribution packages)

Install the security update from your distribution and restart PHP. The version number may stay the same; the package changelog lists the CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Apply the vendor errata for your PHP module stream, then restart.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / official php images

Pull or rebuild with the fixed tag and recreate the containers.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Use the panel’s update tool for every installed PHP version (EA-PHP, Plesk PHP handlers, alt-php, CustomBuild), then restart PHP-FPM. Panels often keep old versions installed for individual sites — update or remove them too.

Shared or managed hosting

You usually cannot update PHP yourself. Use the message on the result card to ask your provider for the exact version, the patch date and confirmation that workers were restarted.

Windows / IIS

Download the fixed build from windows.php.net, replace the PHP directory and recycle the IIS application pools.

3 Restart every PHP process

Installing a package does not change code that is already running. Restart PHP-FPM, Apache (for mod_php), LiteSpeed, FrankenPHP, queue workers and supervisors. For containers, rebuild or pull the new image — restarting the same image does not install a patch.

4 Verify

Run php -v for each binary and confirm the running processes use the new build (for example ls -l /proc/$(pgrep -o php-fpm)/exe should not say “deleted”). Then run this checker again.

5 If you cannot update today

Apply the partial mitigations below and restrict who can reach the site until you can update. They reduce the risk; they do not remove it.

6 Check for signs of compromise — and rotate secrets

If a vulnerable site was reachable from the internet, review activity from 20 October 2026 onwards: PHP worker crashes (SIGSEGV) in the PHP-FPM or Apache error log, new or modified PHP files in the web root, new cron jobs, new administrator accounts, and unexpected outbound connections.

Because CVE-2026-109619 can expose PHP process memory without running any code, a clean file system is not proof that nothing leaked. Change database passwords, API keys, payment and mail credentials, and invalidate user sessions for sites that were exposed.

7 After updating

The fix introduces a new hard memory limit: a process that reaches it is terminated immediately and shutdown handlers do not run. Check how your application behaves under memory pressure, review memory_limit together with post_max_size and max_input_nesting_level, and undo any temporary memory_limit = -1 you set before patching. Hiding the version with expose_php = Off is optional hardening, not a fix.

Partial mitigations (from php.net and the advisories)

These only narrow the known attack paths. php.net states that updating is the only safe choice.

; php.ini / FPM pool (php_admin_value) — restart all workers afterwards
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M if uploads are needed
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Set these in php.ini, the PHP-FPM pool (php_admin_value) or the server configuration — not with ini_set() or .user.ini — and restart the workers. Further measures from the advisories and the research team:

memory_limit = -1 blocks some paths that rely on PHP’s own memory limit, but hands memory exhaustion to the operating system — only use it together with a cgroup v2 memory.max limit. Do not use RLIMIT_AS or RLIMIT_DATA; they can trigger the same vulnerable paths.
Lower max_input_nesting_level as far as your forms allow.
Lower PHP-FPM pm.max_requests so workers are recycled more often (performance cost).
Request size, field-count and nesting limits at the web server or proxy; remove invalid or deprecated per-request INI settings.
SELinux or AppArmor policies can limit what a compromised worker may run — they reduce impact, they do not prevent memory disclosure.

References

Source: php.net security advisory, 21 October 2026. Last verified 2026-10-23.