On 21 October 2026, the PHP project released security updates for two critical vulnerabilities. The flaws CVE-2026-109618 and CVE-2026-109619 are being discussed under the name “PHP2Shell”. Under certain conditions, memory management errors may allow attackers to execute their own code remotely on an affected server without prior authentication. The affected component is the runtime environment that executes PHP applications on the server.[1][2]
PHP forms the technical foundation of many websites and applications, including WordPress, Drupal and Joomla. Online shops, customer portals and bespoke business applications may therefore also be affected. The researchers also demonstrated reading process memory, which may contain passwords or technical access keys, for example. The actual consequences of an attack depend particularly on the configuration, permissions and connections to other systems. Depending on how the system is used, risks include operational disruption, disclosure of trade secrets or manipulation of business processes. In addition to recovery costs, this may result in lost revenue and claims by customers.[2]
In particular, the PHP installation running the content management system must be checked. The PHP project identifies all installations processing web requests as at risk and rates the risk as particularly high for Apache with mod_php. Security fixes have been available since 21 October in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For packages from a Linux distributor or a provider offering long-term support, the fix may have been backported to an older release branch. What matters is the verified patch status of the package actually in operation.[1]
The first task is to identify the company’s own dependencies. IT teams and contracted providers should inventory all PHP systems and give priority to publicly accessible applications. Executive management should obtain written confirmation of the affected systems, the planned protective measures and when the update will become effective. If technical obstacles exist, a temporary restriction or shutdown of the affected service must be weighed against the consequences of an attack.[3]
The interim measures described by the PHP team reduce individual attack paths. Fully addressing the published vulnerabilities requires the security update. In parallel, checks should establish whether there are already signs of compromise. An update closes the known flaw; investigating previous access and possible backdoors remains a separate task. Where compromise is suspected, specialists should preserve relevant logs and assess which credentials need to be renewed and which systems need to be restored.[1][3]
From a data protection perspective, responsibility begins before any damage occurs. Article 8 FADP requires controllers and processors to take technical and organisational measures ensuring a level of data security appropriate to the risk. This creates an ongoing duty to assess and act when vulnerabilities become known. Legally, the combination of public accessibility, significant potential harm and available security fixes calls for very high priority. The appropriate timeframe depends on the specific exposure and the protective measures that can be implemented.[4][5]
For a company limited by shares, these risks also engage the board of directors’ duties under Articles 716a and 717 of the Code of Obligations (CO). The board must ensure appropriate organisation and oversight. Operational remediation is the responsibility of the relevant specialists; at management level, clear responsibilities, adequate resources and reliable reporting are required. Personal liability under Article 754 CO requires a culpable breach of duty, damage and the necessary causal connection. The relevant considerations are the information available at the time and the measures required in the specific circumstances.[6]
Even where hosting is outsourced, the company remains responsible for its data processing. Under Article 9(2) FADP, it must in particular satisfy itself that the processor can guarantee data security. In practice, this includes the patch status, the timing of implementation and the allocation of tasks between the hosting provider, web agency and company. Contracts should also specify how quickly critical vulnerabilities must be addressed, who reports security incidents and what assistance must be provided in investigating them.[7]
Breaches of agreed maintenance, security or information duties may give rise to damages claims under Article 97 CO. The relevant elements are the services owed, the damage and the causal connection; fault is generally presumed for this form of contractual liability. The specific contractual terms and statutory limits on exclusions or limitations of liability must also be considered.[6]
For reporting obligations, a distinction must be drawn between a vulnerability and a data security breach. Discovering a vulnerable PHP version initially calls for investigation and protective measures. Article 24 FADP is concerned with a data security breach within the meaning of Article 5(h) FADP. This includes, for example, making personal data accessible to unauthorised persons, unlawfully altering them or losing them. Unauthorised accessibility alone may already be relevant. The legal assessment therefore extends beyond proof that data have actually been exfiltrated.[4]
If such a breach is likely to result in a high risk to the personality or fundamental rights of those affected, the controller must inform the FDPIC as quickly as possible. The focus is on the potential consequences for the individuals concerned, for example from disclosed health data or credentials that could be misused. According to the FDPIC’s guidance, where a likely high risk is apparent, notification must be made promptly while longer investigations continue. Missing information may be supplied later. Remedial measures that are only planned must be disregarded in the risk assessment.[8]
A processor must report every data security breach to the controller as quickly as possible, regardless of whether it is classified as high risk. Under Article 24(4) FADP, affected individuals must be informed where this is necessary for their protection or where the FDPIC requires it. This may be the case, for example, if they need to change their credentials. This information duty must be assessed independently. Companies should therefore examine notification to the authority and communication with customers, employees or patients separately.[8]
Further reporting obligations may apply. Since 1 April 2025, operators of critical infrastructure covered by the Information Security Act have been required to report certain cyberattacks to the Swiss National Cyber Security Centre (NCSC) within 24 hours of discovery. Relevant attacks include those that threaten functionality, cause an information leak or manipulation, or involve extortion. Whether a company is covered depends on the statutory scope and exemptions.[9]
FINMA-supervised institutions are additionally subject to supervisory requirements. For a cyberattack that reaches the materiality threshold, FINMA generally expects an initial notification within 24 hours of discovery and a full report within 72 hours. The periods are generally counted on official banking business days; serious attacks must also be reported within 24 hours outside those days. For outsourced functions, discovery by the third-party provider may already trigger the reporting period. Banks in particular must therefore structure their contractual reporting channels so that the required information arrives in time.[10]
Companies with links to the EU market should also assess whether the GDPR applies. Where it does, Article 33 requires notification without undue delay and, where feasible, within 72 hours of becoming aware of the personal data breach. The reporting threshold is lower than under the Swiss FADP and generally already covers a likely risk to rights and freedoms. To qualify for an exemption, the breach must be unlikely to result in such a risk. The respective recipients, thresholds and deadlines must therefore be assessed separately.[11]
Finally, intentional breaches of the minimum data security requirements laid down by the Federal Council may, upon complaint, be punished by a fine of up to CHF 250’000 under Article 61(c) FADP. The criminal provisions primarily target natural persons. Such a sanction requires the elements of the specific offence to be established. A security incident or a delayed update alone therefore does not permit a reliable conclusion about criminal liability. Civil liability must be assessed separately and may also arise in cases of negligence.[4][12]
Executive management should now obtain a concise, substantiated situation report. It should identify which applications are affected, which fixes have been effectively installed, which signs of attack are being investigated and who decides on reporting obligations. If a service remains temporarily vulnerable, the decision should record the reasons, the additional protective measures and a binding remediation deadline. This documentation provides the basis for reducing technical risks in a targeted way and making the response understandable to customers, contractual partners and supervisory authorities.