A Patch Is Not Complete Until the Running Service Is Fixed

The CTO should require evidence from the running service before declaring a critical software vulnerability remediated. A patch announcement establishes that a fix exists. A deployment record establishes that someone attempted to apply it. Closing the operational exposure requires a verified connection between the affected business service, its software dependencies, and the code and configuration now handling requests.

That distinction matters when responsibility is divided among application teams, infrastructure operators, hosting companies, and product vendors. Each can complete its assigned task while a business service remains exposed through a component outside its immediate view. The CTO should own the technical completion standard, with the CISO assessing residual exposure and the business service owner deciding whether an interruption is acceptable. Those responsibilities need to meet in one service record.

What this week changed

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities that can permit unauthenticated remote code execution. PHP is a software runtime used to execute application code on web servers and in other products. The PHP Foundation’s account also describes the compatibility and engineering constraints involved in producing the fixes. Its explanation is a maintainer’s account, not an independent assessment of how widely systems were compromised.[1]

The UK National Cyber Security Centre advises organizations to discover PHP across their infrastructure, prioritize internet-facing systems, and monitor third-party products that bundle it. That last category matters to an executive: an organization can depend on affected software without a team describing its own application as a PHP application.[2]

Guidance also continued to change after the initial release. On October 23, PHP published an informational advisory about a further, configuration-dependent issue, CVE-2026-115560, to be handled in its regular release cycle. The project describes an unusual combination of application behavior and configuration; it does not say that every patched installation remains equally exposed.[3] CERT-EU updated its advisory that day.[4] Remediation therefore needs a dated scope: which vulnerability, which affected service, and which revision of the guidance was checked?

Start with the service that must keep working

Consider an illustrative customer portal. One team maintains its application, a platform team supplies the container image, and a hosting provider operates the production environment. An appliance elsewhere in the request path may also include the affected runtime. An application release can finish successfully while an old container remains active, a replacement instance still starts from an old image, or a bundled dependency waits for a vendor update.

This is a hypothetical operating example, not a reported PHP incident. It illustrates why a count of completed patch tickets can overstate completion. The unit that matters to the business is the service customers can reach. Its remediation record should identify the components that affect that service and the people who can change them. An inventory with no service owner leaves someone else to decide what the technical findings mean.

Begin with the most exposed services and expand the inventory as evidence arrives. Record uncertain dependencies explicitly. A team that has not established whether a vendor product contains the affected component should record that question as unresolved. Treating silence as a negative finding makes the dashboard look complete by hiding the work still required.

Use one record to connect action with evidence

We recommend a service remediation record with four fields: scope, fix route, running-state evidence, and exception. This is an operating recommendation derived from the incident’s dependency and verification problems; it is not a new standard or a requirement attributed to PHP.

Scope identifies the business service, affected component, applicable advisories, reachable environments, and accountable technical owner. Include production replicas and the artifacts used to create replacement instances. That prevents a healthy current instance from masking the ability to reintroduce a vulnerable one during scaling or recovery.

Fix route identifies how the supported correction reaches the service. A team building its own software can change an image and redeploy it. A customer of a managed platform may need a provider’s service-specific confirmation. A vendor appliance may require a product release rather than a direct runtime upgrade. The chosen route should preserve the support arrangement and identify the evidence needed to establish completion.

Running-state evidence records what is actually serving requests after the change. Depending on the system, that may include the deployed image digest, the vendor’s package or build identifier, confirmation that relevant workers were restarted, and an application health check. An image digest is a precise identifier for the deployed image. The evidence should cover the service’s relevant instances and carry a timestamp; a check on one administrative host is not proof about every production worker.

Exception records what remains unresolved, the protective action in place, who accepted the remaining business risk, and when the decision expires. An exception can explain a temporary operating decision without allowing it to disappear into a completed ticket. The record should distinguish a verified fix, a temporary reduction in exposure, and an unresolved condition.

Choose the update path with the supplier

Version numbers require interpretation. PHP’s current advisory distinguishes upstream releases, distribution packages, and vendor backports. A backport applies a security correction to an older software branch. Some vendors provide these fixes even when that branch no longer receives ordinary upstream updates.[3] A scanner’s version finding therefore needs to be reconciled with the applicable supplier advisory and installed package evidence.

For a managed service, ask the supplier to identify the affected product or service, the correction applied, its completion time, and any action still required from the customer. A general statement that the supplier has patched its infrastructure may leave an organization unable to determine whether its particular service is covered. The customer’s owner must resolve that gap before closing the record.

Avoid turning the executive article into a permanent list of supposedly safe releases. Engineers need the current project and supplier instructions for their actual deployment. Preserve those instructions, or their revision and retrieval time, with the remediation evidence so a later reviewer can understand what the team relied on.

Availability changes the decision, not the evidence

Taking a service offline can interrupt orders, access to information, or essential operations. Leaving it reachable can expose the organization to compromise. The appropriate decision depends on exposure, the available correction, credible protective measures, the consequence of interruption, and the organization’s ability to investigate suspicious activity.

NCSC’s guidance sets out escalation options when updating or applying temporary mitigations is not feasible, including considering taking the system offline. It also addresses assessing for compromise where immediate action has not been possible.[2] The executive action is to make that decision explicit with the service owner and security team. A business need for continued operation should result in a bounded, documented decision with a next review time.

A temporary measure must retain its limited description. A tested reduction in exposure is useful, but it does not support a claim that every affected component has been fixed. Likewise, remediation does not by itself establish that a system was never compromised. Keep the technical correction and any incident investigation linked while preserving their separate completion criteria.

Ask for a demonstration of closure

At the next operations review, select one exposed service and ask its owner to trace the evidence from advisory to running deployment. Include a supplier-managed component and the image or configuration that would be used to replace a failed instance. The demonstration should reveal whether the organization can prove completion or merely report activity.

Then fix the specific gap it exposes: missing dependency information, an unclear vendor obligation, deployment evidence that omits workers, or an exception with no expiry. A new dashboard is unnecessary if the existing service record can hold those facts and route unresolved decisions to the right owner.

A useful question for peers is: What evidence would persuade your organization that an affected business service is remediated, including its vendor dependencies and the instances that could be started tomorrow? The answer should be something the responsible team can produce and another person can verify.