php2shell: is your site exposed?

What happened

On 21 October 2026 the PHP project published fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619. They let anyone on the internet run code on a server that runs PHP, without signing in: no password, no account, just a crafted request. PHP rates them critical (CVSS v4 9.2).

Am I affected?

If your site runs on PHP and its version is older than the fixed release of its branch, yes. PHP's advisory names the ways PHP is run that are exposed: PHP-FPM (behind nginx or Apache), mod_php inside Apache (the highest risk), php-cgi, FrankenPHP and LiteSpeed. Between them, that is almost every PHP site.

You may run PHP without thinking of it as PHP. WordPress, WooCommerce, Laravel, Magento, Drupal, Joomla and most shared hosting plans all run on it. A "headless" site whose pages come from a JavaScript framework often still has a WordPress behind it, on another address such as wp. or cms. of your domain: that server needs the update too.

The check above reads what your home page tells anyone: the Server and X-Powered-By headers, the generator tag WordPress adds, and the paths in the page. If your server names its PHP version, you see at once whether it is below the fix. If it hides the version, that is good practice, but it does not make the server safe: you need to look on the server itself.

How to check your PHP version

• On the server: run php -v. The command-line PHP can differ from the one serving your site, so also run the FPM binary your site uses (for example php-fpm8.3 -v), or ask your host.
• In WordPress: Tools › Site Health › Info › Server shows the PHP version your site runs on.
• In a hosting panel: cPanel shows it under MultiPHP Manager or Select PHP Version; Plesk under PHP Settings for each domain. Managed hosts usually show it on the site's dashboard.
• Node.js: node -v on the server, or the base image in your Dockerfile (node:22 follows the branch; a pinned tag needs a rebuild).

Then compare: same branch, at or above the fixed release. 8.3.36 fixes 8.3; 8.3.10 does not, even though it is newer than 8.2.35.

What to do now

1. Update PHP to the fixed release of its branch, then restart PHP: the FPM pool, or the web server when PHP runs inside it. On a managed host, ask them to confirm the date they updated.
2. On PHP 8.1 or older, plan the move to a supported branch now. There is no official fixed release for those branches.
3. Until you can update, PHP's advisory lists mitigations. They reduce the exposure; they do not make a site safe:
   • set memory_limit=-1 through php_admin_value in the pool or virtual host;
   • set post_max_size to 8M (32M on a site that takes uploads);
   • set session.upload_progress.enabled=0, then restart the PHP workers;
   • on PHP 8.5, set fatal_error_backtraces=0;
   • at the proxy, limit the request size, the number of form fields and the number of multipart parts.
4. Keep the version hidden once you are updated: expose_php = Off in php.ini removes X-Powered-By, and server_tokens off; stops nginx naming its own version.
5. Close the WordPress login page to the world if you can: allow only your own addresses, or add a second factor.

Node.js fixes the same day

The same day, Node.js shipped its October 2026 security releases: ten fixes, the most serious a flaw in the Brotli decoder (CVE-2026-111497) that can let a crafted request run code on the server. Others concern DNS lookups, TLS hostname checks and keep-alive connections. The fixed releases are 22.23.4, 24.22.1 and 26.12.1. A Next.js site runs on Node.js, so the check above flags Node.js whenever it sees Next.js. Update Node.js, rebuild the app's image if it runs in a container, and restart it.

What this check can and can't see

This reads only what your home page shows anyone. It can't see inside your server, and it doesn't test for the flaw.

• One look, like a browser: your home page, then, for a WordPress host of your own domain, its login page, /xmlrpc.php, /readme.html, /wp-json/ and home page. Eight requests at most, each listed in the result: never a secret file, a user list or a form sent. No attack, no password, no form sent.
• Proof for every finding: the exact header line or page reference we read, the address it came from, and a command to check it yourself. What we could not read says "could not check": we never guess.
• A hidden version is good, not proof: the flaw works whether the version is shown or not. Only the server can say.
• The check keeps nothing: no cookie, and a result stays in memory for an hour, so a second check is instant, then it is gone. But a result page's address names the site you checked (/check/?url=…), and like any page address it is in our server log for 14 days (privacy note).