PHP2Shell checker: what a check can and can't confirm

If your site runs PHP, treat it as exposed to PHP2Shell (CVE-2026-109618 and CVE-2026-109619) until the PHP that serves it is confirmed fixed. A checker can see that PHP is present and sometimes a version banner. It cannot see a backport or a worker restart. Get the fixed build and restart time from your host or your server.

What can a PHP2Shell checker actually confirm?

Less than its result screen suggests. Public checkers use one of three methods, and each has a blind spot.

The second row is the checker's own wording. Aikido's page says its clean result does not prove PHP is patched, and that a banner version "may not account for vendor backports" (at our check on 24 October 2026). Its optional crash probes can exhaust memory and interrupt requests on the target, so run those only on servers you own, with permission, off peak.

Red's free scan is a lookup. It identifies the technologies your site serves, the way Wappalyzer does, then looks each version up in public vulnerability records. It can say a version is affected. It cannot say whether your setup is exposed, and it cannot see a vendor backport.

Why does the version number mislead?

Two traps, each documented by the vendors:

1. Backports keep the old number. Ubuntu's fixed PHP for 24.04 is package 8.3.6-0ubuntu0.24.04.13, and for 22.04 it is 8.1.2-1ubuntu2.28 (Canonical, 21 October). Both still announce an old PHP version (the backport version trap in full). CloudLinux says its backport builds stay below PHP.net's numbers, so a version scanner may flag them wrongly, and that most builds are checked by changelog and its native PHP 8.2 and 8.3 rebuilds by installed version.
2. A fixed package is not a restarted worker. Canonical says the application that uses the PHP interpreter would likely need to be restarted, and that restarting the apache2 daemon is required with mod_php. The PHP project's 21 October advisory says to restart every worker after setting session.upload_progress.enabled=0.

It also fails in the other direction. A banner can say 8.5.12 on a site where an unrelated PHP build handles a different path. A hidden banner says nothing either way.

Who is affected?

Any site served by PHP, which includes WordPress, WooCommerce, Magento, Shopware, Drupal, Joomla and Laravel. The bug is in the engine, so up-to-date application code does not help. mod_php is the highest-risk setup according to the PHP notice; the other server types are in scope too. Sites with no PHP (static, Node.js, Ruby, Python) are not affected by this bug. The wider picture is on the PHP2Shell page.

How do I get real proof that I'm patched?

If a host manages PHP for you

Send support this question and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP-FPM, CGI or Apache workers serving it have been restarted or replaced, and say whether I need to redeploy or change a setting.

Some hosts name evidence you can check yourself. Hostinger's status page said on 22 October (06:44 UTC) that for its managed hosting a Build Date of 21 October 2026 or later in hPanel's PHP Info means the site has the fix, and that some sites show 8.5.11 rather than 8.5.12 as expected (vendor-claimed, at our check on 24 October 2026). Hostinger's own page has the detail. Its notices cover Web, Agency and cPanel Hosting. Its 23 October update says VPS clients manage PHP themselves. A selector that shows only "8.4" proves nothing on its own. If you are on shared hosting, the questions to put to your host has the longer version. Per-host status is in the SiteGround page and the other host pages.

• Send the question above for each domain, not once per account.
• Ask for the answer in writing, with the build identifier.
• Redeploy anything on a managed platform that bundles its own PHP, if the host says so.
• Keep the reply with the date.

If you manage the server yourself

• Update PHP from your distribution or vendor. Check the installed package version against your vendor's fixed version. On cPanel and CloudLinux, CloudLinux (updated 23 October 2026) says most ea-php and alt-php builds name both CVE ids in rpm -q --changelog, but its native PHP 8.2 and 8.3 builds name none, so check for 8.2.35 or 8.3.36 or later with rpm -q php-cli. On Ubuntu, compare the installed package with Canonical's table.
• Debian: the tracker shows bookworm's php8.2 fixed in 8.2.35-1~deb12u1 and trixie's php8.4 in 8.4.27-1~deb13u1, both in the security suite. The main-suite builds (8.2.32-1~deb12u1, 8.4.24-1~deb13u1) are listed as vulnerable. Here the package version does match the upstream fixed release (Debian tracker, at our check on 24 October 2026).
• Restart every PHP worker or the web server, then note the time (how to restart PHP-FPM after the update).
• Rebuild and redeploy container images that bundle PHP.
• Check each virtual host if the server runs more than one PHP version.

If you cannot patch yet, the PHP project lists partial mitigations and says only an update is a complete solution (PHP notice).

Was anything exploited before I patched?

Attempts, yes. AWS reported a honeypot attempt dating to 17 October and more on 21 October, and says it is unclear whether the 21 October attempts would have succeeded on real systems. Its advice is to start any investigation from 17 October, review web server logs, and check application servers for unexpected processes or file changes. See is PHP2Shell being exploited for the dated record.

"Is the runtime fixed?" and "did anything get in before it was?" are two separate answers. A fix does not remove anything planted earlier. Signs your site was already exploited are on their own page, and the rest sit under the PHP2Shell topic.

What changed on 23 October?

On 23 October the PHP project posted an informational advisory on session upload progress. It suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, and says a full advisory for CVE-2026-115560 will be published with that release. The notice does not mention restarting workers; the 21 October advisory is where the PHP project says to restart every worker after setting it. CVE-2026-115560 is a different issue from the two PHP2Shell CVEs, so a build that fixes those two does not tell you about this one. No 8.5.13 was listed in the PHP 8 changelog at our check on 24 October 2026.

What is the bug, without the exploit?

Both are memory-safety problems in the PHP engine, reachable by an unauthenticated web request. The conditions are in the two advisories (CVE-2026-109618, CVE-2026-109619). We do not reproduce how to trigger them, and you do not need that to fix your site.