On this page
A scan that finds no issues does not prove your site is patched. A free vulnerability scanner reads what your site shows to visitors, usually a version banner, and compares it to known flaws. Aikido's checker says a version in X-Powered-By may not account for vendor backports, and CloudLinux says to restart PHP after installing fixed packages. Ask your host for the build identifier and restart time.
| Fact | Detail | Source |
|---|---|---|
| What these two checkers see | Sucuri: what a browser can access, not anything server-side. Aikido: response headers on the PHP path you give it, plus optional active probes | Sucuri SiteCheck, Aikido |
| Worked example | PHP2Shell, CVE-2026-109618 and CVE-2026-109619, disclosed 21 October 2026 | PHP advisory |
| Fixed PHP releases | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | PHP advisory |
| Older branches | PHP 8.1 and older get no updates from the PHP project. Some distributions and LTS vendors backport fixes | PHP advisory |
| Fix shipped as a package build | Debian bookworm: 8.2.35-1~deb12u1. Ubuntu 22.04: 8.1.2-1ubuntu2.28 | Debian, Canonical |
| Workers must restart | CloudLinux says to restart PHP-FPM or the web server after installing | CloudLinux |
| CISA KEV | CISA added CVE-2026-109618 and CVE-2026-109619 to its catalog on 26 October 2026 | CISA |
| Checked | 24 October 2026; CISA status re-checked 28 October 2026 | this page |
What does a free scanner actually see?
Only what is visible from outside. At our check on 24 October 2026, php2shellchecker.com said its own checker sends one normal GET request to the homepage and reads the response headers. At the same check, Sucuri's SiteCheck said on its own page that remote scanners have limited access, that it only sees what a browser can access, and that it will not detect anything on the server side.
Red's free scan identifies the technologies your site serves, then looks each version up in public vulnerability records. It is a lookup: it can say a version is affected, not whether your setup is exposed.
Why can "no issues found" be wrong?
Three things sit between a banner and a patched server. PHP2Shell shows all three.
- The version is hidden. On WordPress, updating WordPress does not update PHP, so a clean plugin report says nothing here. Many servers do not report PHP at all. At our check on 24 October 2026, php2shellchecker.com said most servers turn off
expose_php, so the version is not in the headers, and that this does not mean the site is patched. - A fix keeps the old number. The PHP project says 8.1 and older get no updates from it, and that some distributions and LTS vendors provide backported fixes. Canonical lists Ubuntu 22.04 as fixed in 8.1.2-1ubuntu2.28. The upstream line for 8.1 has no fixed release, so the package name is the evidence, not the version.
- The checker asked the wrong thing. At our check on 24 October 2026, Aikido's checker stated that a clean result does not prove PHP is patched. It listed other causes of no crash signal: an elevated memory limit, a rejected request, or an untested path. It also said a version in the
X-Powered-Byheader is a hint and may not account for vendor backports.
The error runs both ways, which matters for agencies answering clients. If a compliance scan flagged an old version string on a patched server, disputing a backport false positive has its own evidence checklist.
| What the scan shows | What it may really mean | What settles it |
|---|---|---|
| Old PHP version in a header | Could be a vendor build that already has the fix | The vendor's package-specific check, such as a changelog naming the CVE or a build version (CloudLinux gives different checks per package) |
| No version, no finding | Could be unpatched and just quiet | Package or build identifier from the server or host (Aikido: a clean result does not prove PHP is patched) |
| A fixed package version on the server | A package check reads installed package metadata, not running workers. CloudLinux says to restart so the new build is loaded | Restart or redeploy time after the install |
A scan can also be wrong in the other direction, so a flag is a reason to ask, not a verdict.
How do I get proof that I am patched?
The proof sits with whoever runs the server. Installing a fixed package is step one. CloudLinux says to restart PHP-FPM or the web server afterwards so the new build is loaded.
What do I ask if a host manages PHP for me?
Send support this and keep the reply:
For [your domain], which PHP package or build is serving web requests, and what shows that it contains the fixes for CVE-2026-109618 and CVE-2026-109619? When were all the workers that serve it last restarted or replaced?
- Reply names a package or build identifier, not only a version branch
- Reply gives a restart or redeploy time after the install
- Reply is about your domain, not "our fleet"
- You saved the reply with its date
What do I check if I manage the server myself?
- Verify the package the way your vendor says. Debian's tracker shows the package versions it fixed. CloudLinux says some of its rebased native PHP builds have changelogs that name no CVE ids, and gives per-package checks in its updates through 23 October
- Restart PHP-FPM or the web server afterwards, as CloudLinux says
The full PHP2Shell steps are on the PHP2Shell page.
Am I affected? What a scan result means
Am I affected? Where you stand right now
A passive check from outside can give you the first two states. Only evidence from the server or the host gives you the third.
- Detected The scan sees a version below the fixed release for its branch. Treat it as exposed until the host or server says otherwise. It could still be a vendor build, so ask for the package identifier before you panic and before you relax.
- Unknown The version is hidden, or is one a backport could explain, or no finding came back. This is the common case. A result with no findings lands here, not in a better state. Ask the host or check the server.
- Confirmed by owner evidence You hold the package or build identifier naming the CVE, and a restart or redeploy time after it. That is proof for that runtime. It says nothing yet about whether anything got in before the fix.
No scan, ours included, moves you from "unknown" to "confirmed".
So what is a scan for?
Red's free scan checks for .git, .env, backups and open directory listings, API keys and tokens in shipped bundles, TLS protocols and ciphers, DNS records pointing at services you no longer own, and panels, consoles and debug pages left online. It is the wrong tool for the question "did my host install the fix and restart", because that answer is not on the public side of the server.
Use a scan to see what you expose. Use your host or server to prove what you run. If you are new to scanning, how to scan your own site legally covers permission and reading results, whether you need a scan or a pentest helps you choose, and the other evergreen guides go further. For what the PHP bug means for small sites, see why one PHP bug mattered.
Was anything exploited, and how would I know?
A passive version lookup cannot tell you that. Some scans do look for evidence: Sucuri's SiteCheck says it detects malicious code and infected file locations in your external website source code, and also says it will not detect anything on the server side. For PHP2Shell, CISA added both CVEs to its catalog of known exploited vulnerabilities on 26 October 2026, so exploitation in the wild is on record. That says nothing about your site. Only the server or your host can show whether anything got in. The PHP advisory has the fixed releases, and the PHP2Shell page has the rest.
Questions people ask
Does a scan with no findings mean my site is okay?
No. A scan from outside sees what your site shows to any visitor. It cannot see the packages installed on the server or whether the PHP workers were restarted after an update. A result with no findings is one input, and the server or your host holds the proof.
The checker says my PHP version is old, but my host says it is patched. Who is right?
Both can be right. Distributions and hosts ship fixes as new package builds and keep the old version number. Ask the host for the package or build identifier that names the CVE, and for the restart time.
My PHP version is hidden. Does that mean I am fine?
No. A hidden version means the checker cannot tell. One checker operator says on its own page that a hidden version is not a sign you are patched. Treat it as unknown until the server or host gives you evidence.
Is a free vulnerability scanner accurate?
It reads what the site shows from outside and is not a measure of the server behind it. Sucuri's SiteCheck says remote scanners have limited access and see only what is visible at the browser level. Read each tool's own page for what it checks, and treat the result as a lead, not a verdict.
Can a scan tell me whether I was hacked?
A passive version lookup cannot. Looking for compromise means checking the server for unexpected files, scheduled tasks and accounts, or asking your host to do it. A scan of the public pages only sees what is visible to visitors.
Sources
- PHP security advisory, 21 October 2026 (php.net)Fixed releases, scope, and the statement that PHP 8.1 and older get no updates from the project while some vendors backport.
- Debian security tracker: CVE-2026-109618Shows fixes shipped as Debian package versions such as 8.2.35-1~deb12u1.
- Canonical: PHP2Shell vulnerability fixes available (Ubuntu blog)Lists Ubuntu 22.04 as fixed in 8.1.2-1ubuntu2.28.
- CloudLinux: CVE-2026-109618 and CVE-2026-109619 (blog, updated 23 October 2026)Says to restart PHP-FPM or the web server after installing the fixed packages.
- Aikido PHP2Shell checker (the operator's own page)States its own limits on what a result shows.
- php2shellchecker.com (the operator's own page)
- Sucuri SiteCheck (the operator's own page)
- CISA Known Exploited Vulnerabilities catalog
Facts on this page are dated and point at the primary source next to them. If a vendor status changes after the date shown, the vendor's page wins; tell us at support@run.cloud and we will update it.