PHP flaw php2shell: What companies need to do now

Only a PHP update closes the flaws completely

• What: CVE-2026-109618 and CVE-2026-109619 are two critical flaws in the PHP core (CVSS 4.0: 9.2). Under the right conditions, attackers can use them to run code on the server without logging in, with the privileges of the PHP process.
• Who: PHP installations that serve web requests are at risk, for example with PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. The official CVE entry lists the branches 8.2 to 8.5 before the fixed versions, while the finders see the flaw reaching back to PHP 5.4.
• Fix: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. For 8.1, 8.0 and 7.4 there are only minimal source backports, and for 7.3 and older nothing from PHP itself.
• Not enough: An update of your WordPress website, your shop or a plugin changes nothing, and a WAF (web application firewall, a protective filter in front of your site) is not enough on its own, according to the Swiss Federal Office for Cybersecurity (BACS). After the PHP update, all PHP processes must restart and containers must be rebuilt.
• Open: In the sources we checked up to the morning of 22 October 2026, no successful break-in is documented, but attack attempts are. How many websites are really vulnerable, nobody knows exactly, because scans by version number do not recognise backports.

What the flaws mean in the worst case and why they are so delicate

Both flaws have to do with how PHP handles errors, for example when memory runs short or a request breaks off in the middle of its work. That can corrupt the state of a PHP process, and an attacker can trigger it with crafted requests. Because the flaw sits in the PHP core, no update of WordPress, Shopware or a plugin helps.

In the worst case, an attacker can change files of the website, drop malicious code such as web shells (remote access for attackers), read credentials for the database and interfaces, and reach data that the application itself may read. Whether other websites on the same server are also affected depends on how the host separates them.

WordPress, Shopware, Shopify: Are you affected by the PHP vulnerabilities?

What decides it is who runs PHP on your server and which version runs there. The flaws sit in PHP itself, so the CMS plays no role.

WordPress. WordPress runs on PHP and is therefore indirectly affected. WordPress.org says, however, that no WordPress update is needed. For WordPress websites, the PHP version of the server alone decides. On the evening of 21 October, Automattic reported that its platforms, including WordPress.com and WordPress VIP, are protected. With managed hosts, the host patches; on your own servers, you or your agency do.

Shopware, TYPO3, Drupal, WooCommerce. TYPO3 and WooCommerce say the same as WordPress in so many words: the application needs no update, PHP does. Drupal calls the PHP update the only complete remedy. Shopware updated its SaaS shops automatically on 21 October, between 9:00 am and 4:33 pm CEST according to its status page. Anyone who hosts Shopware or TYPO3 themselves needs the PHP fix on their own server or from their host.

Shopify. Shopify operates its platform itself, and according to Shopify Engineering its core runs on Ruby on Rails (a description from 2020), so not on PHP. We found no statement on the PHP flaws up to the morning of 22 October 2026.

Everything around the shop can be affected: a WordPress blog, an app backend, middleware or a self-hosted frontend. Such parts belong in your inventory, even if the shop itself sits with Shopify.

A platform change is no answer to this flaw. Anyone who is considering a move from Shopware, Magento or WooCommerce to Shopify anyway should include the question “Who patches what?” in the planning of the Shopify migration.

Which PHP version is patched and how do you check?

Four branches are officially patched: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 8.1, 8.0 and 7.4, the PHP security team has provided minimal backports as Git branches, according to its announcement, and for 7.3 and older nothing. Anyone running these versions needs the fix from a distribution, an LTS vendor or the host, or an upgrade.

The version number misleads. Ubuntu, AlmaLinux and Red Hat in part backport the fix into older versions and leave the number as it is, Red Hat for example with PHP 7.4 on RHEL 8. Ubuntu 22.04, for example, ships it in package version 8.1.2-1ubuntu2.28, which looks ancient by number. Debian, by contrast, distributes new versions, 8.2.35 for Bookworm and 8.4.27 for Trixie. A scanner that only reads the version number therefore raises a false alarm or a false all-clear. What counts is the exact package version checked against the vendor's security notice, as the BACS also advises, and Red Hat explains the principle.

How to check. In WordPress, you find the version under Tools, Site Health, tab Info, section Server (documentation). On your own servers, the package manager shows you version and changelog. In containers, what counts is the version in the running container, not the one in the Dockerfile. After every update, restart PHP-FPM, Apache and all long-running workers, because old processes keep running with the old code.

Ten questions your agency and host should answer now

If you do not patch yourself, the conversation with your agency or host is key. These questions get binding answers instead of reassurance. A good answer names people, dates and times.

• Which websites, shops and applications run on PHP, including staging, microsites and legacy projects, in which version and at which host?
• Who is responsible for each system's PHP update, application update and restart, and where is that written down?
• Does anything run on PHP 8.1 or older, where does the fix come from, what does it cost per month, and when is the upgrade planned?
• By when is the patch in place, in which order are the systems worked through, and which interim measures apply until then?
• How is it ensured that the patch is really running, and what proof is there?
• Was there an attack before the patch, which logs exist, how far back do they go, and how is the file system checked for web shells?
• Which credentials and keys are rotated in which order if there is a suspicion, and who coordinates it?
• What does the response to this flaw cost, what does the maintenance contract cover, and is there on-call cover outside office hours?
• What do the hosting and maintenance contracts say about liability and shutdown in case of malware, and what does that mean in a real incident?
• How quickly does information arrive if data leakage is suspected, so that the 72 hours of the GDPR can be met?

Reporting duties: A PHP flaw alone does not trigger a report

A vulnerability is not yet a legal incident. The reporting duty under the GDPR only arises with a personal data breach, that is when data has been destroyed, lost, altered or disclosed, or accessed without authorisation (Art. 4 No. 12).

According to the guidelines of the European Data Protection Board, the 72 hours under Art. 33 start from the moment you know with reasonable certainty that this has happened. A report is due if there is likely a risk to the people affected, and with a high risk you must also inform them yourself under Art. 34. A short initial check is allowed, but it must begin immediately.

Hosts and agencies are usually processors. They must inform you without undue delay once they know, while the report to the supervisory authority stays with you as the controller. The reporting chain therefore belongs in the contract before anything happens.

Under NIS2, more applies if you are one of the essential or important entities. The countries implement it differently.

Austria: The NISG 2026 has applied in its main provisions since 1 October 2026. For a significant security incident, the Federal Office for Cybersecurity names an early warning within 24 hours of becoming aware, a notification within 72 hours and a final report after one month. A vulnerability alone is not an incident, and vulnerabilities and near misses can be reported voluntarily.

Germany: The NIS 2 implementation act has been in force since 6 December 2025. Switzerland: There is no NIS2. According to the BACS, the reporting duty for cyber attacks applies there only to critical infrastructure, within 24 hours of discovery. For data breaches with a likely high risk, Art. 24 of the revised Data Protection Act requires informing the Federal Data Protection and Information Commissioner as soon as possible, and there is no fixed 72 hours.

Manufacturers of products with digital elements are additionally subject to the Cyber Resilience Act: the reporting duty for actively exploited vulnerabilities under Art. 14 has applied since 11 September 2026, and ENISA recalls it in its joint statement on the PHP flaws. This is not legal advice. What applies to you is something to clarify with your legal or data protection adviser.

How an audit turned into an emergency release

The trail begins in 2024. According to the PHP Foundation, it was the first external audit in years, funded by the Sovereign Tech Agency and carried out by Quarkslab. While fixing a reported bug, a developer contracted by the Foundation came across early signs of a problem in how PHP handles memory exhaustion. A clean solution did not materialise for months: every approach broke compatibility, opened new ways to take the service down (denial of service) or required changes to many extensions, and the security team's decision process slowed the work. The Foundation itself calls the delay “a structural failure”.

The findings came in summer 2026, as the PHP Foundation reports. Calif began an audit on 30 July and on 11 August reported unconditional code execution with the same root cause as the 2024 problem. OpenAI independently reported the same cause the same day. Wiz Research reported further attack paths on 24 August, OpenAI on 18 September. According to the CVE record, the numbers were reserved on 12 October, and on 18 October the backports were ready.

Then came the leak. On 20 October, around 3 pm UTC, the two CVE numbers, a wrong release time and a wrong severity of 10.0 circulated; the actual score is 9.2. At 7:30 pm UTC, PHP published the pre-announcement and moved the release forward by one day to Wednesday, 21 October, 2 pm UTC (4 pm CEST). According to the PHP Foundation, Chainguard published images with the fix at 7:41 am UTC on 21 October, more than six hours before the release, and thereby broke the embargo. The release itself appeared before the announced time.

Nobody knows how many websites are affected, but three measurements set the frame

There is no percentage of affected websites, and every one you read is calculated or estimated. Three separate things can be documented: how widespread PHP is, which versions it runs on and how many servers on the open internet show PHP.

Reach. According to W3Techs, PHP runs on 69.3% of websites whose server-side language is known (as of 22 October 2026). WordPress alone, which is built on PHP, is behind 39.6% of all websites. Under .at domains the PHP share is 76.9%, under .de 77.7% and under .ch 70.4%. That describes the frame and says nothing about the number of vulnerable sites.

Versions. According to W3Techs, 65.2% of PHP websites run on PHP 8, 27.0% on PHP 7 and 7.7% still on PHP 5 (as of 21 October 2026, the values shift daily by tenths of a percent). Working through the branches (our own calculation), around 48.5% of PHP websites run on 8.1 or older, that is without a regular fix release, and around 51.5% on 8.2 to 8.5. Whether the fix is already running there, this number does not say.

Servers. Internet scans capture servers and services, not websites. According to Mallory, Shodan counted about 2.6 million services reporting a PHP version on 21 October, Censys about 6.3 million hosts running PHP software, VirusTotal about 5.1 million IP addresses, of which only about 1.1 million name a version. The numbers cannot be added up, and because one server often holds many websites, hosts cannot be converted into websites. Palo Alto Networks names over 22.6 million exposed instances without explaining what an instance is.

Austria. In the Shodan scan evaluated by Mallory, among services with a visible PHP version, 64% in Austria run PHP 8.1 or older, 57% in Germany and 81% in Switzerland, and 73.5% across all countries. Services are counted by IP location, not websites. That shows the direction, not exposure.

How cloud providers, platforms and hosts reacted to php2shell

Four patterns run through the reactions of 21 October (times in CEST unless UTC is stated). They help you place your own situation.

Protection before the release. Cloudflare switched on a default protection at 03:02 UTC for all customers with the WAF enabled and calls it an additional layer of defense that you keep active while patching. Anyone behind a WAF gains time but is not patched, and according to AWS, a WAF technically cannot see parts of the flaw.

Patched automatically. Some platforms did this without customers lifting a finger: Shopware for its SaaS shops, and Google Cloud is rolling out patches for App Engine Standard (PHP 8.2 and newer) and for Cloud Run with automatic base image updates. Automattic reports its WordPress platforms as protected. Customers must rebuild their own containers themselves, and at Google Cloud, discontinued runtimes are not patched.

Switching off until patched. The Dutch host Mijndomein took all customer websites offline and brought the hosting packages back online from about 6 pm. mittwald shut down all systems from 4:17 pm. IONOS switched off Nextcloud instances, the universities of Freiburg and Bochum took web services offline as a precaution or blocked them for external access, and numerous Dutch government sites went offline. That is no proof of successful break-ins, the sources name caution as the reason.

Release does not mean protected. Hosts needed hours too. Hetzner had patched PHP 7.4 and 8.0 to 8.5 on web hosting and managed servers by the evening, with older versions still pending. mittwald reported at 9:54 pm that the patches for 8.2 to 8.5 and for LTS versions were on the home straight, and only at 12:28 am did all versions from 5.6 count as patched. IONOS has been rolling out the update on all systems since 5:44 pm, planned within 24 hours. At Mijndomein, the Plesk update was ready at 4:30 pm and the rollout took until about 6 pm.

What earlier cases show: the window is short

With Log4Shell, the first exploitation attempt came nine minutes after disclosure, according to Cloudflare, and limited testing had happened there eight days earlier. With the PHP-CGI flaw CVE-2024-4577, which only affected Windows, a proof of concept was online one day after the fix, and a few days later ransomware used the flaw, according to Imperva. Mandiant measures an average time to exploit of five days for 2023, excluding 15 outliers, and 47 days with them.

Two lessons carry over. First, a patch does not automatically end the incident: with Citrix Bleed, stolen sessions stayed valid after the patch, and with Drupal in 2014, the update did not remove backdoors. Second, vulnerable systems disappear slowly: with Heartbleed, around 300,000 servers were still open a month after disclosure.