Yesterday our team spent the day updating our clients’ servers. The reason is called PHP2Shell, and if your store or company website runs on PHP, this story is about you too. Chances are it does, because most of the web runs on PHP.

9.2out of 10 on the severity scale, according to the PHP team
5.4the vulnerable code goes back to this PHP version, about 14 years
45 minafter disclosure, Cloudflare was already counting tens of thousands of attack attempts

What actually happened

Let’s start with the basics. PHP is the language Magento, WordPress, Drupal and countless stores and business systems are written in. PHP2Shell is two flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. They let anyone run code on the server without logging in1. Put simply: a stranger can take over the server your store runs on.

The story has a few twists:

  1. August 2026Two teams, Calif and Wiz Research, independently find the bugs in PHP with the help of AI models. Wiz reports them to the PHP team on 24 August2,3.
  2. 17 OctoberAmazon records the first attack attempt, four days before the fix is published4.
  3. 20 OctoberDetails leak on Hacker News before the embargo ends5.
  4. 21 October, 14:00 UTCThe PHP team releases fixed versions a day earlier than planned and urges everyone to update now1.
  5. 21 and 22 OctoberAccording to Cloudflare's CEO, attack attempts climb from tens of thousands in the first 45 minutes to millions6.

Why it’s so serious

Most flaws we read about affect one plugin or one program. This one sits underneath, in the engine the whole site runs on. That’s why updating Magento changes nothing. Sansec, a firm that specialises in online store security, confirmed that a Magento 2.4.9 store can be taken over this way even when its own code is flawless7.

The second piece of bad news: one of the flaws lets an attacker read pieces of the server’s memory, which can hold passwords, session tokens and API keys2,7. Whoever takes over the store can go further, for example into the payment or warehouse system.

CERT Polska says plainly that every PHP version from 5.4 up is vulnerable and that the only real protection is installing a fixed version8. In Poland, some public services were briefly taken offline9.

The only effective way to protect yourself is to install a fixed version of PHP. CERT Polska, advisory 196/2026 (own translation)

Why flaws like this keep coming

This bug sat in PHP for over a decade. It was only found by researchers who searched the code with the help of AI models. Wiz wrote that a single researcher using AI did in a week what used to take a world-class team months2.

Here’s what that looks like in numbers:

48,185new CVE-numbered flaws in 2025, 20.6% more than the year before
−7 daysaverage time to exploit in 2025 according to Mandiant: attacks start before the fix
23.43%of exploited flaws were attacked on or before the day they were published (first half of 2026)

The number of reported flaws grows every year12. According to Mandiant, in 2018 it took an average of 63 days from disclosure to the first attack; in 2025 attackers were starting an estimated 7 days before the fix was out10. VulnCheck counted that almost one in four exploited flaws was attacked no later than the day it got its CVE number11. Back in 2025, AI systems in DARPA’s challenge found 54 of 63 planted bugs, plus 18 real ones nobody knew about13.

AI helps both sides. The same tools that found PHP2Shell let attackers build exploits faster, and OpenAI says so openly3. For a store owner this means the gap between a flaw going public and the first attack is now measured in hours. With PHP2Shell, attacks began within tens of minutes6.

What we did for our clients

We follow security advisories as they come out. When the PHP team released the fixed versions, we updated PHP for our clients the very same day.

Then we went through every store and server we look after, so none was left on a vulnerable version. Our clients got a message from us saying whether the flaw affected them and what we’d done, before they had time to ask.

That’s how I think looking after a store should work. When things heat up online, the owner shouldn’t have to hunt for a developer and explain what’s going on.

What to do if you’re not our client

If someone else looks after your store, or you manage the server yourself, here’s today’s list, based on guidance from the PHP team, CERT Polska and the US agency CISA1,8,15:

  1. Update PHP. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are safe. Restart the PHP processes after updating.
  2. Ask your host to confirm in writing. Ask which PHP version runs on your server and when it was updated.
  3. Don't rely on a firewall alone. Cloudflare's rules help, but attackers are already getting around them14.
  4. Check your logs from 17 October. That's when the first attack attempt was recorded4.
  5. Change passwords and API keys. They may have leaked from the server's memory before the fix went in2.
  6. If PHP can't be updated, take the site offline or put it behind a firewall. That's CISA's advice for systems that can't be patched right away15.

How to stay safe in the age of AI

This year the US agency CISA cut the deadline for fixing the most dangerous flaws to 3 days, and named AI as the reason16. At that pace, a store updated once every few months is left unprotected for weeks.

For us, security is a standing part of looking after a project. We follow vulnerability advisories, update servers as soon as a fix is out, and tell clients before they start to worry. We work with AI agents ourselves, but in isolated environments with no access to data, and they do nothing in production without a developer’s supervision. I write more about it on The AI edge page.

If you remember one thing from this post, let it be this: in the age of AI, what counts is how fast someone reacts on your behalf.