PHP2Shell Post-Mortem: Software Security Beyond Breach Notices

What happened, and how did it happen?

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, involved memory handling inside PHP.

In one, an out-of-memory condition could interrupt initialization, leaving invalid request data for cleanup routines to process. In the other, internal state could survive after the memory supporting it had been freed, allowing a later request to interact with stale state. These conditions could enable remote code execution. ^[1]

The weakness sat in the runtime supporting the application. Updating WordPress or its plugins, for example, would not establish that the underlying PHP installation had been corrected.

The timing complicated the response. Amazon reported an exploitation attempt against its monitoring infrastructure on October 17, before public disclosure, followed by additional attempts around the release. Those observations did not establish successful compromise of every targeted system, but they made the period before remediation relevant to investigation. ^[2]

Patching and investigating therefore answered different questions. One addressed whether the vulnerability remained. The other examined whether an attacker had already used it.

Classification comes before conclusions about notification

A vulnerability is a weakness that may be exploited. Its presence does not automatically establish a confidentiality incident. Exploitation may nevertheless result in unauthorized access, disclosure, alteration, service interruption or other consequences.

Determining what occurred requires understanding how the affected technology was used. PHP supporting a public website presents a different factual context from PHP supporting a document portal or an application connected to internal systems. Even a public website may hold credentials or provide access beyond the pages visitors see.

The relevant information, its sensitivity, the system’s connections and the evidence of activity all inform classification.

Contracts introduce additional distinctions. Depending on their wording, they may require notice of a material vulnerability, a potential security threat, suspected compromise, a confirmed security incident or a confidentiality breach. Assessment and patching obligations may apply independently of those notices.

An organization could therefore conclude that no confidentiality incident has been identified while still owing a vulnerability notice or remediation update.

Technical specialists establish the facts and their limitations. Breach counsel assesses those findings against contractual definitions, regulatory requirements and applicable deadlines. The analysis develops as evidence emerges; it cannot be reduced to a single question about whether personal information was stolen.

Familiar cybersecurity practices provide the legal facts

PHP2Shell illustrated the importance of maintaining technology inventories, mapping dependencies and information flows, and verifying that maintenance actually occurs.

As Jaspreet Kaur explains:

These are established cybersecurity disciplines. A critical disclosure exposes the consequences when they are incomplete.

A useful inventory connects an application to its dependencies, business owner, provider and maintenance arrangements. Information mapping identifies what it holds or can access. Contract mapping connects that environment to supplier obligations and commitments made to customers.

Without those connections, legal and security teams can each hold only part of the answer. Counsel may know a notification clause but lack the facts needed to apply it. Security specialists may understand the vulnerability without knowing that a customer agreement requires notice before compromise is confirmed.

The records also need to remain current as applications, providers and customer commitments change.

Due diligence should examine how software is maintained

Software procurement requires understanding how a supplier identifies, assesses and corrects vulnerabilities throughout the supported life of its product.

That inquiry should examine whether the supplier tracks relevant dependencies, determines affected versions, communicates customer applicability and provides corrections or interim protections. It should also establish which activities depend on the customer or another provider.

A supplier licensing software for deployment in the customer’s environment may release a correction while the customer controls installation. A SaaS provider may control both. A hosting provider may maintain PHP while an agency maintains the application above it.

Due diligence should make those boundaries visible before they become disputed during an incident. CISA’s Software Acquisition Guide similarly encourages buyers to examine supplier practices concerning third-party components and vulnerability management. ^[3]

Where an SBOM helps

A software bill of materials, or SBOM, identifies components included in a software product. It can support the assessment of newly disclosed vulnerabilities, provided its coverage, accuracy and relationship to the deployed version are understood. ^[4]

For relevant procurements, customers should consider requirements for SBOM delivery, updates and supplier explanations of whether disclosed vulnerabilities affect the product.

Coverage matters. A product SBOM may not identify a separately managed hosting runtime or the complete operating environment. Receiving one also does not establish exploitability or successful remediation. Its information needs to feed into dependency mapping, vulnerability assessment and patching processes.

Software security deserves dedicated contract provisions

Data protection schedules address important issues, but they do not comprehensively govern software security. A product can contain a serious vulnerability before any data incident occurs. The customer may need a correction regardless of whether personal information is involved.

A software agreement should address that lifecycle expressly and reflect the delivery model.

Definitions and deadlines need to work together. Awareness of a public advisory, confirmation that a product is affected and availability of a correction are different events. A provision should identify what starts the clock and what performance satisfies it.

Jaspreet explains why a fixed patching window is insufficient:

The framework should address assessment, interim protection, correction, deployment and validation. It should also provide a process for exceptions, including their justification, compensating measures and review dates.

Automation can improve discovery, deployment and reporting. Failed updates, excluded assets and unsupported systems still require oversight. The contract should account for the circumstances in which remediation requires customer action, compatibility testing or a separately purchased upgrade.

Make patching and vulnerability management verifiable

Contracts should distinguish the organization’s own security responsibilities from the evidence it expects suppliers to provide.

Within systems it controls and is authorized to assess, an organization can validate remediation through patch records, configuration checks and vulnerability assessments. Where a provider controls the environment, the customer should obtain evidence through agreed reporting, cooperation and audit mechanisms. Technical testing of provider infrastructure requires appropriate authorization and an agreed scope.

Jaspreet identifies several ways to support verification:

Who performs those activities depends on the service. For customer-hosted software, a supplier may demonstrate release of a correction while the customer verifies deployment. For a hosted service, the provider should supply evidence covering the affected service and the remediation performed.

Vulnerability management commitments and audit rights therefore need to be drafted together. A general right to audit may leave important questions unresolved: whether verification can occur outside an annual cycle, what evidence must be supplied, how quickly it must be delivered and how unresolved findings are handled.

Evidence should match the obligation. Releasing a correction, installing it and confirming effective deployment are distinct steps. Software versions may require interpretation where distributors backport fixes, and scan results must be read within their scope.

Both parties should retain records sufficient to demonstrate the activities for which they are responsible.

Map contractual events to a working communication process

A notification clause is difficult to perform if nobody knows which agreements apply or where notice must be sent.

A practical contract register should connect relevant security events to customer and supplier relationships. It should record:

• The event definition and knowledge trigger.
• The deadline and required notice content.
• The contractual recipient, address and delivery method.
• The internal person responsible for assessment, approval and delivery.
• Any continuing update, cooperation or remediation requirements.

An account-management email may not satisfy a provision requiring notice to a designated legal or security address. Contacts need maintenance, and teams need a process that remains usable outside ordinary business hours.

Regulatory, contractual and insurer communications should be identified separately. Their purposes, triggers and timing can differ.

A tabletop exercise can test the process using an uncertain scenario: a supplier reports a critical vulnerability, customer applicability remains under investigation and no compromise has been confirmed. Can security and legal identify the relevant obligations, establish what facts are missing and reach the correct recipients within the applicable periods?

This tests whether the organization can recognize and handle legally significant events beyond a classical data breach.

What the retrospective should change

PHP2Shell exposed the importance of connecting technical facts, contractual obligations and response decisions. A useful retrospective should turn any gaps encountered into changes to the way those functions work together.

Inventory gaps should inform dependency and information mapping. Unclear supplier answers should inform due diligence, reporting and verification rights. Delayed decisions should inform emergency authority. Uncertain notification pathways should lead to a maintained contract register and a tested communication process.

Those improvements depend on an integrated team that shares information in a form others can use. Security specialists need to know which contractual events require escalation. Counsel needs findings that explain affected systems, information and uncertainty. Procurement teams need feedback on which supplier commitments proved useful and which were missing or impractical.

A vCISO can establish ownership, priorities and reporting. A security team as a service can provide capacity to maintain inventories, coordinate remediation and validate completion. Procurement counsel connects those activities to supplier and customer commitments, while breach counsel assesses the legal consequences of emerging findings.

The processes become more useful when each informs the others. Technical findings support legal classification; legal requirements shape escalation and evidence collection; operational experience improves the next agreement. That coordination helps an organization manage the next vulnerability with clearer facts, workable rights and fewer avoidable delays.