PHP2Shell: What NIS2 Entities Need to Do Now
PHP2Shell (CVSS 9.2) alone does not trigger a reporting obligation. A significant incident does. What § 30 BSIG requires now and what applies to manufacturers under the CRA.
Written by the NIS2Compass editorial team · Updated: October 2026 (news coverage as of 22 October 2026)
The PHP2Shell vulnerabilities (CVSS 9.2), patched on 21 October 2026, do not have to be reported on their own. In NIS2Compass's assessment, the reporting obligation under § 32 BSIG only applies once they lead to a significant security incident. Patching and documenting, however, are required under § 30 BSIG right now.
What Is PHP2Shell?
The name covers CVE-2026-109618 and CVE-2026-109619, two flaws in the PHP core. According to the BSI security advisory of 21 October 2026, attackers can use them to run code remotely on web servers, with no login and no user interaction. The BSI rates the advisory at criticality 3 / Orange: "Measures must be taken without delay."
According to the PHP project's advisory, every installation that processes web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team sees the highest risk with mod_php, where a single unauthenticated request is enough, before any application code runs.
The flaws sit in the language itself, not in a single product. As examples of PHP-based software, the BSI names WordPress, TYPO3, Nextcloud and OPNsense, among others. The vulnerabilities are fixed in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive regular releases. The PHP team has published minimal source code backports for 7.4, 8.0 and 8.1, and distributions and LTS vendors ship their own backports.
When it issued its advisory, the BSI knew of no confirmed attacks, but it expects vulnerable systems to be exploited soon. Some operators in Germany have taken their servers offline as a precaution. According to Help Net Security, an Amazon honeypot recorded an exploitation attempt as early as 17 October, before disclosure.
Do I Have to Report PHP2Shell to the BSI?
The vulnerability alone does not trigger a reporting obligation. The BSIG distinguishes three terms. A vulnerability is an exploitable property of a product (§ 2 no. 38 BSIG). A security incident is an event that actually compromises availability, integrity or confidentiality (no. 40). Only a significant security incident must be reported (no. 11).
An incident is significant if it causes or can cause "severe operational disruption of the services or financial losses", or can cause considerable damage to other persons. If you find traces of a compromise on an unpatched server, you have to answer that question. The deadlines in § 32 BSIG then apply: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report no later than one month after that.
The article on the significant security incident explains how to check the threshold. If personal data is exfiltrated, a notification to the data protection authority under Art. 33 GDPR is usually due in parallel.
A blocked attack attempt is usually a near miss (§ 2 no. 1). You can report it to the BSI under § 5 BSIG, but you are not required to.
What Does § 30 BSIG Require Because of PHP2Shell?
PHP2Shell mainly touches five of the ten minimum areas in § 30(2) BSIG. The measures must be appropriate, proportionate and effective and should reflect the state of the art. For a flaw this severe, that means acting fast and documenting it.
- Vulnerability management (no. 5): The provision explicitly covers "vulnerability handling and disclosure". That includes an inventory showing where PHP runs: on web servers, in Docker images and in appliances such as firewalls.
- Supply chain (no. 4): If a hoster, agency or managed service provider runs your PHP applications, ask for their patch status and get it confirmed.
- Incident handling and operations (nos. 2 and 3): If a system cannot be patched immediately, you need a decision on whether to take it offline temporarily. According to the BSI, only the patch or disconnecting from the internet provides full protection.
- Assessing effectiveness (no. 6): Distributions often ship backports with their own version numbers. The BSI points out that you may then need to compare the installed version against the distribution's advisory.
If an entity subject to NIS2 breaches these obligations, § 65 BSIG comes into play. The range would be up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities, or alternatively 2% or 1.4% of worldwide total turnover above EUR 500 million. The article on the fine tiers under § 65 BSIG explains the system, and the fine calculator provides an estimate.
What Applies to Manufacturers Using PHP in Their Products?
The BSI notes that manufacturers may need to release new firmware with patched PHP. Since 11 September 2026, they also face a reporting obligation. If a manufacturer becomes aware that a vulnerability in its product is being actively exploited, it must report it under Art. 14 of the Cyber Resilience Act as an early warning within 24 hours. The obligation is tied to exploitation in the manufacturer's own product, not to the disclosure of PHP2Shell.
The comparison CRA reporting under Art. 14 vs. § 32 BSIG shows how this report differs from § 32 BSIG.
Which Three Steps Make Sense After PHP2Shell?
- Inventory: Record every system running PHP, including containers, appliances and applications at service providers. The industry page for IT service providers shows whether your hosting provider is itself subject to NIS2.
- Patch and restart: Update to a fixed version, restart PHP services, rebuild Docker images and check the result against the advisory. The configuration changes in the PHP advisory only reduce the risk; they do not replace the update.
- Review and document: Check the logs of unpatched systems for anomalies from at least 17 October onwards, and record when each system was patched. You will need this record if the BSI later requests evidence of your measures.
To see whether your company falls under the BSIG at all, use the NIS2Compass applicability check. For everyone else, PHP2Shell is a reason to patch, but not a matter for the BSIG.
Sources:
- BSI, security advisory, version 1.1 of 21 October 2026: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit
- PHP project, security advisory of 21 October 2026: php.net News Archive 2026
- Help Net Security, 21 October 2026: PHP2Shell: Critical PHP vulnerabilities patched, update now!
- § 2 BSIG (Definitions), gesetze-im-internet.de
- § 5 BSIG (General reporting office), gesetze-im-internet.de
- § 30 BSIG (Risk management measures), gesetze-im-internet.de
- § 32 BSIG (Reporting obligations), gesetze-im-internet.de
- § 65 BSIG (Fine provisions), gesetze-im-internet.de
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- Regulation (EU) 2016/679 (GDPR), EUR-Lex
Does NIS2 apply to your company?
After an incident like this, many companies ask whether the obligations under the German NIS2 Implementation Act (NIS2UmsuCG) also apply to them. The NIS2 Affectedness Check answers this in under a minute, anonymously and without registration.
Start the NIS2 Affectedness CheckRelated Articles
CRA for Machinery: Which Connected Products Count?
Which connected machine components fall under the Cyber Resilience Act? PLCs, HMIs, gateways, the Machinery Regulation and smart meter gateways at a glance.
10 min read
Vienna Data Leak: Does NIS2 Apply to German Municipalities?
Attackers copied 26,000 documents from the City of Vienna. In Germany, core municipal administration is outside NIS2 scope, but municipal enterprises can be covered.
5 min read
Am I Affected by the CRA? A Self-Check for Manufacturers
Does the Cyber Resilience Act apply to you? The free CRA Applicability Check uses 20 questions to clarify whether you are a manufacturer, importer or distributor.
8 min read