PHP2Shell: what happened, and what to check

On 21 October, PHP released an urgent update. If you have never heard of PHP, you have almost certainly used it. It is the software that runs behind most of the websites you visit: nearly every WordPress site, along with Drupal, Joomla, and a great many company websites and online shops.

The update fixes two flaws that researchers named PHP2Shell. This is what they are, why they matter, and what to do, without the jargon.

What is PHP, and why does it matter here?

Every time someone opens a page on your website, a computer somewhere, the server, builds that page and sends it back. On most of the web, PHP is the part of the server doing the building. It reads the request, fetches what it needs and puts the page together.

So PHP sits at the front door of the server. Whatever reaches PHP is, in a sense, already inside.

What actually went wrong?

A useful way to picture it is a hotel. Each visit to your website is a guest who gets a room for a moment. When they leave, the room is cleaned for the next guest.

The researchers found that if a guest left in a very particular, messy way, the room was not cleaned properly. Something of theirs was left behind, and the next guest would use it without knowing. A careful attacker could book both visits: leave something behind on the first, and have it run on the second.

On a real server, “something left behind” means instructions. Once an attacker’s instructions run on your server, they can read your data, change your site, or use the server for something else. Security people call this remote code execution. It is about as serious as website flaws get, and it required no password at all.

How long was it there?

About ten years. According to Wiz, the research firm that found it, every PHP version released in the past decade carries at least one of the two flaws, going back to PHP 5.4.

The dates are worth knowing:

• 19 August. The first flaw is found.
• 20–21 August. The researchers prove they can take over test Drupal and WordPress sites.
• 24 August. They tell PHP’s security team, privately.
• 21 October. PHP releases the fix, and the research is published the same day.

This is how it is meant to work. The people who found it gave PHP two months to build a fix before telling anyone else. Wiz reports no attacks seen before the announcement.

Why is everyone talking about AI?

Because AI did a large part of the finding. Wiz used AI models from Google and OpenAI to search the code, build working proofs, adapt them to different setups and check the fixes. Their own estimate is that one researcher did in a week what would have taken a strong team months.

This flaw sat in plain sight for ten years because looking for it was slow, skilled work, and there are only so many people who can do it. AI has made that looking fast and cheap. This time it was used by the good side, and the fix came first. The same tools are available to anyone.

What does the PHP patch mean for a business?

In the short term, one task: make sure the update is installed. The safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Your host or developer can confirm it in a minute, and many hosts install these fixes without changing the version number you see, so ask rather than guess. If you are on PHP 8.1 or older, the upgrade you have been postponing is now due.

There’s a longer lesson as well. The parts of a website most at risk are the ones nobody looks at: the plugin installed for a campaign years ago, the old theme, the admin page one person remembers. Those used to be safe because they were boring and finding their flaws took effort. With AI doing the reading, they are the first places anyone will look.

The websites that come through weeks like this calmly are small, current and owned by someone. That is less about PHP and more about how a site is looked after. PHP itself, once patched, is a perfectly sound place to be.