PHP2Shell: 1.9 Million Websites in Europe Are Still Vulnerable
Set Trending Topics as a preferred source on Google.
One half was secure within hours, the other half has been waiting for years for an update that will never come.
A week after the emergency update for the PHP programming language, a complete picture for Europe is available for the first time. Vienna-based risikomonitor.com, which specializes in cyber risk monitoring, surveyed the websites of all 27 EU member states, Switzerland and Liechtenstein together with EY Austria. On the day of disclosure, 3.9 million websites with a visible PHP version were vulnerable, 11.2 percent of the 34.9 million reachable websites. Within days, that share fell to 5.6 percent. What remains, according to the study, is not a problem of stragglers but a legacy issue: Four fifths of the still vulnerable servers run on PHP versions that have not received security updates for years.
What PHP2Shell Is
PHP2Shell is the collective name for two vulnerabilities in the core of PHP (CVE-2026-109618 and CVE-2026-109619), both rated critical at 9.2 out of 10. They allow attackers to execute their own code on the server without logging in. The PHP project announced an emergency release on October 20 and provided the fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 the following day. There are no more official updates for PHP 8.1 and older. The flaws were discovered partly with the help of AI models, and in Austria, universities, chambers and corporations took their websites offline as a precaution. According to Amazon, the first attacks started four days before the patch, and Cloudflare counted millions of attack attempts afterward.
The First Wave: Faster Than Heartbleed
Before October 21, there was no fixed PHP version, so on the day of disclosure every website with a visible PHP version was exposed. At the first measurement, half of them were already running a fixed version, faster than in earlier major flaws such as Heartbleed in 2014, according to risikomonitor.com. That points to automatic updates at hosters and managed platforms: 15 large providers account for 60 percent of the vulnerable websites, and where a hoster maintains PHP centrally, its customers are protected without doing anything themselves.
Carinthian cloud and hosting provider Anexia showed what that looks like in practice. On the morning of October 21, the company informed customers about the flaws on its status page, and in the early afternoon it decided to take all managed services running PHP completely offline at 3:45 p.m. as a precaution, a quarter of an hour before the patch was released. The reasoning: The known workarounds offered no effective protection, and a working exploit was to be expected right after the patch. After the release at 4 p.m., Anexia rolled out the new versions and brought the systems back online step by step after testing. Around two thirds of the affected systems were running again by early evening. Customers whose older PHP and operating system versions had no fix yet were contacted individually.
“PHP2Shell has shown how fast it can go when hosters act centrally,” says Manuel Löw-Beer, founder and CEO of risikomonitor.com. Providers with managed offerings are already obliged to apply security patches within a reasonable period under NIS2 and the European implementing regulation, he adds. But not all hosters are in the same position: At OVH, Hetzner and Amazon, the affected machines are most likely servers under the customers’ own responsibility without a managed service. There, only direct outreach to the operators helps.
Then the Curve Flattens
After the first wave, progress slows. Of the re-checked and reachable affected sites, only 18.1 percent had followed up by October 28. Initially around four percentage points were added per day, afterward only around 1.5. Part of the latest increase does not even come from patches: In the Netherlands and Belgium in particular, tens of thousands of websites simply no longer display their PHP version, and whether they are patched remains open.
The reason for the sluggishness: Those still vulnerable today usually cannot simply update. 80.9 percent of those affected run on PHP branches whose support has expired, above all PHP 7.4.33, which has received no fixes since November 2022 and, with 433,064 websites, is the most common vulnerable version in Europe. On average, these servers have been waiting 4.7 years for an update. 18.3 percent of those affected, around 328,000 websites, have been running without a security fix for more than seven years, 6.7 percent for more than ten.
For these servers, PHP2Shell is only the latest of many flaws. Matching the version levels against the US vulnerability database NVD, each vulnerable server has an average of 72 known PHP vulnerabilities open, 22 of them critical. The legacy burden is greatest in Denmark with 138 open flaws per server, where 11,637 websites alone run on PHP 5.2.17 from 2011. “Anyone still running PHP 7 or older does not need an update but a migration to a current version. That should happen now, not at the next incident,” says Löw-Beer.
Austria on Average, Germany at the Bottom
In Austria, 46,182 of 1,059,104 reachable websites reported a vulnerable PHP version, which corresponds to 4.4 percent and is below the European average of 5.6 percent. At the follow-up measurement, 28,622 were still vulnerable and 6,322 had patched, a patch rate of 18.1 percent, exactly the European average. Hotels and guesthouses are most frequently affected in Austria, followed by medical practices and car repair shops. With 68 open flaws per server, Austria is just below the European average.
Germany has the most vulnerable websites in Europe at 426,854, 94.5 percent of which run on versions without security updates. At the follow-up measurement, 259,891 websites were still vulnerable and only 15,953 had patched, a patch rate of 5.8 percent, the lowest in Europe. The fastest were Lithuania (39.7 percent), Cyprus (38.7 percent) and Malta (38.1 percent). In Switzerland, 54,246 websites (3.0 percent) reported a vulnerable version, with 22,286 still open at the follow-up. Portugal has the highest share of vulnerable websites at 14.4 percent, Slovakia the lowest at 2.5 percent. Germany, the Netherlands and France together account for half of all affected sites in Europe.
Hotels, Shops and Their Customers
Where those affected can be assigned to an industry, hospitality, retail, transport and gastronomy together make up almost half. It mainly hits small businesses that have their websites built externally and have no IT security of their own. Almost nine out of ten websites with a recognizable content management system run on WordPress, and more than 19,400 online shops run on PrestaShop, Magento or Shopware.
That means the flaw reaches beyond the operators. Anyone who takes over a shop server can skim customers’ payment data at checkout, as a Europol-coordinated operation involving 443 compromised online retailers has shown. Other campaigns use hacked websites to push malware onto visitors disguised as a fake browser update. “The changed threat landscape makes it necessary to critically question cyber strategies and information security measures and, in particular, to align them with the increasing use of AI on the attacker side,” says Gottfried Tonweber, partner at EY.
What Operators Should Do Now
Operators should update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and then restart all PHP processes. Updating WordPress or another application alone is not enough, what matters is the PHP version on the server. Anyone still using PHP 8.1 or older must switch to a supported version. For rented web space, the hoster is the right contact, for own or rented servers it is the operators themselves. Websites can be checked free of charge at php.risikomonitor.com.
The study itself names one limitation: Only the version identifier that web servers publicly send with an ordinary page request was evaluated. Websites that hide their version do not appear in the statistics, and Linux distributions or hosters that backport fixes into old PHP versions without changing the version number may be counted as vulnerable even though they are not. The number of open flaws per server should be understood as an order of magnitude, according to the authors.
