php2shell: what the PHP flaw tells us about tomorrow's attacks

At 4 pm on 21 October 2026, things got serious for a lot of site operators. The PHP project published patches for two critical flaws in the core of the language, soon known as php2shell. Anyone running PHP on the web, which is roughly three quarters of all websites, was affected. The first mass scans ran that same evening. Some operators took their sites offline; administrators worked through the night.

The case is more than another security advisory. It shows, in fast forward, how attacks unfold in 2026, and it shows what companies need in order to get ahead of them. We followed php2shell on our own servers and on those of our clients. This is what we take from it.

What happened on 21 October

The two flaws carry the identifiers CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. The first allows foreign code to run when PHP runs out of memory while cleaning up a request. The second lets leftovers of one request live on into the next one on the same worker. Together they give attackers what they are after: running code without logging in.

Every PHP that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The patches shipped as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older only received minimal source backports; 7.3 and older received nothing. The distributions followed: Ubuntu published its packages on 21 October at 16:07 CEST, Debian the same day.

Then it moved fast. According to Amazon Threat Intelligence, the first proof-of-concept exploits circulated before the embargo lifted, and the first attack attempts against honeypots followed within hours. The US agency CISA added both flaws to its catalogue of actively exploited vulnerabilities. On 23 October the PHP project issued a further advisory (CVE-2026-115560), an additional route via the session upload progress feature.

Why this flaw was different

Most security advisories that reach companies concern an application: a WordPress plugin, a shop module, a library. You update the plugin and you are done.

php2shell sat underneath. PHP processes the malicious request before a single line of the actual application runs. That is why no login, no role management and no plugin update helps. Datadog Security Labs puts it plainly: application-level authentication cannot block the attack. And the workaround that circulated in forums, disabling the session upload progress in the PHP configuration, closes only one of the routes. Only the update closes them all.

For companies, this means the question was not “which plugin do we use?” but “which PHP runs on which server, from which source, and who applies the update?”. Anyone who could not answer that within minutes on 21 October had a problem.

Three patterns php2shell reveals about tomorrow

The attack arrives before the patch. Amazon observed the first attack attempt on 17 October, four days before disclosure. How the attackers obtained details that early is unknown; according to Huntress, information about the flaws was online on 20 October. Amazon draws the conclusion itself: investigations must start from the earliest known exploitation, not from the disclosure date. If you only check your logs from 21 October, you are looking past the gap.

Scanners need hours, not weeks. There were no days between patch and mass scan any more. What used to be a weekend of buffer is now an afternoon. An update scheduled for the next maintenance window “sometime in the next two weeks” comes too late.

AI makes both faster. In October the TÜV association and the German Federal Office for Information Security (BSI) published their AI security study 2026: 17 percent of the companies surveyed reported a confirmed or suspected AI-assisted attack in the past twelve months. Around 40 percent of those cases involved automated attacks on IT vulnerabilities. Only 11 percent of companies using AI have dedicated processes for such incidents. We described how attackers use AI to find gaps and run attacks in series in AI versus AI. php2shell was the first major case where that speed could be measured.

Looking ahead instead of reacting

You cannot predict the next flaw. You can predict that it will come, and set yourself up so that it does not trigger an emergency. Four things proved their worth during php2shell.

An inventory that answers the question. Which server runs which PHP, from distribution packages or third-party sources, and when does support end? If you have that in a table, you know within minutes where it burns. Anyone running PHP 8.1 or older also knew on 21 October: no regular patch is coming here. That is a migration project, not an update.

Security updates within hours, not weeks. The distributions had the patches on 21 October. Everything after that is a matter of your own processes. For our servers and those of our clients, our maintenance service Sentinel takes care of this: every ten minutes it checks for open security updates, cross-references them with the distribution’s notices and the CISA catalogue, and applies them, with a backup before and a check afterwards. php2shell also taught us a lesson, which we documented openly in the chronicle: back then Sentinel still waited for the maintenance window the next morning, 14 hours after Ubuntu’s notice. Since then security updates are applied immediately and only ordinary updates wait. Learning from the case is part of the job.

Know your attack surface from the outside. A patching service closes the gap in the system. It does not see whether the application on top is vulnerable itself, whether a forgotten staging system is still online, or whether an old upload folder executes code. For that you need the view an attacker has: a penetration test. We currently offer it free of charge, precisely because cases like php2shell show how much unnoticed surface there is.

Check logs from the earliest date. For php2shell that means from 17 October. Watch for very large or deeply nested form data, memory errors at the start of a request, crashes of individual workers and shells spawned by web server or PHP processes. No single signal proves anything; the combination does.

Checklist for the coming week

1. Check your PHP build, the package, not just the version number. On Ubuntu and Debian, apt-get changelog php8.3 | grep -m1 CVE-2026-109619 shows whether the fix is in the installed package.
2. Find third-party sources. PHP from Docker images, hosting panels or your own builds does not get the update from the distribution.
3. Lift PHP 8.1 and older to a supported version. This was overdue; php2shell merely made it visible.
4. Review logs from 17 October for the patterns above. If you suspect something: do not patch and hope, preserve the evidence.
5. Define the process: who applies security updates, within what time, with which backup? If the answer is “a colleague, when they have time”, that is where it will fail next time.

Conclusion

php2shell was not an exception but a preview. Attacks begin before the patch, scanners need hours, and AI keeps shortening both. Companies do not win by reacting faster on day X but by being prepared: an inventory that gives instant answers, security updates that run without a night shift, and a regular look from the outside.

If you want to know where your systems stand today, start with the view from outside: our security check is free of charge, confidential, and ends with a prioritised list instead of a gut feeling.