Two critical vulnerabilities in the PHP programming language are threatening web applications and digital products worldwide. The Federal Office for Information Security (BSI) has warned of a possible imminent and widespread exploitation of the vulnerabilities known as PHP2Shell and has called for immediate protective measures. Security updates are already available for supported PHP versions. Companies should not only assess their technical vulnerability but also consider potential legal obligations regarding action and reporting, as well as liability risks.
The vulnerabilities CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026, affect one of the world’s most widely used technologies for running web applications.
The security vulnerabilities, which have become known as “PHP2Shell,” each have a CVSS score of 9.2. Under certain technical conditions, attackers can exploit them remotely and without prior authentication to execute malicious code on affected systems.
The potential consequences range from the compromise of individual websites to the takeover of affected servers and access to the information processed on them. In addition to traditional websites, corporate portals, online stores, administrative systems, and other digital products may also be affected.
Security updates have been available for the currently supported PHP version branches since October 21, 2026. The vulnerabilities have been fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For older PHP versions and PHP components embedded in products, you should check separately whether the respective manufacturer or distributor provides security updates or backports.
The risk is not limited to theoretically conceivable attacks. Security firms have already documented specific attempts to exploit these vulnerabilities, in some cases even before the vulnerabilities were officially disclosed.
BSI Warns of Widespread Attacks
On October 21, 2026, the BSI issued a cybersecurity alert regarding the PHP vulnerabilities and rated the threat at alert level 3 (“Orange”).
BSI Vice President Thomas Caspers warned of a possible short-term, widespread exploitation of the vulnerability. His conclusion was clear: “There is therefore an urgent need for action!”
In particular, the BSI recommends installing available security updates immediately, checking the patch status, and stepping up monitoring of affected systems. If systems cannot be updated promptly, temporarily disconnecting them from the Internet should also be considered as a protective measure.
As of October 22, 2026, the BSI was not yet aware of any widespread successful exploitation of these vulnerabilities. However, this does not mean the all-clear has been given. Furthermore, the risk does not apply exclusively to traditional websites. Network components may also be vulnerable if they use the relevant PHP-based interfaces.
For companies, this means that systems that have not yet been patched require immediate attention. Systems that have already been updated should also be checked for possible prior compromises.
Risk and corrective action increase the urgency to act
The BSI warning is relevant not only from a technical standpoint but also from a legal one. This is because it raises the standards for due diligence.
Article 32 of the GDPR requires data controllers and processors to implement appropriate technical and organizational measures. For particularly important and important institutions, Section 30 of the BSIG requires appropriate cybersecurity risk management measures and explicitly addresses security in the procurement, development, and maintenance of IT systems, as well as the management of vulnerabilities.
What is particularly relevant in the case of PHP2Shell is that the vulnerability is not only publicly known, but security updates are already available for supported PHP versions. This makes it more difficult to justify a delayed response. The more clearly a significant security risk is identifiable and the more effective the available remedies are, the more obligated companies are to implement them as quickly as possible.
Key factors include, among others, the extent to which the system is specifically affected and exposed, the feasibility of implementing the update, available interim measures, and the potential consequences of an attack.
Companies should therefore not only implement technical measures, but also document in a transparent manner when the threat was detected, which systems were examined, and what decisions were made.
An attack can trigger reports under the CRA, BSIG, and GDPR
Companies must determine whether an incident triggers a reporting requirement. The good news: The mere existence of a vulnerable PHP installation does not, in itself, constitute a reportable incident. A report is only required if the vulnerability was actually exploited and if the legal requirements are met. The respective reporting requirements under the CRA, BSIG, and GDPR differ.
CRA: Mandatory Reporting of Actively Exploited Vulnerabilities
Manufacturers of products containing digital elements have been subject to the reporting requirements of Article 14 of the CRA since September 11, 2026. For PHP-based products, it is particularly important to verify whether there is an actively exploited vulnerability present in the specific product. The mere use of a vulnerable third-party or open-source component should therefore not be equated with a CRA reporting obligation without first verifying whether the specific product is affected.
BSIG: Mandatory Reporting of Significant Security Incidents
According to Section 32 of the BSIG, particularly important and important organizations must report significant security incidents. Here, too, the mere existence of a vulnerable PHP version does not, in and of itself, constitute a significant security incident.
GDPR: Obligation to Report Data Breaches
Under the GDPR, a reporting obligation may apply, in particular, if an attack results in a breach of the protection of personal data. A proven data breach is not required for this. For example, the alteration, deletion, or loss of availability of personal data may also constitute a data breach.
Companies should therefore conduct technical investigations into the attack and legal assessments of potential reporting thresholds in parallel. They should not wait for the forensic investigation to be completed if a statutory reporting deadline has already begun.
We explain in detail the various triggers, deadlines, and how the reporting requirements under the GDPR, BSIG, and CRA interact in our article “Reporting Deadlines for Cyber Incidents Under the GDPR, BSIG, and CRA—Every Hour Counts.”
Manufacturers may be required to provide security updates under product liability law
Manufacturers of software and products with digital components may also be liable under product liability law to provide necessary security updates after the product has been placed on the market.
Under the reform of product liability law, software is explicitly classified as a product. At the same time, the new law recognizes that manufacturers can influence the safety of digital products even after they have been placed on the market through software updates and related services.
If security updates required to maintain product security—and which are subject to the manufacturer’s control—are missing, this can lead to product malfunctions.
The new regulations are scheduled to take effect, for the most part, on December 9, 2026. However, for products placed on the market prior to that date, the existing product liability law generally remains applicable; in addition, claims for damages based on contract, tort, or data protection law may also be considered.
PHP2Shell thus serves as a prime example of why vendors should be aware of their software dependencies and have effective processes in place for assessing vulnerabilities and providing security updates.
Cybersecurity is the responsibility of senior management
Dealing with a known critical vulnerability is also a matter for senior management, not just the IT department.
For particularly important and important institutions, this is made especially clear by § 38(1) of the BSIG: Management is required to implement the risk management measures mandated by § 30 of the BSIG and to monitor their implementation.
Even outside the scope of this specific regulation, organizational and oversight obligations under corporate law may apply. In the event of a critical security vulnerability that has been explicitly addressed by the BSI, it is therefore also essential that responsibilities, escalation procedures, and decision-making processes function properly.
In the event of a loss, management may also be personally liable if adequate risk management and effective decision-making processes were not in place.
What Companies Should Do Specifically Right Now
From a technical and legal perspective, the following measures are of particular importance:
1. Determine the extent of the impact
. PHP versions, exposed servers, web applications, and digital products should be reviewed. This review should also take into account embedded PHP components, network components, and external hosting and IT service providers.
2. Prioritize security updates
Security updates are available for the supported PHP versions. Affected systems should be updated based on the specific risk level, and their actual patch status should be verified. For older or embedded PHP versions, check whether vendors or distributors provide updates or backports.
3. Investigate Previous Compromises
Even systems that have already been updated may have been compromised previously. Security logs and other indicators of compromise should therefore be reviewed retroactively.
4. Review reporting requirements in parallel
If there are indications of exploitation, potential obligations—particularly under the CRA, BSIG, and GDPR—should be assessed at an early stage. The technical investigation and the legal assessment should proceed in parallel.
5. Document decisions and involve those responsible
The extent of the impact, the timing of awareness, measures taken, and key decisions should be documented in a transparent manner. IT security, data protection, the legal department, product safety, and, if necessary, senior management should establish a shared understanding of the situation at an early stage.
PHP2Shell also increases the pressure on companies to take action from a legal perspective
The combination of a highly critical vulnerability in PHP2Shell, an explicit warning from the BSI, and security updates that are already available significantly increases the urgency to take action, including from a legal perspective.
A known vulnerability or a government warning increases the requirements for due diligence and the liability risk. Companies may be obligated to assess how they are specifically affected and to respond appropriately to identifiable risks even before any damage occurs.
Even if no attack has been proven, companies may need to be able to demonstrate that they identified, assessed, and appropriately addressed a known significant risk in a timely manner.
