A vulnerability disclosure demands action. It also demands precision. Historic verification information can help identify where to look. It cannot tell the whole story about software running today.
When a critical vulnerability is disclosed, leaders need answers quickly. Which applications might be relevant? Who is responsible for assessing them? What has changed since the last review?
PHP2Shell brings these questions into focus. But speed should not turn a useful indicator into a claim the evidence cannot support.
PHP2Shell refers to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They can allow an attacker to execute code without authentication. PHP published fixed releases on 21 October 2026. The UK National Cyber Security Centre urged organisations to identify PHP installations and take immediate action.
The issue is not confined to applications visibly labelled as PHP products. PHP can be embedded within other software. CISA’s guidance therefore calls for an inventory across the organisation, with priority given to systems accessible from the internet.
The first task is assessment and remediation using current official and supplier guidance. Verification evidence can inform that work.
At Escode, our response included reviewing material from previous detailed verification work to identify indicators of potential relevance. Such a review starts with a specific question: what did the material examined at that time show?
A report may record PHP dependencies, version information or details about how an application was built and operated. Those observations can help focus discussions with a supplier.
But their date matters. So does their scope.
A finding about an earlier deposit is not a finding about today’s deployment. The supplier may have changed the runtime, updated components or altered the hosting arrangement. Equally, the latest deposit may not yet reflect those changes.
Our position is straightforward: use historic evidence to identify questions. Do not present it as proof of current exposure.
What was deposited?
This concerns the software and supporting material held in escrow, including its version and deposit date.
What was verified?
This concerns the checks performed and the evidence available within the agreed scope. A report should be read against those boundaries.
What is running now?
This concerns the current runtime, configuration, infrastructure and deployed software. Historic deposit evidence alone cannot answer it.
PHP2Shell illustrates why that distinction matters. Official guidance identifies risk across PHP installations serving web requests, including Apache with mod_php and PHP FPM. Reviewing application source code is therefore not a substitute for checking the PHP runtime actually deployed.
For a risk committee, these distinctions prevent false certainty. For technical teams, they help define the next check.
Where software has changed, repeat verification can provide evidence about updated deposited material.
The scope must match the question. That might involve examining dependency information, reviewing installation documentation or assessing whether supplied materials support an agreed build process.
The resulting report should state what was examined, which checks were completed, what was found and what remains uncertain.
That is more useful than a broad statement that “the issue is resolved”. Any conclusion should identify the material and conditions it applies to.
A source review alone cannot demonstrate that an updated runtime has been deployed. Nor does repeat verification investigate production logs or determine whether exploitation has occurred.
“Are we affected?” is understandable. It is also a question that needs context.
We recommend asking:
These questions give technical, procurement and risk teams a shared basis for discussion. They also give vendors room to explain work already completed, rather than repeat an assessment without reason.
Our view is that verification is most useful when it helps people decide what to do next.
That requires clarity about both the finding and its limits. Historic evidence can indicate relevance. Updated verification can examine current deposited material. Neither should be presented as a conclusion about a live environment without the necessary assessment.
The practical test is simple: do you know what the evidence shows, when it was gathered and what still needs checking?
Build a stronger software resilience strategy today. Book a demo to see our platform in action, or talk to our sales team for pricing details and solutions guidance.
