Since the advance notice on 20 October, PHP2Shell has been on many IT managers’ review lists. On 21 October 2026, the PHP project released security updates for two critical vulnerabilities. For DAXS, this meant interpreting the reports, identifying potentially affected services and prioritising measures according to actual exposure. What matters is what is effectively running on each system, beyond the completion of an update task.
What was published
The vulnerabilities CVE-2026-109618 and CVE-2026-109619 can allow remote code execution without prior authentication. The advance notice rates both CVSS v4.0 9.2. This critical rating calls for prompt assessment; it does not establish which particular customer installation has been successfully attacked.
The PHP project lists the fixed releases as 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution-maintained packages may receive security fixes as backports. A lower displayed base version therefore does not, by itself, prove either missing protection or a successful fix. The exact package, vendor advisory and runtime actually in use are decisive.
The advisories cover different web server integrations. PHP highlights the risk for Apache with mod_php; this does not provide blanket clearance for PHP-FPM or other deployment methods. Components, extensions and settings are assessed separately for each environment. A product name in an inventory is insufficient.
Our first question: where is PHP actually running?
We brought the available reports together with existing knowledge of the systems. The inventory includes public websites, management interfaces, additional applications and services that bundle PHP. Prioritisation considers external reachability, the service’s purpose and who is responsible for updating it. Unclear entries receive a concrete follow-up task.
We distinguish an installed package from the active web service. Several PHP versions may coexist. Updating the command-line program successfully does not establish which runtime a particular web server process uses. After a change, the affected services and their effective settings must therefore be checked in a traceable way. A publicly accessible diagnostic page is not a permanent solution for this.
The inventory must also include less conspicuous systems. Web management may be a secondary function of a device while still creating an additional attack surface. Whether PHP is used there at all and whether a fix is required remains a technical question. We do not infer exposure merely from the existence of a web interface.
Update, verify effective operation and record open points
The practical process starts with inventory and assessment. Available security updates are then applied according to priority. Checks include the package version, required restarts, effective configuration and necessary application functions. Those responsible must be able to see which service has been checked and where a vendor response, suitable package or functional acceptance is still outstanding.
If a specialist service cannot be updated immediately, we first review which direct public access is actually needed. Unnecessary internet access can be removed temporarily. Legitimate internal use may be retained through suitable isolated access paths. This is a deliberately limited measure whose effects and side effects must be checked; it does not automatically make the underlying software free of vulnerabilities.
A task is not complete merely because an update has started. It needs a traceable conclusion or a named open point with an owner. If access is restricted, the remaining reachability is also checked. If a fix is installed, the service actually in use is verified afterwards. Both belong in maintained operational documentation.
The verification record also includes the software’s supply channel. For an operating-system-maintained installation, the distribution’s advisory is compared with the installed package. For a bundled runtime, the responsible product vendor’s information matters. This helps prevent a version number alone from being misinterpreted. If the evidence is insufficient, the point remains open and receives a next review step. A green status without a verifiable basis would be misleading.
What WAFs, proxies, firewalls and separate networks provide
WAFs, reverse proxies, firewalls and VLANs are already among the tools used to limit access and data paths. A firewall controls permitted connections, a proxy consolidates defined web access, and separate networks help constrain allowed communication. These are valuable functions, but they do not resolve every vulnerability within a PHP process.
In particular, PHP2Shell must not be presented as fully addressed by an upstream WAF or one running inside the application. The PHP project describes updating as the complete solution; temporary restrictions cover only particular attack paths. We therefore consider these layers alongside patch status and check whether another route could bypass the intended access restriction.
Isolated tests and AI support human assessment
We also used our own isolated test environments for technical assessment. Claude and OpenAI Codex supported research and the preparation of those environments. Professional judgement and reliable technical sources were decisive. A plausible AI answer replaces neither evidence of the installed version nor verification of an effective setting.
Observation remains necessary after updating. Unusual errors, unexpected processes or unusual connections are assessed against normal system behaviour. An installed patch does not retrospectively prove that nothing happened beforehand. Equally, a single unusual log entry is not reliable evidence of a successful attack.
Put public reports in context
The University of Vienna’s report on restrictions to central IT services illustrates how disruptive precautionary measures can be. Its updated notice reports that most services are available again. Such public information helps explain the situation; it says nothing about the state of another organisation or a particular DAXS-supported environment.
Vendor advisories must also match the service concerned. A vendor may distinguish its products from a hosted portal it operates. A statement about one product cannot be extended to arbitrary third-party applications. For OPNsense, FreePBX, Sophos or an individual gateway, the exact version, bundled components, vendor guidance and actual access situation therefore matter.
Our conclusion: preparation makes the response verifiable
A useful inventory, clear responsibilities and prepared update paths make responding to critical advisories easier. We publish neither an unsupported patch percentage nor blanket clearance for every system. Traceable individual checks and continued handling of open cases are decisive. On Friday, we will look at how AI can help bring easily overlooked devices into this kind of review list.
