Free security check

Is your website's PHP patched against php2shell?

PHP shipped emergency fixes on 21 October 2026 for two flaws that let attackers take over a server without logging in, and they are already being exploited. See what your site gives away about its server, then use the steps below to confirm and patch.

A few ordinary requests, each listed in your result. Nothing is attacked, and nothing about your site is saved.

Do this today

Confirm your PHP version in two minutes.

Last reviewed 22 October 2026. Facts on this page come from the PHP project's advisory and Cloudflare's write-up.

  1. 1

    Find the version your site really runs

    • WordPress: Tools, then Site Health, then the Info tab, then Server.
    • Hosting panel: the PHP version or PHP settings page for your domain.
    • SSH access: php -v. Web requests are often answered by PHP-FPM, which can be a separate install from the php command you type, so also run the versioned binary, such as php-fpm8.3 -v.
    • Managed or shared hosting: ask support for the version and the date it was last updated.
  2. 2

    Compare it with this table

    Your branchSafe from
    PHP 8.58.5.12 or later
    PHP 8.48.4.27 or later
    PHP 8.38.3.36 or later
    PHP 8.28.2.35 or later
    PHP 8.1 and olderNo upstream release: upgrade the branch

    Match the first two numbers before looking at the last one. A server on 8.4.20 is unpatched even though 20 is bigger than the 12 in 8.5.12, because its own branch is safe only from 8.4.27.

    Installed PHP from Ubuntu, Debian or Red Hat packages? Those vendors often ship the fix without changing the upstream number, so an older-looking version can be safe. Their security notice for the php package is the place to confirm.

  3. 3

    Patch, then restart PHP

    Install the update, then restart whatever runs PHP: the php-fpm service, or Apache when it loads PHP as mod_php. Until that restart, the old code is still the one answering visitors. On branches 8.1 and older there is no upstream fix, so schedule the move to 8.2 or newer.

Can't patch yet? Stopgaps for the next few days

PHP's security team published settings that shut the known attack routes. Use them as short-term cover while you arrange the update, not as the fix:

  • Remove the memory ceiling with memory_limit=-1, set somewhere applications cannot change it, such as php_admin_value in the FPM pool or Apache config.
  • Keep post_max_size small: 8M for sites without uploads, 32M for sites with them. Cap request size, field counts and multipart parts at the web server or proxy as well.
  • Turn off session.upload_progress.enabled in php.ini or the pool config (setting it from application code does not count), then restart every PHP worker.
  • On PHP 8.5 only, set fatal_error_backtraces=0 and restart the workers.

After patching, stop announcing your versions to the world: expose_php = Off in php.ini, plus server_tokens off; for nginx or ServerTokens Prod for Apache.

Who should be worried

Anyone whose server uses PHP to answer web requests. The advisory covers PHP-FPM, Apache's mod_php (which it calls the riskiest setup), php-cgi, FrankenPHP and LiteSpeed. In practice that is nearly every WordPress, WooCommerce, Laravel, Magento and Drupal site, plus most shared hosting accounts.

Don't forget the back office. A shop or marketing site built with a JavaScript framework may still pull its content from a PHP-based CMS on a separate server. That server needs patching too, even if the public site never mentions PHP.

How our check works

It sends an ordinary GET request to the page you enter, follows up to four redirects, and reads the response: server headers, security headers, cookie names, a CMS's generator tag and the file paths in the HTML. If the site is WordPress, it also requests three public files on the same address (the login page, xmlrpc.php and readme.html) to see whether they answer.

Every request is listed in your result with its answer and size, and each finding quotes the line it is based on and gives you a command to see it yourself.

It never attempts the exploit. That makes it safe to run on any site, but it also means a reassuring result only tells you the page didn't give away an unpatched version. If you would rather have the server checked from the inside, our maintenance team can do it and apply the update.

FAQ

php2shell questions we keep hearing.

In plain terms, what can an attacker do with php2shell?

Take control of the web server. The two flaws, CVE-2026-109618 and CVE-2026-109619, live in PHP itself, so a single crafted web request can make the server run the attacker's code, with no login involved.

From there they can read your database, plant malware or use the server to attack others. Details leaked before PHP released its patch on 21 October 2026, and Cloudflare saw attacks the same day.

Our host manages the server. Do we need to do anything?

Yes: ask them. On shared and managed hosting the host updates PHP, but you are the one who knows whether it happened.

Open a ticket asking which PHP version your site runs and the date it was updated for this advisory. If the answer is vague, or your site is still on PHP 8.1 or older, ask about moving to a supported version.

We use Cloudflare. Are we covered?

Covered for traffic that passes through Cloudflare, if the WAF is switched on. Cloudflare says its managed rules have blocked php2shell by default on all plans with the WAF since the morning of 21 October.

Anyone who finds your server's real IP address can skip Cloudflare entirely, though, and Cloudflare still recommends patching. Treat it as a seatbelt, not a substitute.

Does updating WordPress or our plugins fix it?

No. WordPress, its plugins and themes all run on top of PHP, and the flaws are in PHP itself. The PHP installation on the server has to be updated.

Your WordPress admin will tell you which PHP it runs under Tools, then Site Health, then Info, then Server.

How is this check different from a vulnerability scan?

A vulnerability scan tries attacks. This check does not: it loads your page as an ordinary visitor would, plus three public WordPress files when the site is WordPress, and reports what the server reveals, quoting the exact header or line each finding is based on.

So a reassuring result means the site did not reveal an unpatched version. It cannot prove the server is patched; only the server itself can.

What happens to the address I enter?

It is used for the check and then discarded. It travels in the body of the request rather than the URL, so it never lands in our web server's logs.

The only thing we keep is a ten-minute counter of how many checks your connection has run, keyed to a one-way hash of your IP address, to stop the tool being abused. If you send us your results through the form, they arrive as an email.

Rather have someone handle the update?

We patch PHP on Laravel, WordPress and custom servers, confirm the real version from the inside, and leave you a short note of what changed.

Start a projectEmail us