Is your PHP patched?

What can actually be seen from outside

A version number in a header is the only proof a stranger can get. Most sites remove it: of the popular PHP projects we checked while writing this page, nine out of nine hid the version. That is why “vulnerability scanners” that promise to confirm this CVE remotely are mostly guessing.

What a passive check can establish:

• Whether the site runs on PHP at all — session cookies, .php links, platform markers.
• The version, when it is disclosed — X-Powered-By: PHP/8.3.29 is a fact, not an inference.
• Which server API is in play — FrankenPHP and LiteSpeed announce themselves; Apache with X-Powered-By looks like mod_php, the setup the PHP team rates as most dangerous.
• Leaks that publish the version for you — an open phpinfo() or a PHP-FPM status page. If either is reachable, your exact build is public.

Everything else needs one command inside the server. That is not a weakness of the check — it is the difference between a report and a guess.

Verify on the server in one command

Run this where the site is served (SSH or your hosting panel’s terminal):

# what the web server actually uses
php -v
# if PHP-FPM is used, ask the binary of that branch
php-fpm8.3 -v

# the fixed versions are:
# 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

Compare the first line of the output: PHP 8.3.36 (cli) is patched, PHP 8.3.29 is not. If your panel shows several PHP versions, check the one the site is switched to — updating a version the site does not use changes nothing.

After the update, run the check again: the PHP row should move from “vulnerable” to “at or above”. If it still says “version not disclosed”, that is fine — the header is hidden, but the server now answers with the patched build.

What to do, in order

1. Update PHP to a fixed build. 8.2.35, 8.3.36, 8.4.27 or 8.5.12. The PHP team, CERT-EU and CISA all say the same thing: the patch is the only complete fix. Distribution packages and LTS vendors received the patches in advance — update through them if you use packages.
2. If you cannot update today, lower the exposure. The advisory suggests removing the memory ceiling (php_admin_value[memory_limit] = -1 in the FPM pool, or the Apache equivalent) and lowering post_max_size (8M without uploads, 32M with). Understand what you are trading: memory_limit=-1 removes the limit that protects you from ordinary runaway scripts.
3. Do not trust the “session.upload_progress off” advice alone. It appears in early guidance, but independent researchers reported that it does not stop the attack. Read it as a partial measure, never as a fix.
4. Look for signs of use. Large multipart requests, memory-exhaustion errors during request start, unexpected shell processes, new files in upload directories. A successful exploit does not have to crash the worker, so absence of crashes proves nothing.
5. Re-check after the update and keep the result. If you run sites for clients, that timestamped report is the evidence they will ask for.

On end-of-life branches (8.1 and older) there is no official package: PHP published minimal source backports for 7.4, 8.0 and 8.1 — building them is a task for whoever maintains the server, and the long-term answer is an upgrade.

What is affected

Every way of serving PHP is listed as affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is rated the most dangerous, because the malicious request is handled before application code — authentication cannot block it. PHP is also embedded in appliances and control panels, where nobody updates it by hand.

Sources

• php.net — security advisory, 21 Oct 2026 (fixed versions, mitigations, source backports)
• GHSA-w8hw-w9fx-j79w — CVE-2026-109618, RCE via OOM corruption
• GHSA-6wmf-4rv5-p3rp — CVE-2026-109619, RCE via stale global state
• CERT-EU Security Advisory 2026-018
• CISA alert, 21 Oct 2026
• NCSC-NL operational repo (php2shell)
• Datadog Security Labs — reproduction and detection notes