PHP2Shell: A wake-up call for the rest of us

At Prodigent we use Laravel for some of our systems, and we’ve already patched the affected PHP runtimes in our environment. As with any security issue of this severity, we’ve treated it as a priority.

But PHP2Shell is worth talking about for reasons beyond the immediate vulnerability. It’s a reminder of how much of the internet rests on software we rarely think about, how quickly AI is changing security research, and why engineering teams need to be prepared for more of these events.

What happened?

PHP2Shell refers to critical vulnerabilities in PHP itself that can, under the right conditions, allow an attacker to execute arbitrary code on a vulnerable server through specially crafted HTTP requests.

The important distinction is that these vulnerabilities exist in the PHP runtime, below the application layer. They aren’t specific to Laravel, WordPress, or any other framework. Depending on the vulnerability and deployment configuration, application-level authentication and authorisation checks may never get a chance to run before the vulnerable code is reached.

PHP maintainers have released fixes, and affected deployments need to update their runtimes rather than relying on application-level changes alone.

For engineering teams, the immediate response is straightforward: establish whether you’re affected, patch the relevant components, and investigate whether there are any signs of exploitation. The broader implications are more interesting.

PHP is suddenly having a moment

There’s something a little surreal about watching PHP become the subject of announcements from major technology companies and national cybersecurity agencies.

For a language that has spent years being the punchline of programming-language debates, it’s quite a moment.

PHP has never entirely shaken its reputation. Depending on which corner of the internet you inhabit, it’s either a perfectly practical tool for building web applications or a relic of a less enlightened era of software engineering.

And, admittedly, incidents like this probably aren’t going to improve its public image.

But there’s an important detail that can get lost in those conversations: PHP runs an enormous portion of the web.

It powers WordPress, Drupal, and countless other applications and services. That includes mature systems that have been running for years, custom applications that nobody outside their original development team understands, and infrastructure that may have been quietly doing its job for a very long time.

When a vulnerability affects the language itself, the potential blast radius is enormous.

This isn’t just a PHP problem. It’s a reminder that the internet is built on layers of shared infrastructure, and a weakness in one of those layers can have consequences far beyond the project where it was discovered.

This is probably just the beginning

Perhaps the most interesting part of PHP2Shell isn’t the vulnerability itself. It’s what it tells us about the future of security research.

AI is increasingly capable of helping researchers discover vulnerabilities, reason about complex code paths, and turn obscure implementation details into working exploits.

That changes the economics of security research.

Some vulnerabilities have remained undiscovered for years, not necessarily because the code was particularly safe, but because finding and exploiting the flaw required an enormous amount of time, expertise, and experimentation.

AI can reduce that barrier.

We should expect more vulnerabilities to be discovered in foundational software, including software that has been considered mature, stable, and well understood. Some will be severe. Some will affect technologies that underpin a substantial proportion of the internet.

The uncomfortable implication is that the volume of security issues we need to respond to may increase, while the time available to respond to them decreases.

PHP2Shell may be an early example of what that looks like.

The surprising things AI can exploit

Something else stands out when looking at recent security research: many of the opportunities attackers exploit aren’t particularly exotic. They’re ordinary behaviours and assumptions that we’ve perhaps taken for granted for years.

Consider an old message board that’s been abandoned for years. An AI agent might discover that it’s still accessible, identify a vulnerability, and figure out how to use it as a foothold for further attacks.

Or consider an endpoint that accepts POST requests but was never intended to be accessible to unauthorised users. An AI-assisted attacker can probe the application, identify unexpected behaviours, and work out how to exploit them.

Historically, finding and chaining together these kinds of opportunities could require considerable expertise and manual effort. Increasingly, AI can help automate that process: exploring unfamiliar systems, testing assumptions, identifying weaknesses, and working out how to turn them into something useful to an attacker.

That’s what makes this shift so significant. The individual weaknesses don’t necessarily have to be sophisticated. What’s changing is how cheaply and quickly they can be discovered and exploited, potentially at a scale that wasn’t previously practical.

The risk isn’t just that AI will uncover new classes of vulnerabilities. It’s that it will become exceptionally good at finding and exploiting the ones we’ve already been living with.

We need to be proactive, not just responsive

Patching PHP2Shell is the immediate priority. But the longer-term lesson is about how we approach security as an engineering team.

We can’t assume that because our application is built on mature, widely used technologies, the underlying components are free of critical vulnerabilities. Nor can we assume that vulnerabilities will always be discovered with enough warning for us to deal with them at our leisure.

We should prepare for more events like this.

That means making sure we know what we’re running, where it’s running, and which systems depend on it. It means keeping runtimes and dependencies up to date, having a straightforward process for assessing security advisories, and being able to deploy critical patches without unnecessary delays.

It also means looking beyond dependency versions. We should understand which services are exposed to the internet, which endpoints can be reached without authentication, what our applications can do when running on a server, and whether older or forgotten components are still accessible.

And we should be thinking about detection and recovery, not just prevention. If a vulnerability allows remote code execution, patching closes the vulnerability going forward, but it doesn’t tell us whether somebody exploited it beforehand. Logs, monitoring, incident response, and the ability to rebuild affected infrastructure all matter.

Ideally, much of this should already be part of our normal engineering practice, rather than something we scramble to establish when a critical advisory lands.

The takeaway

PHP2Shell is a serious vulnerability, but it’s also a useful preview of the security landscape we’re heading into.

AI is making it easier to find weaknesses in software that has been around for decades. The resulting vulnerabilities won’t always be in obscure libraries or experimental projects. They may be in the runtimes, frameworks, and infrastructure that power the systems we depend on every day.

For engineering teams, the challenge isn’t simply to react faster when the next vulnerability makes the news. It’s to build systems and processes that make those reactions routine, while reducing the number of weaknesses we leave undiscovered in the first place.

We’ve patched the immediate issue. Now we should take the opportunity to ask ourselves a bigger question:

If the next PHP2Shell affects something we depend on, will we be ready to respond?