Skip to main content

PHP2Shell (CVE-2026-109618, CVE-2026-109619): How to Check and Fix

Security · 27.10.2026 · 3 min read

What happened

On October 21, 2026, the PHP developers released an out-of-band security update. Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2, allow arbitrary code execution on the server without authentication and without a password. Together they are known as PHP2Shell.

Why this is worse than an ordinary vulnerability

The attack triggers before the request reaches your site's code. A login form, two-factor authentication, and access rights inside the application do not help: by the time they are checked, the attacker's code has already run. The first vulnerability involves handling of an out-of-memory condition, which leaves request data half-parsed. The second involves leftover state in the worker process that is passed on to the next request.

Datadog researchers note that application-level checks do not stop the attack. Cloudflare is already recording requests aimed at these vulnerabilities.

Fixed versions

PHP branchFixed version
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35

Branches 8.1 and older no longer receive support. If you run one of them, upgrading to a newer PHP branch is the only option.

How to check your server in a minute

The command php -v answers the wrong question. Ubuntu, Debian, AlmaLinux, and other distributions backport the fix into the old version without changing its number: a patched server still reports 8.3.6. Check the package version and its changelog instead.

Ubuntu and Debian:

dpkg -l | grep -E 'php[0-9.]+-(fpm|cli|common)'
zgrep -l 'CVE-2026-109618' /usr/share/doc/php*/changelog.Debian.gz

If the second command prints a file path, the fix is installed. If it prints nothing, the server is still vulnerable.

AlmaLinux, Rocky, RHEL:

rpm -q php-fpm php-cli
rpm -q --changelog php-cli | grep -m1 CVE-2026-109618

What to do right now

  1. Update the PHP packages with your distribution's package manager. This is the fastest and supported path.
  2. Restart PHP-FPM. Without a restart, the old processes keep running the old code.
  3. Repeat the changelog check and confirm that the CVEs now appear in it.

Detailed commands for each system are in our articles on Ubuntu and Debian, AlmaLinux and RHEL, and on control panels and Docker.

If you cannot update right now

Temporary measures reduce risk but do not close the vulnerability. Disable upload progress tracking and limit the request body size:

session.upload_progress.enabled = 0
post_max_size = 8M

Restart PHP-FPM after the change. This buys time to update; it does not replace the update.

Frequently asked questions

I have PHP 8.3.6. Am I vulnerable?

Not necessarily. On Ubuntu 24.04 the fixed package is named 8.3.6-0ubuntu0.24.04.13 and still reports version 8.3.6. Check the package changelog, not the output of php -v.

Is it enough to update only PHP-FPM?

No. Update all PHP packages on the server and restart every service that uses them, including the web server if you use mod_php.

Does password-protecting the site help against PHP2Shell?

No. The vulnerability triggers before the application checks access.

Do ZevsHost customers need to do anything?

PHP is already updated on our shared hosting servers and in our billing system. Owners of VPS and dedicated servers must update PHP themselves, because the server is under their control.

Was this article helpful?
← Back to Knowledge Base Ask Support