Abstract
The October 2026 PHP2Shell incident exposed a significant weakness in modern cybersecurity, raising concerns that extend well beyond the technical risks associated with cyber software. Our article raises a pertinent question, which is, how should an organisation determine whether a reportable data breach has occurred when the forensic evidence needed to establish the facts is incomplete, inconclusive, or entirely unavailable? This question is worth addressing especially where sophisticated attacks can exploit weaknesses without leaving clear or readily detectable traces. The PHP2Shell incident highlights the friction between technical uncertainty and legal accountability, particularly as regulators demand timely, accurate, and evidence-based reporting of cybersecurity incidents across different jurisdictions worldwide.
The PHP2SHELL cybersecurity problem
On 21 October 2026, two critical security vulnerabilities in PHP sent an urgent warning across the technology industry. The flaws, identified as CVE-2026-109618 and CVE-2026-109619, could potentially allow attackers to execute malicious code remotely, without authentication, or access sensitive information stored in server memory.
The vulnerabilities were serious, and both received a severity rating of 9.2 under the Common Vulnerability Scoring System, and the PHP development team urged users to install security updates immediately.
The technical response was clear for organisations operating PHP-based applications; vulnerable systems needed to be identified, patched and investigated.
However, the legal position was less straightforward, which happens to be the subject of this article.
Did the discovery of these vulnerabilities mean that organisations had suffered a data breach? Were they legally required to notify regulators? Could businesses “potentially” face liability simply because they had operated affected software These questions highlight an important distinction that is frequently overlooked in cybersecurity discussions.
Our position is that a critical vulnerability is not automatically a confirmed data breach, but the absence of a confirmed breach does not necessarily establish that an organisation’s systems were never compromised.
The difficulty balancing these two possibilities lies in understanding the difference between what is technically possible, what can be established through forensic investigation, and what the law requires organisations to report.
We believe the PHP2Shell incident exposes a deeper problem in modern cybersecurity governance. Organisations are increasingly expected to make rapid legal decisions based on technical evidence that may be incomplete, difficult to interpret or unavailable.
We will address these issues below.
What PHP2Shell actually exposed
PHP is one of the foundational technologies behind modern web applications.1 It supports content management systems, online businesses, customer portals and numerous services that people rely on daily.
The October 2026 vulnerabilities were particularly concerning because they affected PHP’s underlying runtime environment.
According to the PHP project’s official security advisory, CVE-2026-109618 concerned memory corruption during out-of-memory error handling. CVE-2026-109619 involved internal references that could continue pointing to memory after that memory had been freed. Both flaws could potentially allow attackers to manipulate the PHP runtime in ways that developers had never intended.
The vulnerabilities were not simply oversights in individual websites, but rather they concerned the software environment on which those websites depended.
It is important to note that organisation could have implemented secure application code, authentication controls and ordinary vulnerability testing while remaining exposed through the underlying PHP installation.2
The PHP project identified particular risks involving Apache’s mod_php integration, where a demonstrated attack could occur before application code began executing. Other PHP environments were also affected.
Security updates were released in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Nonetheless, the discovery of a vulnerable installation does not establish that an attacker successfully exploited it.
Let us consider some possibilities:
A business running an affected version may have been exposed to serious risk without experiencing any unauthorised access.
Another organisation may have experienced repeated exploitation attempts without those attempts succeeding.
A third organisation may have suffered a successful compromise that resulted in unauthorised access to personal information.
Although the underlying vulnerability is identical, the legal consequences may be substantially different.
That is why the first responsibility in any incident investigation is to establish what actually happened.
Vulnerability, compromise and data breach require different legal enquiries
Cybersecurity incidents often unfold faster than organisations can accurately describe them. During the earliest stages of an investigation, words such as vulnerability, attack, intrusion and breach are sometimes used interchangeably.
They should not be.
A vulnerability is a weakness that could be exploited. An attempted attack is evidence that someone tried to exploit a weakness. A successful compromise indicates that an attacker obtained unauthorised access or otherwise affected a system’s security. A personal data breach involves a security incident that compromises the confidentiality, integrity or availability of personal information.3
We need to distinguish them because reporting obligations are generally tied to defined events and consequences, not simply the existence of dangerous software.
For now, let us consider a hypothetical financial services company that discovers it has been operating an affected PHP version. Its security team immediately installs the relevant update. At this stage, the company knows that its systems were vulnerable. It does not necessarily know that an intrusion occurred.
Suppose investigators subsequently identify suspicious requests directed at the affected servers. That evidence may justify a more detailed investigation. However, suspicious requests alone do not establish successful exploitation.
Now imagine that investigators discover evidence of unauthorised code execution and access to authentication credentials. The position changes immediately because the organisation must examine, e.g., what those credentials permitted, whether personal information was accessed and what consequences may follow.
Importantly, personal data breaches are not limited to stolen databases.
Under Article 4(12) of the EU General Data Protection Regulation (GDPR), a breach can involve unauthorised access, disclosure, alteration, loss, destruction or unavailability of personal data.
An attacker does not necessarily need to download a customer database for a personal data breach to occur. The key question is what happened to the information and whether the relevant legal definition has been satisfied.4
An academic study examined more than 12,000 cyber events and distinguished data breaches from broader security incidents and privacy violations.5
A technical security incident may create serious operational consequences without involving personal data. Conversely, an unauthorised disclosure of personal information may constitute a data breach even where no sophisticated cyberattack occurred.
This legal classification must follow the evidence, rather than the severity of the vulnerability alone.
The most difficult problem is when the evidence cannot tell the whole story
The PHP2Shell incident raises an unusually important cyber-forensic concern.
Some of the exploitation techniques involved internal PHP operations that could occur before application-level security controls or logging mechanisms became active.
Others concerned memory management and the handling of information across requests.
This creates a difficult investigative problem.
Organisations frequently depend on application logs, authentication records, database activity and network monitoring to reconstruct suspected attacks.6 Be that as it may, an application cannot ordinarily record an event that occurs before its own logging mechanisms begin operating.
Similarly, accessing information directly from process memory may not produce the same evidence as downloading records through an application or database.
Such activity is not necessarily invisible. Web server logs, network telemetry, endpoint monitoring and other forensic records may still reveal suspicious behaviour.
Nevertheless, an organisation cannot assume that the absence of suspicious application logs establishes the absence of exploitation.
This is where we believe PHP2Shell introduces an important new dimension to cybersecurity law.
An organisation’s ability to establish that no breach occurred depends partly on whether its systems were capable of detecting the relevant attack.
A company might state that investigators found no evidence of unauthorised access.
That statement may be accurate, but its meaning changes if investigators later discover that relevant logs were never collected, critical records were overwritten or the monitoring system could not observe the affected part of the PHP runtime.
The company may have found no evidence because the available evidence was insufficient.
There is a significant difference between establishing that an event did not occur and being unable to establish whether it occurred.
Forensic research supports this concern.
In a recent finding, the authors examined the quality of information generated during incident investigations. Their research identified challenges in the collection and quality of incident-response data, demonstrating why the information available after an incident may be insufficient for reliable analysis.
PHP2Shell makes that problem particularly relevant.
Where exploitation may occur outside ordinary application visibility, the quality of monitoring becomes inseparable from the reliability of legal conclusions.
We would describe this as the forensic visibility gap: the distance between what an attacker may have done and what an organisation’s systems are capable of proving.
A European court has already confronted part of this problem
A particularly relevant judicial decision is VB v Natsionalna agentsia za prihodite, Case C-340/21, decided by the Court of Justice of the European Union on 14 December 2023.7
The case arose from a major cyberattack against a EU member state National Revenue Agency.
In July 2019, personal information relating to millions of individuals was unlawfully accessed and published online.
Affected individuals brought proceedings seeking compensation for the anxiety and fear that their information could be misused.
One important question concerned whether the fact that hackers had successfully accessed personal information automatically proved that the agency’s security measures were inadequate.
The Court held that it did not.
A successful cyberattack does not, by itself, establish that an organisation failed to implement appropriate technical and organisational security measures under the GDPR.
However, the Court also made clear that, in proceedings seeking compensation under article 82, the data controller bears the burden of demonstrating that its security measures were appropriate.
The Court further recognised that a genuine, well-founded fear of future misuse of personal information can constitute non-material damage.
The judgment therefore draws an important distinction between the occurrence of a breach, the adequacy of an organisation’s security measures and the harm suffered by affected individuals.
These issues appear to be connected, but they are not identical.
Regarding the PHP2Shell incident, the implication as significant and we should recognise it as such.
Even where a breach is established, liability does not necessarily arise simply because hackers succeeded. The relevant security standards, circumstances, causation and applicable legal requirements still require examination.
Equally, an organisation cannot rely solely on the involvement of cyber criminals to escape responsibility. It must be able to demonstrate the reasonableness of its security arrangements.
When does the legal reporting clock begin?
Perhaps the greatest difficulty in cyber incident reporting is deciding when uncertainty becomes sufficient knowledge.
Under article 33 of the GDPR, organisations must generally notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.
Where a breach is likely to result in a high risk to individuals, article 34 may also require notification to those affected.
What does it mean to become aware?
The European Data Protection Board’s Guidelines 9/2022 explain that awareness arises when an organisation has a reasonable degree of certainty that a security incident has occurred and personal data has been compromised.
This does not mean every vulnerability automatically starts the notification clock, nor does it mean an organisation may postpone reporting until investigators have established every detail.
An initial investigation may be necessary to determine whether a personal data breach occurred.
Once the relevant threshold is reached, however, uncertainty about the full extent of the incident will not ordinarily justify postponing notification.
The GDPR allows information to be provided in phases when complete details are not immediately available. This approach reflects the reality of cyber investigations.
From experience, organisations often discover incidents gradually. A security alert may lead to evidence of unauthorised server access. Further investigation may identify compromised credentials. Investigators may subsequently establish that personal information was affected.
The law must accommodate that progression without allowing organisations to delay reasonable investigation indefinitely.
In one journal article, the authors argued that breach notification should not operate merely as a reputational penalty.8 Its central value also lies in coordinating action to reduce the harm suffered by affected individuals.
That remains a compelling principle. The purpose of notification should not simply to announce that something went wrong, but rather to ensure that regulators and affected individuals receive information when it can meaningfully support oversight, protection and appropriate responses.
One incident, several legal reporting standards
There is no single international reporting threshold applicable to every cybersecurity incident. Different legal frameworks might protect different interests.
Under the GDPR, the main concern is the protection of personal data and the risks created for individuals.
The EU’s NIS2 Directive addresses critical cybersecurity incidents affecting organisations within its scope. Its reporting framework includes an early warning within 24 hours, an incident notification within 72 hours and a final report generally within one month after the incident notification. The applicable duties must be assessed under the relevant national implementation.9
The EU Cyber Resilience Act introduces another important distinction.
Since 11 September 2026, manufacturers within its scope have been required to report actively exploited vulnerabilities and severe incidents affecting the security of qualifying digital products.10
Its reporting obligations are not limited to incidents involving personal information. They concern product security and vulnerability management.
The obligations applicable to qualifying open-source software stewards begin later, on 11 December 2027.
In the United States, certain public companies must generally disclose material cybersecurity incidents under the Securities and Exchange Commission’s rules within four business days after determining materiality. That determination must not be unreasonably delayed.11
The SEC framework focuses on information material to investors, which may include significant business disruption even where no personal data has been stolen.
Australia’s Notifiable Data Breaches scheme uses another test.
Under that framework, notification generally becomes necessary where an eligible data breach is likely to result in serious harm to affected individuals.12 Organisations must also promptly assess suspected eligible breaches, taking reasonable steps to complete that assessment within 30 days.
The implications are quite clear for everyone.
A single PHP2Shell exploitation incident could trigger different duties across jurisdictions, depending on the organisation’s role, the systems affected, the consequences and the applicable legislation.
A reportable cybersecurity incident is not always a personal data breach, and a personal data breach does not automatically establish civil liability.
What the courts tell us about liability
Two important cases help illustrate why cybersecurity law requires some in-depth discussion.
The United Kingdom: WM Morrison Supermarkets plc v Various Claimants [2020] UKSC 12
In this case, a Morrisons employee, Andrew Skelton, deliberately disclosed payroll information after developing a personal grievance against his employer.
He had been entrusted with employee information for a legitimate work-related purpose but later published it online.
Thousands of affected employees brought legal proceedings against Morrisons.
The central issue before the UK Supreme Court was whether the company was vicariously liable for the employee’s wrongful conduct.
The Court concluded that Morrisons was not vicariously liable because the employee had acted in pursuit of a personal vendetta rather than in the ordinary course of his employment.
The judgment did not establish that organisations are generally free from responsibility for misconduct involving employee data. Rather, it clarified the limits of vicarious liability in the circumstances of that case.
The ruling tells us that the existence of a data breach does not answer every question about who is legally responsible for it. Responsibility requires analysis of the relevant legal duty, the conduct involved and the connection between that conduct and the alleged defendant.
Read the UK Supreme Court judgment here.
The United States: Remijas v Neiman Marcus Group, LLC, 794 F.3d 688 (7th Cir. 2015)
In 2013, hackers compromised payment card information belonging to customers of the American retailer Neiman Marcus.
Approximately 350,000 payment cards were potentially exposed, and around 9,200 were known to have been used fraudulently.
Affected customers brought proceedings alleging various forms of harm, including expenses incurred in responding to the compromise and the risk of future fraud.
The United States Court of Appeals for the Seventh Circuit held that the plaintiffs had sufficiently established standing to pursue their claims.
The decision did not necessarily determine that Neiman Marcus was ultimately liable, but it concerned whether the alleged injuries were sufficient to permit the litigation to proceed.
It nevertheless demonstrates how evidence of an actual compromise can change the legal assessment of future harm.
How relevant is this ruling to PHP2Shell?
A theoretical possibility of credential theft is different from forensic evidence establishing that attackers obtained sensitive information.
The two situations may produce very different legal consequences.
Read the Seventh Circuit judgment.
Taken together, these cases show why we must distinguish the occurrence of a breach from inadequate security, liability and legally recognised harm. They do not prescribe when PHP2Shell incidents must be reported; rather, they clarify the questions that may arise after the technical facts have been established.
An attack may begin before the public warning
A further development makes the October 2026 PHP disclosure especially important.
On 21 October, Amazon Threat Intelligence reported detecting an attempted PHP2Shell exploit against its MadPot honeypot infrastructure on 17 October.
That was four days before the public disclosure.
Amazon also identified further exploitation attempts around the time the vulnerabilities became public.13
The observations did not establish whether those attempts would have succeeded against real-world production systems.
Nevertheless, they challenge a common assumption.
Organisations frequently begin vulnerability investigations from the date an official advisory is published, but an attacker may have discovered or attempted to exploit the weakness earlier.
The date a vulnerability becomes public is not necessarily the date the security risk begins.
Forensic investigations should therefore consider credible evidence of earlier exploitation when establishing the period of possible exposure.
This creates what we might call two competing timelines:
The first concerns when malicious activity could have occurred.
The second concerns when an organisation became sufficiently aware of a legally relevant incident to trigger notification obligations.
Those dates may be separated by days, weeks or longer.
A reporting deadline cannot simply be calculated from the vulnerability’s publication date; mor should an organisation assume that an investigation need only examine activity occurring after that announcement.
Understanding both timelines is essential.
A new standard of cybersecurity accountability: can organisations prove what they know?
We believe the strongest lesson from PHP2Shell case is not simply that organisations need better patch management, but they also need better ways to establish the truth after an incident.
For years, cybersecurity governance has concentrated heavily on preventing attacks through firewalls, encryption, authentication, vulnerability scanning and software updates.14
Those measures remain indispensable. However, incident reporting introduces another responsibility: organisations must be capable of investigating foreseeable security failures and explaining the basis for their decisions.
This requires attention to forensic readiness.
An organisation should understand what its monitoring systems record, how long relevant evidence is retained, which infrastructure components fall outside its visibility and whether third-party providers can supply essential technical information.
It should also be able to explain important gaps in that evidence.
This does not mean organisations must maintain perfect monitoring systems or store every possible record indefinitely (it would be great if they could, of course!). Security and privacy considerations require proportionate decisions about collection and retention.
However, an organisation cannot confidently rely on the absence of evidence without understanding what evidence its systems could realistically have produced.
The aforementioned point has broader relevance beyond PHP.
Software environments are becoming more complex and attacks increasingly target dependencies, cloud infrastructure and runtime processes. Conventional application records may provide only a partial picture.15
Legal advisers should therefore ask questions that go beyond whether investigators discovered signs of intrusion/hacking.
For example, what sources were examined? What information was unavailable? Could the monitoring system detect the suspected method of attack? Were findings independently tested? What reasonable alternative explanations remain?
These are technical questions, but their answers may determine the defensibility of legal conclusions. They also influence whether a statement to a regulator, investor or affected customer accurately reflects the organisation’s knowledge.
Why patching alone cannot respond to legal enquiry
Installing security updates is an essential part of responding to PHP2Shell, but a patch addresses the vulnerability going forward. It does not establish whether an attacker exploited it before the update was installed.
This is particularly important where credible evidence suggests exploitation attempts preceded public disclosure. An organisation may have fully patched its infrastructure and still need to examine earlier activity. At the same time, investigators face a practical challenge.
Restarting affected services, rebuilding systems or replacing compromised infrastructure may remove key evidence.
Security teams therefore need procedures that support rapid remedies while preserving relevant records where reasonably possible.
This strategy requires coordination between technical investigators, legal advisers, management and external service providers. It also requires safe documentation.
Ideally, organisations should be able to explain when a vulnerability was identified, how its exposure was assessed, why particular investigative steps were taken and what evidence supported the resulting reporting decision.
Research examines the broader value of breach-notification obligations where the authors identify accountability, transparency and incentives for improved cybersecurity among their important benefits, while questioning how far individuals can realistically protect themselves after receiving notifications.
Their analysis reinforces a point that deserves wider recognition.
Cybersecurity reporting should not become an administrative exercise in which organisations merely satisfy a deadline (or a ‘tickbox’ task). Its value should depend on the accuracy of the information disclosed and the actions that follow.
What can we learn from the PHP2Shell incident?
The October 2026 PHP vulnerabilities will understandably be remembered as a major technical security event.
They exposed weaknesses in a widely deployed software runtime, prompted urgent remedies and demonstrated the speed with which attackers may attempt to exploit newly disclosed flaws.
They also reveal how difficult it can be to translate technical uncertainty into sound legal decisions.
A vulnerable system is not necessarily a compromised system. Likewise, a compromised system does not necessarily establish that personal data was affected. Similarly, a confirmed personal data breach does not automatically establish negligence, compensation or liability, and the absence of detected malicious activity does not always prove that no intrusion occurred.
Each question requires its own evidence and legal assessment.
The challenge for organisations is not to eliminate uncertainty entirely; that may be impossible to achieve. However, they should investigate reasonably, recognise the limitations of available evidence and make timely decisions under the legal frameworks that apply.
We believe future cybersecurity accountability will increasingly depend on an organisation’s ability to demonstrate not only the precautions it took to prevent an incident, but also the quality of its investigation when those precautions were tested.
A critical vulnerability is not automatically a confirmed data breach, but where an organisation cannot determine whether a breach occurred, the more important question may be “why” it cannot establish the facts.
That is the key legal issue PHP2Shell brings into focus, and it may become one of the defining questions in the next stage of global cybersecurity law.
Legal and technical information reflects developments available as of 24 October 2026. The judicial decisions discussed illustrate different legal principles and do not concern PHP2Shell itself. Reporting obligations and liability depend on the relevant jurisdiction and the specific facts of each incident.
Sotnik, S., Manakov, V., & Lyashenko, V. (2023). Overview: PHP and MySQL features for creating modern web projects.
Scambray, J., Shema, M., & Sima, C. (2006). Hacking exposed: Web applications. New York: McGraw-Hill.
Aslan, Ö., Aktuğ, S. S., Ozkan-Okay, M., Yilmaz, A. A., & Akin, E. (2023). A comprehensive review of cyber security vulnerabilities, threats, attacks, and solutions. Electronics, 12(6), 1333.
Schwartz, Paul M., and Edward J. Janger (2007). “Notification of Data Security Breaches.” Michigan Law Review, 105(5), 913–984.
Sasha Romanosky, Examining the costs and causes of cyber incidents, Journal of Cybersecurity, Volume 2, Issue 2, December 2016, Pages 121–135
Liu, L., De Vel, O., Han, Q. L., Zhang, J., & Xiang, Y. (2018). Detecting and preventing cyber insider threats: A survey. IEEE Communications Surveys & Tutorials, 20(2), 1397-1417.
VB v Natsionalna agentsia za prihodite, Case C-340/21, ECLI:EU:C:2023:986, Court of Justice of the European Union, 14 December 2023.
Schwartz, Paul M., and Edward J. Janger (2007). “Notification of Data Security Breaches.” Michigan Law Review, 105(5), 913–984.
European Parliament and Council. Directive (EU) 2022/2555 (NIS2), particularly Article 23.
European Commission (2026). “Cyber Resilience Act — Reporting Obligations.”
United States Securities and Exchange Commission (2023). “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure.”
Office of the Australian Information Commissioner. “Notifiable Data Breaches Scheme.”
Amazon Threat Intelligence (2026). “Amazon Threat Intelligence Identifies PHP2Shell Exploitation Prior to Public Disclosure in MadPot.” 21 October 2026.
Salman, H. A., & Alsajri, A. (2023). The evolution of cybersecurity threats and strategies for effective protection. A review. SHIFRA, 2023, 73-85.
Zuiderveen Borgesius, Frederik, Hadi Asghari, Noël Bangma, and Jaap-Henk Hoepman (2024). “The GDPR’s Rules on Data Breaches: Analysing Their Rationales and Effects.” Research preprint.