PHP2Shell: Who is affected and what to do now

PHP2Shell is the name for two critical flaws in PHP itself, and only two things fully protect against them: updating to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or disconnecting the system from the internet. [1, 2]

A provisional assessment. It is based on the BSI cyber security warning in version 1.2 of 22.10.2026, and the situation is still developing. This analysis separates what the BSI and the PHP project have documented, what the media and security firms report and what we assess. It is valid until 31.12.2026. [1, 3]

The author is founder and managing director of KaitoSec.

In brief

• PHP2Shell refers to two critical vulnerabilities in PHP itself (CVE-2026-109618, CVE-2026-109619, CVSS 4.0: 9.2) that let attackers execute code on web servers without logging in and without any user interaction. The only protection against this PHP vulnerability is versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or disconnecting from the internet. [2, 3]
• According to the BSI, every PHP installation that processes web requests is affected, going back at least to PHP 5. Workarounds reduce the attack surface but do not close the flaws. [1]
• As of 22.10.2026, the BSI has no confirmed reports of successfully compromised systems in regulated industries or the federal administration. Attempts began before the patch: Amazon reports a first exploitation attempt on 17 October and now speaks of widespread exploitation. [1, 4]
• You can be affected even if you do not run a PHP website of your own. Firewalls, load balancers, NAS systems and hosting panels can contain PHP; according to the BSI, products from F5, Citrix NetScaler, Palo Alto, OPNsense, pfSense, QNAP, Synology and cPanel are at least partly affected. [1]
• Many public authorities, hospitals and universities have taken their websites offline as a precaution since 21 October. That is a deliberate trade-off: the BSI recommends considering disconnection if patching is not possible immediately. [1, 5, 6]

What has happened since 20 October?

On 20 October 2026, the PHP security team announced a critical security release, and the patches came out on the afternoon of 21 October. On the same day, the BSI issued a cyber security warning at level 3/orange, the EU cybersecurity bodies published a joint statement, and numerous operators took websites offline as a precaution. [2, 3, 7]

The PHP project's pre-announcement and the GitHub advisories both rate the flaws at CVSS 4.0 9.2; the PHP project's security advisory followed on 21 October, with the release announced for 4 pm German time. The BSI cyber security warning has been available in version 1.2 since 22 October. [1, 2, 3]

Date	Event	Evidence level	Source
from August 2026	Several research teams, including Wiz and Calif (the latter at OpenAI's invitation, partly using AI models), find the flaws and report them to the PHP project; Calif first on 11.08., Wiz on 24.08.	reported (researchers themselves)	[8, 9]
17.10.	Amazon Threat Intelligence observes a first exploitation attempt, four days before disclosure	reported	[4, 10]
20.10.	The PHP project announces the security release for 21.10. According to SecurityWeek, the flaws leak to the public the same day; Huntress points to a since-deleted post on Hacker News.	documented / reported	[2, 10, 11]
21.10., afternoon	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released, along with backport patches for 7.4, 8.0 and 8.1	documented	[1, 2]
21.10.	BSI warning in versions 1.0 and 1.1; ENISA, CERT-EU, Europol EC3, the European Commission and the CSIRTs Network publish a joint statement	documented	[3, 7]
21./22.10.	Public authorities, hospitals and universities in Germany and Switzerland take websites offline as a precaution	documented (spokespersons) / reported	[5, 6, 12, 13]
22.10.	BSI warning in version 1.2: vendor advisories for network components; no confirmed reports of successful compromise in regulated industries or the federal administration (as of 22.10.2026); reports of incomplete patches refuted	documented	[1]

How does PHP2Shell work, and which versions are safe?

Both parts of this PHP vulnerability sit in the core of PHP, not in an application. One arises when PHP aborts a request half-built because memory runs short; the other when remnants of an earlier request are reused in memory. Updating WordPress, TYPO3 or Shopware alone therefore does not protect you; the PHP runtime itself has to be updated. [1, 2]

Both CVE entries, CVE-2026-109618 and CVE-2026-109619, enable remote code execution (RCE): attackers run their own code on the server over the network. Hence the "Shell" in the name: anyone who manages this can drop a web shell, a backdoor through which the server can later be controlled remotely. According to Wiz, even a plain "Hello World" script on a vulnerable version can be attackable. [8, 14, 15]

Volker Dusch, a software developer at the PHP Foundation, told the Wall Street Journal that the flaws are PHP's most serious security problem in more than ten years (as quoted by 20 Minuten/dpa). [12]

According to the BSI, all installations that process web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php, where a single request without login is enough, before any application code runs. [1]

PHP usually comes from the package manager. Distributions patch by backporting, so the version number does not show the real state: what counts is the advisory from Ubuntu, Debian or Red Hat. Docker images have to be rebuilt, and according to the PHP project and the BSI, workarounds do not fully protect. [1, 2]

Version branch	Protected from	PHP security support until	Note
8.5	8.5.12	31.12.2029	supported
8.4	8.4.27	31.12.2028	supported
8.3	8.3.36	31.12.2027	supported
8.2	8.2.35	31.12.2026	BSI points to end of support
8.1, 8.0, 7.4	Backport patches from the PHP Security Team	End-of-Life	migration recommended
older (back to PHP 5)	no patch from the PHP project	End-of-Life	check your distribution or LTS provider, otherwise disconnect or migrate

Table as of: PHP project and BSI, 22.10.2026. [1, 2, 14, 16]

Why are public authorities switching off their websites?

Because a website that cannot be patched immediately has only two states: reachable and attackable, or offline and protected. In this case the BSI explicitly recommends considering a temporary disconnection from the internet, since no workaround fully protects. Switching off trades availability for integrity and confidentiality. [1]

The joint statement of the EU cybersecurity bodies and CERT-EU likewise recommend isolating systems if remediation is delayed. Those who switch off are not deciding against the service, but against injected code and leaking data. [1, 7, 17]

In Berlin, according to Tagesspiegel, the police's online station, the fire brigade, FU, HU and Charité, among others, were offline or restricted on 21 and 22 October, and the House of Representatives had individual functions down; according to heise, parts of berlin.de were switched off. Senate spokesperson Christine Richter said of berlin.de: "We have got almost everything up and running again" (our translation). According to Charité spokesperson Markus Heggen, the restrictions had no impact on the hospital's work. [5, 13]

On 21 October, Kommunal.de named the RKI, the Federal Police, Customs, the Federal Ministry of the Interior, Mainz, Unna and Datteln, among others; the Dachau district office and Munich were already back online. On 22 October, heise, citing dpa and NDR, reported unreachable authority and police websites in Bavaria and Lower Saxony. The BSI confirms precautionary disconnections. [1, 6, 13]

Our assessment: this trade-off can only be made quickly if it has been settled in advance. Who may switch off a citizen-facing website, who communicates alternative contact channels, as kommunal.de recommends, and who decides when to switch it back on? That belongs in the emergency organisation, with clear roles and escalation paths in the crisis team (German). [6]

Who is affected, even without a PHP website of their own?

Any organisation is affected if PHP processes web requests anywhere in its IT: on its own servers, at hosting providers and service providers, or hidden in devices. The BSI names firewalls, routers, load balancers and network components in general; according to the BSI, as of 22.10.2026, products from eight vendors are at least partly affected, including NAS systems from QNAP and Synology. [1]

• Your own web applications and CMS: the BSI names WordPress, Drupal, TYPO3, Joomla, Magento and Nextcloud, and Deutschland sicher im Netz adds Shopware for online shops. [1, 18]
• Hosting providers and agencies: with shared hosting and managed servers, the provider does the patching. In our assessment, the risk stays with the operator, so the question of patch status belongs in supplier risk management (German). [1]
• Appliances and network components: according to the BSI, as of 22.10.2026, products from F5, Citrix NetScaler, Palo Alto, OPNsense, Netgate pfSense, QNAP, Synology and cPanel are at least partly affected; the BSI lists Cisco, WatchGuard, Sophos and Broadcom as unknown so far or not affected. According to the BSI, the list is not exhaustive, and the Dutch NCSC maintains a continuously updated one. Here the flaw is closed by a firmware update from the vendor, not by a PHP update. [1, 19]
• Industrial control systems (ICS/OT): according to the BSI, their web interfaces can in principle be affected. [1]

For scale: on 21 October, Censys counted around 1.58 million hosts whose PHP version was visible from outside, around 1.57 million of them unpatched. VulnCheck found more than 2.6 million internet-reachable PHP hosts, around one million of them running End-of-Life versions. Both figures are based on the firms' internet scans, reported by SecurityWeek on 22 October. [10] According to the BSI, many of these legacy systems no longer receive any updates at all. [1]

Which obligations apply now?

A reporting obligation does not arise from the vulnerability itself, only from a significant security incident. For entities under NIS2, vulnerability management is mandatory: Section 30 BSIG requires it, as it requires supply chain security. If personal data is exfiltrated, Art. 33 GDPR also applies, with a 72-hour reporting deadline. [20, 21, 22]

Under NIS2, particularly important and important entities are obliged under Section 30 BSIG to take appropriate, proportionate and effective measures. These include supply chain security, maintenance "including vulnerability management and disclosure" (our translation) and assessing effectiveness. Of the public administration, the BSI Act covers only federal administration bodies; federal states and municipalities are not included. [20, 23]

Under Section 32 BSIG, only a significant security incident is reportable, for example one causing severe operational disruption or considerable damage to others. On our reading, a confirmed compromise via PHP2Shell will often reach this threshold; a precautionary shutdown or a repelled attempt on its own will not. The individual case remains decisive. Our article on NIS2 reporting obligations explains the channels and content of a report. [21, 24]

Under the GDPR, a personal data breach must be reported without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk. Where the risk is high, Art. 34 requires notifying the data subjects. [22]

For ISO/IEC 27001:2022 and BSI IT-Grundschutz (Edition 2023), the table summarises the relevant requirements; in its warning, the BSI additionally names APP.3.1. [1, 25, 26, 27, 28]

Framework	Applies to	What it requires now	Deadline
Section 30 BSIG	Particularly important and important entities	Vulnerability management, supply chain security, effectiveness review	no fixed deadline, risk-based
Section 32 BSIG	Particularly important and important entities	Reporting significant security incidents to the BSI	24 h early warning, 72 h notification, 1 month final report
Art. 33/34 GDPR	Controllers of personal data	Notification to the supervisory authority, notification of data subjects where the risk is high	72 h (Art. 33)
ISO/IEC 27001 A 8.8	Organisations with an ISMS under ISO 27001	Management of technical vulnerabilities	no fixed deadline, risk-based
BSI IT-Grundschutz OPS.1.1.3/APP.3.2	Users of BSI IT-Grundschutz	Patch and change management, securing web servers	no fixed deadline, risk-based

What should organisations check now?

First establish everywhere PHP runs, including in appliances and at service providers. Then compare the versions against the patched releases, patch or disconnect, check vendor advisories, examine the systems for compromise and document every decision. The BSI advises checking for a compromise that has already occurred, even after patching. [1, 2]

Step	Question to check	Responsible	Evidence/source
1. Inventory	Where does PHP process web requests: own servers, container images, CMS and shops, appliances with a web interface, hosted sites?	IT operations with information security officer	Asset list [1]
2. Version	Does the installed version match 8.5.12, 8.4.27, 8.3.36, 8.2.35 or the distribution's backport?	IT operations	Comparison with php.net or the distribution advisory [1, 2]
3. Patch or disconnect	Is every reachable system patched or disconnected from the internet? Have containers been rebuilt?	IT operations, service providers	Changelog, ticket [1]
4. Appliances	Have the vendors of your firewalls, gateways and NAS published an advisory?	Network/security	BSI vendor list, NCSC-NL [1, 19]
5. Service providers	Have hosting providers, agencies and data centres patched and checked for compromise? Is the answer in writing?	Information security officer, procurement	Supplier response [7]
6. Check for compromise	Are there signs of a dropped web shell: unusual processes started by the web server, new or modified PHP files, clusters of HTTP 500 errors after upload requests?	Security/SOC	BSI indicators [1]
7. End-of-Life	Which applications run on PHP older than 8.2 or on 8.2 (support until 31.12.2026)?	Application owners	Migration plan [1, 16]
8. Document the decision	Who decided on shutdown, workaround or residual risk? Has the reporting obligation (Section 32 BSIG, Art. 33 GDPR) been checked?	Information security officer, management or head of the authority, data protection officer	Risk decision [20, 21, 22]

Steps 2 and 3 belong in regular patch management. Steps 1, 5 and 8 are documentation work that should already be done when things get serious.

In KaitoSec, the information for these three steps sits in one place. The asset inventory records hardware, software, cloud and network, including via CSV import, and shows which systems and processes depend on an asset and which supplier it is linked to.

In vendor management, you send questionnaires to hosting providers and agencies, and open items become tasks with an owner. You record risk decisions as a treatment, with owner, due date and approval. Our article on tracking ISMS measures shows how to follow up on such measures.

How we arrive at this assessment

This assessment relies primarily on the BSI cyber security warning in version 1.2, the PHP project's security advisory and the GitHub advisories for both CVEs. We mark media reports and observations by security firms as reported, and our own inferences as assessment. [1, 2, 3, 14, 15]

Our assessment covers the reporting threshold under Section 32 BSIG, the shutdown trade-off and the order of the checks. The procedure is the same as in our case analyses of the City of Vienna and the Berlin state network.

What remains open about PHP2Shell?

Above all, it remains open whether and where PHP2Shell has already been successfully exploited. As of 22.10.2026, the BSI has no confirmed reports of successfully compromised systems in regulated industries or the federal administration. Amazon, by contrast, reports widespread exploitation, and Reuters, citing Cloudflare, millions of attack attempts; Cloudflare's own blog gives no number. These measurements by individual providers have not been independently verified, and attempts are not confirmed compromises. [1, 4, 13, 29]

The list of affected products is still being compiled: the BSI explicitly calls its list not exhaustive, and the NCSC-NL updates its own continuously. The BSI considers further findings in PHP possible, partly because of the increased use of AI in vulnerability research. The list of organisations that went offline is also incomplete; we name only those that sources name. [1, 19]

Frequently asked questions about PHP2Shell

What is PHP2Shell?

PHP2Shell is the collective name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 4.0 9.2. They allow code execution without login. Only the patched versions or disconnecting from the internet protect against them. According to the BSI, the name is a nod to Log4Shell. [1, 2, 3]

Which PHP versions are safe?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are protected. For 7.4, 8.0 and 8.1, the PHP Security Team has provided backport patches. If you get PHP from a Linux distribution, check your status against its advisory, because the version number does not always reflect the patch level. [1, 2]

Is it enough to update WordPress or TYPO3?

No. The flaws sit in the PHP runtime, not in the application. Updating the CMS leaves the vulnerable PHP version unchanged. According to the BSI, PHP itself has to be updated, and for containers that includes rebuilding the images. [1]

Does a web application firewall protect against PHP2Shell?

A web application firewall can make attacks harder, but cannot rule them out. According to the BSI, as things stand only patching or disconnecting from the internet offers full protection. Cloudflare, too, advises in its own blog to patch despite its filter rules. [1, 29]

Do I have to report PHP2Shell under NIS2?

The vulnerability itself is not reportable. What is reportable is a significant security incident under Section 32 BSIG: early warning within 24 hours, notification within 72 hours, final report after one month. If personal data is exfiltrated, Art. 33 GDPR also applies, with 72 hours. [21, 22, 24]

Has PHP2Shell already been exploited?

There have been attempts: Amazon observed the first on 17 October, four days before the patches were released. Amazon now speaks of widespread exploitation. According to the BSI itself (as of 22.10.2026), it has no confirmed reports of successfully compromised systems in regulated industries or the federal administration. [1, 4]

Sources

1. BSI, IT-Sicherheitshinweis zur Cybersicherheitswarnung PHP (PDF, TLP:CLEAR), Version 1.2, 22.10.2026. bsi.bund.de
2. PHP project, Security advisory: Critical remote code execution vulnerabilities, update now, 21.10.2026, with pre-announcement of 20.10.2026. php.net, advisory, php.net, pre-announcement
3. BSI, Cybersicherheitswarnung „PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.2, 22.10.2026. bsi.bund.de
4. Amazon Web Services, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, 21.10.2026. aws.amazon.com
5. Tagesspiegel, Berliner Polizei und weitere Behörden waren betroffen: Etliche Webseiten nach schwerer IT-Sicherheitslücke wieder verfügbar, 22.10.2026. tagesspiegel.de
6. KOMMUNAL, IT-Sicherheitslücke PHP: Bundesamt warnt Kommunen, 21.10.2026. kommunal.de
7. ENISA, European Commission, CERT-EU, Europol EC3 and CSIRTs Network, Joint statement on critical PHP vulnerabilities, 21.10.2026. enisa.europa.eu
8. Wiz, PHP2Shell: AI uncovers critical RCE vulnerabilities, 21.10.2026. wiz.io
9. Calif, A tale of two PHP remote vulnerabilities, 21.10.2026 (calif.io; contains technical exploitation details, so not linked here).
10. SecurityWeek, PHP2Shell Exploitation Started Days Before Patches, 22.10.2026. securityweek.com
11. Huntress, Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities, 20.10.2026. huntress.com
12. 20 Minuten (with dpa), «PHP2Shell»: «Gravierendstes Sicherheitsproblem»: Auch CH-Websites offline, 21.10.2026. 20min.ch
13. heise online, php2shell: Updates roll out as websites go offline and attacks begin, 22.10.2026. heise.de
14. PHP project, GitHub Security Advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618 "RCE via OOM corruption", 21.10.2026. github.com
15. PHP project, GitHub Security Advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619 "RCE via stale global state", 21.10.2026. github.com
16. PHP project, Supported Versions, retrieved 22.10.2026. php.net
17. CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP, 21.10.2026. cert.europa.eu
18. Deutschland sicher im Netz, PHP2Shell: Kritische Sicherheitslücken gefährden Webseiten und Onlineshops, 21.10.2026. sicher-im-netz.de
19. NCSC-NL, php2shell: product list and guidance on detection and protection, as of 22.10.2026. github.com
20. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 30 Risikomanagementmaßnahmen. gesetze-im-internet.de
21. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 32 Meldepflichten. gesetze-im-internet.de
22. Regulation (EU) 2016/679 (General Data Protection Regulation), Art. 33 and 34. eur-lex.europa.eu
23. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 29 Einrichtungen der Bundesverwaltung. gesetze-im-internet.de
24. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 2 Begriffsbestimmungen. gesetze-im-internet.de
25. ISO/IEC 27001:2022, Information security management systems, Requirements. iso.org
26. BSI, IT-Grundschutz-Kompendium Edition 2023, OPS.1.1.3 Patch- und Änderungsmanagement. bsi.bund.de
27. BSI, IT-Grundschutz-Kompendium Edition 2023, APP.3.2 Webserver. bsi.bund.de
28. BSI, IT-Grundschutz-Kompendium Edition 2023, APP.3.1 Webanwendungen und Webservices. bsi.bund.de
29. Cloudflare, Cloudflare deploys protections against php2shell vulnerability, 21.10.2026. blog.cloudflare.com

Status and updates

As of: 22.10.2026 (BSI warning version 1.2) · Valid until: 31.12.2026

• 22.10.2026, first published as a provisional assessment. The flaws, patches and BSI recommendations are documented; exploitation is reported by security firms, and successful compromises have not been confirmed by the BSI.

Until the review date we will check four points: new versions of the BSI warning, confirmed compromises in Germany, further vendor advisories and the return of websites that were taken offline. We will update this article in the same place if the situation changes.

---

How we work: In our case analyses, we assess incidents and security situations using a fixed procedure: sources with evidence levels, consequences, obligations, checks, open questions. From this we derive measures for organisations with organically grown IT and regulatory pressure. Arrange a conversation.