PHP published fixes for CVE-2026-109618 and CVE-2026-109619 — together, php2shell — on 21 October 2026. Combined, they allow commands to be run on a server without prior authentication.
We have added two checks for them to ClickScan, the self-serve platform that runs alongside the work we do by hand. Both are free until 31 December 2026, and the instructions are on the ClickScan post.
What is worth a CISO's attention is not the checks themselves. It is the distinction they are built on, which applies to every automated check you will ever accept as evidence.
Passive and active, and why the difference is governance
PHP Runtime Check is passive. It establishes whether a server falls in the affected range using only what the server already makes public, so it needs no authorisation and can be run against any address.
PHP Runtime Audit is active. It reaches further and finds affected servers the passive check cannot see. It sends no payloads and writes nothing, but it is directed at a specific host rather than reading what is published to everyone — so it requires proof that the asset is yours.
Put plainly: the Check tells you what is visible from outside. The Audit tells you what could be seen.
That boundary is not a product convenience. It is the same line that separates reconnaissance from testing in any engagement, and it determines what you can authorise and what a third party may lawfully do to an asset you own.
If you are commissioning scanning — from us or anyone else — this is the question to ask. Which of these checks read published data, and which are directed at my hosts? A supplier who cannot draw that line clearly is a supplier whose scope you cannot write into a contract.
The result category most tools do not have
Here is the part that matters most for evidence.
If you run PHP from a distribution package — Debian, Ubuntu, RHEL — the version number can look vulnerable while the fix is already applied, because distributions backport patches without changing the version number.
So in that case we do not declare a vulnerability. We report that we cannot establish one, and point at the distribution's changelog.
That is a worse-looking result and a better one. Consider what the alternatives cost you:
- A tool that calls a backported package vulnerable generates a false positive your team spends a day disproving — and, worse, teaches them that findings from that tool can be ignored.
- A tool that treats silence as a pass generates a false negative, which is the failure nobody discovers until later.
A third category — could not determine — is what makes a report usable as evidence rather than as a sales document. It is the same rule we apply when a live spoofing test is refused for the wrong reason, and to anything a scan did not actually reach.
For a NIS 2 assessment under Article 21, as transposed by OUG nr. 155/2024, this is the difference between a vulnerability management process that produces defensible records and one that produces noise. An assessor reading "could not determine, see distribution changelog, verified 24 October" is looking at a functioning process. An assessor reading a list of findings half of which were wrong is looking at a tool somebody bought.
A version number is an indicator, not a determination
This episode is the second in a week to make the same point from a different direction.
Node2Shell, the Brotli flaw reported everywhere as a Node.js vulnerability, defeats version-based detection in both directions: some projects are already fixed while still reporting an old version number, and others report a number that looks current and are not. php2shell defeats it the other way, where distribution backports make a vulnerable-looking version safe.
The lesson for a vulnerability management programme: build the process so a version match opens a question rather than closing one, and so "cannot establish" is a recordable outcome with an owner and a deadline rather than a gap somebody quietly drops.
Where a check ends
An external check answers one question well: is this exposure visible from outside, right now. That is genuinely valuable, it is cheap, and it can run continuously, which is why we built the platform.
It does not answer what an attacker reaches once they are inside, whether one recovered credential opens four systems, or whether the segmentation on your diagram exists on your network. Nor does it tell you whether secrets already leaked before you patched — for php2shell that is a credential rotation question, not a scanning one.
Those questions need a person. An internal penetration test answers the reach question directly, an external attack surface review builds the inventory the checks then monitor, and an audit and compliance review establishes what evidence your assessor will actually accept.
The automated half and the expert half are not competitors. The scan tells you what changed since last week. The test tells you what it means.
Running the checks
Sign in at app.clickscan.ai with your email address — no registration form, a one-time code by email. Add the asset as a domain, URL or IP, prove ownership for the active checks, and start the scan. Free until 31 December 2026.
Sources: PHP 21 October 2026 release announcement · CVE-2026-109618 record · CVE-2026-109619 record
Distribution package status for php2shell was accurate at the time of writing and continues to change; verify against your own vendor's advisory rather than against a version number.
This article is general information, not legal or regulatory advice.