AI found PHP’s hidden flaws. Is your SOC ready for what comes next?
- Date: 28 October, 2026
If your organization runs websites, there is a good chance PHP sits somewhere underneath them. On 21 October 2026, the PHP project released emergency fixes for two critical flaws now known as PHP2Shell. Within hours, governments, hospitals and household names took websites offline while their teams patched.
The headlines were dramatic and some of that drama is justified. But PHP2Shell is also a story about what works. The organizations that came through it well knew what they were running, patched quickly, checked their work and kept a close eye on their logs. Every one of those is a capability your people can build, and this blog will show you how.
What is PHP2Shell (in plain terms)?
PHP is the programming language behind roughly seven in ten websites whose server-side language can be identified, including WordPress, Drupal, Joomla and Magento sites (iTWire). PHP2Shell is the name for two flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and each rated 9.2 out of 10 for severity (Unit 42).
Both flaws let an attacker run their own code on a web server without logging in. Because they sit in PHP rather than in any single website, updating a content management system or its plugins does not fix them. The PHP interpreter itself has to be updated.
The scale is eye-watering. Palo Alto Networks counted more than 22.6 million exposed instances that may be vulnerable (Unit 42), and many of those run PHP versions too old to receive official fixes.
What happened, and at what pace?
The timeline shows how little warning defenders now get.
Date | What happened |
17 October | Amazon’s honeypots logged an exploitation attempt, four days before public disclosure (iTWire). |
20 October | The vulnerability identifiers leaked online, and PHP brought its release forward by a day. |
21 October | PHP released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Government sites in the Netherlands, France, Finland, Belgium, Germany and Australia went offline as a precaution. |
22 October onward | National cyber agencies urged immediate patching, and security vendors reported attack activity in the wild. |
The flaws sat in PHP’s code for more than a decade. They were found with the help of AI models, and that is part of why the window between discovery and attack was so short.
Why do attacks like this feel different now?
The biggest change is speed. AI is helping researchers find old flaws faster and it is helping attackers turn them into working attacks faster too. Arctic Wolf’s Ismael Valenzuela put the shift well, “the question is no longer how quickly a patch arrives, but how quickly you can spot exposure and stop one compromised system from becoming many.” (iTWire)
The same week brought a glimpse of what machine-speed attacks look like. Palo Alto Networks Unit 42 reported an attack on a European government agency through a vulnerable PHP application, where attackers reached password hashes and multi-factor authentication secrets within two hours. Unit 42 saw strong signs that an AI agent, not a person at a keyboard, was running the attack. It has since said it cannot confirm that PHP2Shell was the way in (Unit 42).
Whatever the entry point, the lesson stands. A human intruder might take days to move from a web server to the heart of a network. An automated one can do it in an afternoon, so defenses that rely on someone noticing an alert tomorrow morning are already too slow.
Five steps to take right now
The good news is that the fix is available and the steps are well understood. If your teams work through these five, you will have closed the immediate gap and be better placed for the next one.
- Update PHP itself, not just your website. Move to a fixed version, rebuild container images, then restart web servers and PHP workers so the fix actually takes effect. Confirm the version that is running, not just the one installed.
- Find the PHP you didn’t know you had. Appliances, hosting panels, cloud images and vendor products often include PHP. Ask your suppliers to confirm their patch status.
- Keep the web tier separate. Web servers should not be able to reach directory services and domain controllers directly. Limit what they can connect to, inside and outside your network.
- Assume credentials may be exposed. If a PHP server sat unpatched after 17 October, rotate the database passwords, service account credentials and API keys it could reach, and re-enroll any authentication secrets it held.
- Look back, not just forward. Keep your logs and check them for signs of earlier compromise: unexpected processes started by PHP, unusual upload requests and repeated worker crashes. A successful patch should not close the ticket on its own.
How can Global Knowledge help your teams?
Patching closes this hole. The next one will arrive the same way, and the gap between disclosure and attack is now measured in hours. What limits the damage is people who know what to look for at every stage, from the exposed server to the boardroom.
At Global Knowledge, we offer instructor-led cybersecurity courses mapped to each of those stages. Here is where they fit.
Stage of an attack | Who stops it? | Courses that prepare them |
The new attacker, AI: AI agents running the attack, AI should do the defence | Security architects, red teams, AI governance and risk leads | |
The way in: an unpatched server facing the internet | Vulnerability analysts, application security and DevSecOps engineers, penetration testers |
|
The pivot: stolen passwords and authentication secrets used to reach the directory | Identity and access engineers, directory and Windows administrators | |
The clock: hours, not days, from first access to serious damage | SOC analysts, threat hunters, incident responders |
|
The boardroom: leaders deciding fast with incomplete facts | CISOs, security managers, business leaders |
Every course is taught live by instructors who work in the field, and most prepare for a recognized certification. Courses run online, in the classroom or privately for your organization, so a team can train together on the stage where it is thinnest.
The next one is coming. Your teams can be ready for it.
OpenAI’s Greg Brockman has said he expects many more flaws like this to surface in the coming months (iTWire). That is not a reason for alarm. It is a reason to make sure the people who run your web tier, your identity systems and your security operations know exactly what to do when the next alert lands.
Not sure where your gaps are? Talk to our team. We will map your web, identity and security operations teams against the six stages above and suggest a learning path that fits how you work.
Sources