A critical software vulnerability can reach an executive through several channels at once: a hosting notice, a security newsletter, an MSP email and a message from a customer. Each may describe the issue accurately while leaving the most important business questions unanswered.
Are our services affected? Who is responsible? What could happen if we wait? What evidence will tell us the response is complete?
PHP2Shell is a useful and urgent test of whether a business can answer those questions. Leaders should initiate a focused exposure and response review now, with enough evidence to make decisions and enough discipline to avoid turning a technical alert into unsupported claims about a breach.
Understand the issue without becoming the technician
PHP is a runtime that executes application code on a server. It is used by WordPress and other web applications. The PHP project has released fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can enable remote code execution in affected deployments. That means an attacker may be able to run unauthorized instructions on a server. The exact exposure depends on the deployment and the applicable advisory. PHP advisory one and PHP advisory two.
As of October 22, the first fixed releases in supported PHP branches are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Vendors may supply equivalent backported patches. The technical team should use current vendor guidance for the installed build rather than treat this list as a complete operating procedure. PHP release announcements.
WordPress, theme and plugin updates address different software layers. Their completion does not prove the PHP runtime has been remediated. Automattic explains the distinction.
Begin with the services that matter to the business
Ask the internal technology owner to coordinate an inventory with the people who operate websites and applications. Include marketing agencies, developers, hosting providers and MSPs where relevant. Do not assume one provider sees everything.
For each service, record its business purpose, operational owner, technical provider and current assessment. Include the main website, subdomains, customer-facing applications and older or temporary environments that remain accessible. A retired project still online can remain part of the exposure.
Connect this list to consequences. Could disruption prevent orders, delay customer onboarding or interrupt a contractual service? Could the application access customer records or credentials for another system? What would the business do while the service was unavailable?
These are questions for the business and technical teams together. A technical inventory identifies software; the operating team explains why a particular interruption would matter.
Look beyond your own servers when a supplier’s service is essential to delivery. A shared software component can create dependencies across businesses that otherwise seem unrelated. Ask critical providers how they are maintaining continuity, and consider whether customers could need additional support if their own services are disrupted. This is a reason to examine interdependence, not a basis for predicting an economy-wide outage.
Keep unknowns visible. “Not yet assessed” is an acceptable initial answer when it includes an accountable owner and a prompt next step. It becomes a governance problem when it quietly turns into “not affected.”
Establish responsibility before providers pass the issue around
Name one internal executive or technology leader to coordinate the response. This person does not need to install the patch. They do need authority to obtain answers and escalate a gap.
Ask each provider to identify the services it covers, whether those services are affected, the remediation performed and the evidence available. Clarify what the provider does not manage. The business may have bought hosting, application maintenance and security monitoring from different parties, with no single contract covering the whole response.
A general assurance such as “our infrastructure has been updated” can be accurate and still leave a separately managed server outside its scope.
Have the coordinator reconcile those boundaries. If a provider cannot answer, record the uncertainty and decide whether temporary restrictions are warranted while the team investigates. Do not leave an exposed business service operating indefinitely because responsibility is being debated. For a broader framework, see our guide to independent MSP oversight.
Ask for evidence from the running environment
The technical owner should establish that the relevant fix is active, using the software vendor’s or hosting provider’s verification method. Where service restarts are required, confirm they occurred. Follow with checks that the business service still functions as intended.
Avoid treating a version string as a complete answer. Hostinger, for example, says its managed-hosting patches may preserve the displayed PHP version. Its published check uses a PHP Info Build Date of October 21, 2026 or later. Hostinger also distinguishes managed hosting from self-managed VPS responsibilities. That is a provider-specific verification rule, not a universal rule for every PHP installation. Hostinger’s guidance.
For a different provider, ask for that provider’s equivalent evidence. If a scanner and provider report disagree, the technical team should reconcile the difference using the actual build and patch evidence. Neither an automated alert nor a broad reassurance should end the investigation on its own.
Leaders should receive the conclusion and its basis. They should not have to interpret configuration files to find out whether an important service remains exposed.
Make continuity decisions deliberately
Remediation may require a restart, a maintenance period or a temporary restriction. The COO should ensure that the team understands the business impact and can communicate an operational workaround if needed.
Ask for the proposed change, the expected effect on customers, the validation plan and the recovery path if the change fails. For a service that cannot be patched promptly, ask what protective measures are available and what risk remains after applying them. Temporary measures need a named owner and an expiry or review time.
The CEO should resolve conflicts over resources or disruption when they exceed delegated authority. Deferring action is itself a business decision. Record who accepted the remaining risk, why, for how long and what would trigger reconsideration.
A critical issue should not wait for the next routine committee meeting simply because the normal reporting calendar is slower than the exposure.
Keep remediation and incident assessment distinct
Patching an affected service reduces the known vulnerability. It does not prove that the service was never compromised.
Ask the security lead or appropriate provider whether available logs and other evidence indicate suspicious activity, which environments were reviewed and what visibility is missing. An absence of alerts is less informative when monitoring or log retention was limited.
If there are signs of compromise, activate the incident response process. Preserve relevant evidence and involve qualified responders. Decisions about notification, contractual obligations and legal exposure should be made with the appropriate advisors based on the facts, not assumed from the vulnerability announcement alone.
Likewise, the existence of a vulnerable version is not proof of a breach. Leadership communications should distinguish confirmed facts, working assessments and unanswered questions.
Require a concise closure record
For this response, I would expect management to maintain a short record containing:
- The business services assessed and any exclusions from the review.
- The affected or unknown systems, their owners and the actions taken.
- Evidence that the fix is active, with the verification date and responsible reviewer.
- Results of essential functional checks and any customer impact.
- The scope and outcome of the compromise assessment, including visibility gaps.
- Remaining exceptions, the person accepting them and the next review time.
Set the next reporting time at the start of the response. An initial update can acknowledge uncertainty while still showing that the work is controlled. Subsequent updates should explain what changed and which decisions remain.
Boards should use that information to oversee material risks and management’s response. They should not become the incident command team. Management remains responsible for execution and for escalating matters that require board attention under the organization’s governance arrangements.
Use this event to improve the next response
After urgent work is complete, examine what made the answer difficult. Were important applications missing from the inventory? Did provider responsibilities overlap or leave gaps? Did management lack evidence to challenge a reassuring claim?
Address those specific weaknesses. A maintained service inventory, clear provider responsibilities and an agreed standard for evidence will be useful beyond this vulnerability.
For leaders, the practical outcome is straightforward: know which business services are exposed, give someone authority to resolve the exposure and require a supported explanation before considering the work closed.