php2shell and AI attacks: what you should expect from your software agency now

In short: php2shell is the name of two critical security vulnerabilities in PHP that became public on 20 October 2026 and affect every website and app running PHP 5.4 or newer. The case shows that attacks on websites and apps now run automatically and are getting faster with AI. Whoever develops and runs your software therefore needs to test it for vulnerabilities more often and roll out security updates within hours instead of days. Five questions show you whether your agency is prepared.

php2shell: what happened, and are you affected?

On 20 October 2026, two serious security vulnerabilities in PHP became known under the name php2shell. PHP is the programming language that a large share of all websites run on, including every WordPress site. The vulnerabilities allowed attackers to take over servers without needing a password.

The updates followed on 21 October. Attack attempts were observed the same day, and according to the network provider Cloudflare they began hours before an update even existed. Amazon reports that the first attempts against decoy systems were already running on 17 October, three days before the vulnerability became public. CERT-EU, the IT security team of the EU institutions, advised taking affected sites offline if necessary. Some did.

What mattered that day was mainly organisation. Anyone who knew which systems were affected and who would install the update was done the same day. Anyone who first had to search was not.

Are you affected? If your website or app runs on PHP 5.4 or newer, yes. It is only safe with a current update of versions 8.2 to 8.5. For older versions there is no official update. The options there are a move to a supported version or a fix that your hosting provider backports to the old version itself. If you cannot answer this yourself, ask your agency or your hosting provider which version you are running and whether the update has been installed.

If your software does not run on PHP, this vulnerability does not affect you. The next one can hit any other component your software is made of. That is what this text is about.

Why automated attacks hit everyone, and how AI makes them faster

Most attacks on the internet have no specific target. Programs known as bots automatically probe every reachable website and latch on wherever something is left open. According to Imperva, around half of all web traffic now comes from bots, and just over a third of all traffic from malicious bots. ‘We are too small to be interesting’ is therefore not true. The bots do not know you; they only know your vulnerability.

What is new is that AI language models make these bots more adaptable. The AI provider Anthropic analysed accounts it had banned for misuse: two thirds of them used the AI to develop malware. In April 2026 the same provider said its new model finds security vulnerabilities better than almost all humans, and initially released it only to a small group.

What one model finds for defenders, another can find for attackers. I am not aware of a documented case in which an AI found and exploited an unknown vulnerability on its own. I still expect that attackers without deep expertise will soon be able to use a capable language model, and that the window between a vulnerability becoming known and the first attacks will keep shrinking. With php2shell, attacks were running before an update existed. The same pace applies to code that was developed specifically for you: models that find vulnerabilities in PHP can find them there too.

What this means for your software

Two things have to change: software must be checked for vulnerabilities more often, and security updates must go live much faster. Both are ongoing tasks in day-to-day operation that only begin at launch.

It helps to separate two cases. With managed hosting, the host keeps the foundation up to date, such as PHP or the server’s operating system. Only the people who built your application know its own components. For a simple website, a host like that plus regular updates from the agency is therefore enough. For a portal, a platform or an app with its own code, you need the process I describe below.

Security testing before every release instead of once a year

In a penetration test (pen test for short), an attack on your system is simulated to find vulnerabilities before real attackers do. In our experience, external pen tests cost from €20,000. That is why they are rare, even though new code goes live continuously between two tests.

AI changes this. An AI agent is an AI program that works through tasks on its own. Before every release, meaning before every new version, it can look for typical vulnerabilities and try them out against the running application. This does not replace an external pen test, which remains mandatory in regulated industries. But the AI test closes the gap between two external tests.

Security updates in hours instead of days

Nearly all software is built largely from ready-made components from other vendors. Any one of them can be the next php2shell tomorrow. When that happens, two questions count: are we affected? And when is the update live?

The first question should be answered in under an hour, and the second dealt with in a few hours. That only works if the check runs automatically, the system is documented and fixed capacity is set aside for maintenance. A software agency that has handed your project over after launch, and in an emergency has to start by ‘finding someone’, cannot do this.

Five questions to ask your software agency

You do not need to be a technical expert to check whether an agency is prepared. The questions apply to the agency that looks after your system today, just as to any agency pitching for your next project. I would ask them of any agency, including our own:

1. How often is my software tested for security vulnerabilities? Only before launch, or with every update?
2. How quickly do you know whether my system is affected by a new vulnerability? Is there an automatic overview, or does someone search by hand?
3. How quickly is a security update live, and who takes care of it at short notice? Is there fixed capacity, or only an offer on request?
4. Is there up-to-date documentation of my system that any team can pick up and work from straight away? And do I hold it?
5. What data do AI tools working on my system see, and where is it processed?

If a question stays open, you know where operations are falling short today. Then you have two options: build the process with your agency, or give your next project to a team that already has it. The same applies if your software is maintained in-house.

How we put this into practice at Sprylab

We develop platforms, portals and apps and then run them ourselves. The weekly check of all components runs for the systems we look after under a maintenance contract, and we are introducing the pen test before every release step by step. Our target times for these systems:

If there is no update yet for a vulnerability, we inform you of critical findings and set out your options: wait, take the system offline temporarily, or commission a manual workaround.

The basis for this is our spec-driven development. Every new project gets a spec: structured documentation directly in the code that people and AI agents can read equally well, including an operations manual and security standards. For an existing system, a first version is ready in about a week. The spec lives in your code and goes with you if you switch. More in my column on documentation in the code.

If you are commissioning platform development or app development with us, we build and run your system ourselves, using the processes above. If you want to know where your existing system stands today, I am happy to go through it with you, question by question, in a free call: