Patch management: Why known vulnerabilities stay unresolved

Known to whom?

Researchers may have reported a flaw privately while businesses have no public advisory. Later, a vendor may release an update that the affected organization has not deployed. These situations require different responses.

Patch management connects decisions: which systems are affected, who can change them, which fix applies and whether it is running. Neither an open-CVE count nor a critical severity rating replaces an inventory linked to specific services.

A useful status identifies the next missing piece of evidence. “Vendor investigating”, “package approved” and “running instance not yet verified” tell an operator more than a single undifferentiated “in progress”.

PHP2Shell: What the timeline establishes

The PHP case illustrates several of these states. This selection separates earlier indications, private coordination and public releases. Calif's dates come from its retrospective account; the PHP Foundation also records the 11 August report.

There are 71 elapsed calendar days between Calif's first report on 11 August and the releases on 21 October, calculated by subtracting the dates and excluding the start day. That does not measure inactivity or 71 days of public knowledge. It also says nothing about when a particular hosting provider or customer activated the fix. [1] [2] [3] [4]

PHP2Shell: fixed versions and hosting checklist

Swipe or scroll sideways to read the table.

Why confirmation does not immediately produce an update

The PHP Foundation describes trade-offs involving compatibility, performance, new availability risks and extension changes. It also cites limited specialist capacity and a decision process it characterizes as a structural failure, with reforms under way. Following early disclosure, the release was brought forward by one day while distributors were still preparing installable packages.

This is not a general excuse for delay. An escalation should identify the missing step: reproduction, a technical decision, verification or package delivery. Each needs an owner and a review date. Calling everything “waiting for the patch” hides the bottleneck. [1]

What two studies show—and what they do not

Research on patching helps examine how work gets done. It does not provide a current worldwide rate of unprotected businesses. Publication year, collection period and the unit being counted therefore belong beside each number. [5] [6]

Swipe or scroll sideways to read the table.

Review the handovers in your own process

Our working structure starts with the system, not the update catalog. An advisory becomes actionable when it is connected to a service and a responsible role. If information is missing, applicability stays unresolved; it should not quietly become a low-risk finding.

Agree the target state, functional checks and recovery path next. If the fix cannot yet be deployed, a temporary measure needs a rationale and a review date. It should not become permanent by default. After the change, verify the actual instance, including any required restarts or newly deployed containers.

NIST treats patching as preventive maintenance. Its guidance calls for verifying installation and effectiveness and continuing to check, including after restoration or reset. A later restore can reintroduce an older state. [7]

Hosting, internal IT and the application: Who owns each part?

“It is in the cloud” does not identify an owner. As a specific example, AWS distinguishes its infrastructure from the customer-maintained guest operating system and installed applications on EC2. More abstracted services divide responsibilities differently. Do not transfer that example to your hosting contract without checking.

For each service, establish who evaluates vendor advisories, maintains the base system, tests the application and confirms completion. The business owner helps determine which functions must remain available. The technical operator identifies the change and its evidence. If a supplier owns the work, attach its specific response to the record; a general status page may leave the relevant questions unanswered. [8]

A blank register for your next real case

The patch register is Cyberkern's own working aid, not a protocol validated by the studies. One row connects a system, vendor advisory, owner, action and closure evidence. Use roles or teams rather than personal contact details. Do not include passwords, keys or confidential log contents.

The CSV contains column headings only. Document outstanding points as carefully as completed work. A planned installation is not ready to close. Reassess protection after a rollback; an earlier verification should not silently be treated as evidence of the current state.

Download the blank patch register as CSV

• System and applicability recorded with supporting evidence.
• Responsible technical role or supplier and decision path identified.
• Target package or configuration change and recovery path agreed.
• Temporary measure recorded with a deadline and next review.
• Active state and important business functions checked after the change.
• Closure evidence attached, or an unresolved item left open with its next action.

Better questions for the next status review

Ask which publicly reachable systems have unresolved applicability, which temporary measures are overdue for review and where evidence of active remediation is missing. Track time to ownership, activation and final verification separately, rather than relying on closed-ticket counts.

An external security assessment can identify visible systems and anomalies. Internal package state and possible earlier compromise require additional evidence. Updating does not replace incident investigation. For an initial enquiry, describe the services and your question; sensitive records can follow through an agreed channel.

Prioritize vulnerabilities by exposure and urgency

Map the external attack surface