PHP2Shell: why many websites went dark this week, and what to do next

A flaw in one of the internet’s most common building blocks forced organisations to take their websites offline. Here is what happened, why it matters, and what organisations should do next.

On Wednesday 21 October, government services, city websites, libraries and online shops across Europe and beyond went offline within hours of each other, not because they had been hacked but as a precaution to protect themselves.

The reason was a serious security flaw in PHP, the programming language that runs behind most of the world’s websites. Visitors never see it, but it is what turns a website into a working service by handling logins, shopping baskets, forms and the connection to the database behind them. The flaw, called PHP2Shell, could let an attacker take control of a web server without a password. Because the details leaked before a fix was ready, security authorities in several countries advised organisations to switch off vulnerable services until they could update them.

Security flaws are found all the time, but most affect a single product or company. This one sits in software that millions of websites share, so all of them became vulnerable at once.

A fix was released later on Wednesday, and while many services are already back online, others will take days or even weeks to restore.

Why this matters beyond this week

Security researchers from Calif, Wiz and OpenAI discovered the flaw in August, using AI tools as part of an OpenAI initiative to find weaknesses in widely used software. The problem had existed in PHP for years, but it was considered too complex to exploit until AI made the work far easier. The plan was to publish the details together with a fix, giving organisations time to update, but information leaked before the fix was ready.

The same AI tools are now helping both researchers and attackers find vulnerabilities faster than ever, and we expect the number of discoveries to keep growing, so organisations should be ready to respond quickly when the next one comes.

Organizations were asking themselves the same questions:
Are we affected?

If your organisation uses anything built on PHP, assume you are until you have checked. The difficulty lies in knowing where PHP is in use, since it is rarely limited to the public website and can sit in internal applications, an online shop, an intranet, or software bought from a supplier that you cannot update yourself.

Most organisations know how to fix a vulnerable component once they know where it is, so the real problem is visibility, as many companies simply do not know whether they are vulnerable.

Have we been breached?

This is the question we have heard most this week, and installing the update does not answer it. Attackers were already trying to exploit the flaw before the fix came out, which means a system updated on Wednesday may still have been targeted earlier. If you do not have continuous security monitoring in place, ask your IT or hosting provider to review your systems for unusual activity over the past weeks.

Our Security Operations Centre has been monitoring customer environments for more than a decade, which gives us a clear view of where vulnerable PHP components sit in the systems we watch and whether anything unusual has happened on them. Over that time, we have seen widely used software exploited at scale on several occasions, and our detection is built to catch attacks on web application vulnerabilities such as this one.

What should we do next?

The exact steps depend on your setup, but the order of work is the same for everyone:

• Find out where PHP runs in your organisation, including internal systems and supplier software.
• Update to a fixed version. Older versions (PHP 8.1 and earlier) are no longer updated by the PHP project itself, but many operating system and hosting vendors have released patched versions. If none is available for your setup, a larger upgrade is needed.
• Restart every service that uses PHP, so the old, vulnerable code is no longer running.
• Ask your suppliers whether the software they provide has been updated.
• Check whether your systems show signs of earlier compromise, starting with those visible on the internet.

For IT teams, the vulnerabilities are CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you use PHP from your operating system vendor, check the vendor’s security advisory, as patched packages often keep their old version number.

Why are some websites still down?

The longer a site stays offline, the bigger the job behind it tends to be. Long outages usually point to outdated software versions and a large backlog of updates, which is technical debt becoming visible.

Author