PHP2Shell is fixed. Our systems were updated the same day.

Most websites on the internet run on PHP: WordPress, WooCommerce, Laravel applications, corporate sites, B2B portals and e-commerce platforms. On 21 October 2026, two critical vulnerabilities were disclosed in the language itself, the engine underneath every application built on it. The security community named the pair PHP2Shell.

The most important point first: on the servers Globya manages, PHP was upgraded to the patched release on the day the fix was published. The customer systems we host and maintain were updated with the same checklist and placed under monitoring. Below we explain what the flaw is, why it is taken so seriously and how we responded.

What is PHP2Shell?

PHP2Shell is the common name for two separate flaws in the PHP core. The name is not official; it spread from a screenshot of an exploit tool that leaked before disclosure.

In plain terms: an attacker needs no username or password. By sending specially crafted requests, they can trigger a memory-handling bug in PHP and run their own code on the server. According to reports, the attack can succeed before the application's own code even starts running. So how carefully your site is written, which plugins it uses or whether a security plugin is installed does not protect you on its own; the problem is in the platform itself.

Why is it so serious?

• The reach is very wide. All common setups that serve web requests are affected, including PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. Some researchers say affected versions go back to PHP 5; this scope has not yet been confirmed in the official advisory.
• Details leaked early. Disclosure was planned for 22 October, but details spread a day earlier. The PHP team brought the fix forward as an emergency release.
• Exploit code is public. The Dutch National Cyber Security Centre (NCSC-NL) said several public proof-of-concept exploits exist and that it expects large-scale exploitation soon. Some security firms reported first attack attempts in their honeypot networks.
• No patch for old versions. The official fix was released only for the four supported branches. Sites on PHP 8.1 or older, PHP 7 or PHP 5 get no official update.

An attacker who can run code on a server can reach customer data in the database, plant malware on the site or use the server for spam and attacks. Under data protection law this is a direct data breach risk.

Which versions are safe?

Small backport patches were shared for PHP 7.4, 8.0 and 8.1 for those who build from source, but the lasting fix is moving to a supported version. The UK National Cyber Security Centre (NCSC) recommends taking systems that cannot be updated right away offline until they are.

What did Globya do?

With a flaw like this, time is the most important variable. In the first hours after disclosure we completed these steps:

1. We upgraded PHP on our servers. The PHP versions running Globya's sites, the Glommand management panel, the customer portal and the sites we host were updated to the patched releases (8.3.36 and 8.5.12) on 21 October.
2. We went through customer systems one by one. On the systems we host and maintain for customers, we checked PHP versions and applied the security updates.
3. A separate roadmap for old versions. Where an application is tied to an unsupported PHP version, we plan the upgrade together with its owner and restrict and closely monitor access until the move is complete.
4. We tightened monitoring. Server logs are being watched for unusual request patterns, unexpected process crashes and suspicious file changes.
5. We treat telling you as part of the job. This post is part of that: we share what we did without waiting for customers to ask whether they are affected.

We see security not just as a software update but as keeping watch on your behalf, continuously. If your website, e-commerce platform, portal or email runs on our servers or under our maintenance, there is nothing you need to do for this flaw.

If another company or you yourself manage your site

We recommend going through this checklist today:

• Find out your PHP version. Ask your hosting panel or provider for the exact version number. "PHP 8" is not enough; for example 8.3.35 is vulnerable, 8.3.36 is safe.
• If you are not on a supported branch, plan the move. There is no official patch for PHP 8.1 and older. If an old WordPress theme or legacy software keeps you on an old version, this can no longer wait.
• On shared hosting, ask your provider. They, not you, must apply the update; ask in writing when they did.
• Look for forgotten installations. Old campaign sites, test environments and old panels on subdomains are often the weakest link.
• If you use a WAF, enable its rules, but do not treat them as a substitute for patching. Services such as Cloudflare published interim rules for known attack vectors; these are only an extra layer.
• Review your logs. If you have seen unusual PHP process crashes, unexpected new files or admin accounts since 20 October, have an expert look into it.

Frequently asked questions

Sources: PHP security advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp), Help Net Security, SecurityWeek, The Hacker News, watchTowr, Huntress and NCSC-NL statements, 20–21 October 2026. Information on this flaw is changing quickly; we will add new developments to this post.