PHP2Shell and the new pace of website security.

This isn’t really a story about PHP. It’s a story about how AI is changing website security, and what it takes to keep up.

Wednesday, October 21 started the way most of my days do. Each morning, our AI agents put together a briefing on the day ahead and news relevant to our work, including updates to the software we use. This briefing included details on two critical flaws in PHP, the language that runs most of the web, including every WordPress site. The flaws had a name, PHP2Shell, and a severity score near the top of the scale.

Because of the nature of these flaws, patching them was a top priority for our team and our infrastructure partners. We reviewed every site we manage to identify which were affected. Pantheon had already started rolling out patches across the sites on their platform, and we applied patches to the rest.

The sites we manage were all patched by mid-morning. The news, however, was spreading fast, and emails were starting to come in from clients unsure if there was anything they needed to do to protect their websites. Several were ready to take their websites offline, following the advice they were hearing from the news.

Patching the software was the easy part. Managed platforms like Pantheon and security services like Cloudflare had fixes and protections rolling out quickly. Having those partners already in place is a huge part of the value of managed website services. What makes PHP2Shell worth a closer look is how these flaws were found, and what that discovery means for the future of website security.

What PHP2Shell actually is.

PHP stands for “PHP: Hypertext Preprocessor.” It’s a programming language that runs on a website’s server, handling much of what happens behind the scenes, from retrieving content to processing forms and checking whether someone is logged in. WordPress is built on PHP, so even if you’ve never written a line of code, it’s part of what makes your website work.

PHP2Shell is the name given to two related vulnerabilities in PHP’s core engine, tracked as CVE-2026-109618 and CVE-2026-109619.¹ They involve the way PHP handles memory when a request fails or when internal information is carried between requests. Under the right conditions, an attacker could exploit them without logging in.

Two outcomes were demonstrated. Remote code execution means an attacker can make a server run instructions of their choosing. Memory disclosure means reading information out of a running process, which can include passwords, session tokens, and other data that was never meant to leave the server. The reported severity reaches 9.2 out of 10, which puts it in the critical range.²

A CVE, short for Common Vulnerabilities and Exposures, is just a shared identifier for a reported flaw. The score tells you how urgent the fix is. It does not tell you whether your site was attacked. Those are different questions. Applying an update closes the hole. Reviewing logs can help identify whether anyone came through it first, but an absence of evidence does not prove a site was untouched. A good provider will be clear with you about which one they are talking about.

CBC News’ Andrew Chang has a good explainer on the discovery, its reach, and the role AI played. It is worth eight minutes of your time.

The fix arrived in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12, with some vendors supplying patched builds for older branches.³ On October 23, PHP’s maintainers followed up with a recommendation to disable a feature called session upload progress pending a further fix for an unusual configuration.⁴ Follow-up advisories are normal. Someone has to be reading them.

When everyone is looking.

PHP powers roughly seven in ten websites whose server-side language can be identified⁵ and it has done that job, successfully, for decades. Some of the affected code had been in place for more than ten years. Finding the flaws required researchers to work through subtle interactions deep within PHP’s engine. They used advanced AI models to uncover the weaknesses, build working demonstrations, and adapt them across applications. The researchers describe an overall effort that took one person a week rather than a specialist team months, with working exploits adapted across applications in hours.⁶ This is not a bug caused by careless coding or a neglected project. It is the kind of deep, subtle flaw that can remain hidden in mature software. PHP’s massive scale makes it an obvious priority for this kind of research. A single discovery can affect millions of websites.

That scrutiny is part of the business case for PHP. When software runs so much of the web, there’s a strong incentive to find its flaws and get them fixed. Here, researchers at cloud security company Wiz worked with OpenAI, PHP’s maintainers, and infrastructure providers on fixes and temporary protections ahead of public disclosure. By the time the story reached the news, patches were already rolling out.⁷ Less widely used platforms don’t attract the same investment in security research. Their flaws can remain undiscovered for longer, and whoever eventually finds them may have very different intentions.

Yes, these flaws were found in PHP. And PHP has no shortage of critics. “PHP is dead.” “It’s outdated.” WordPress, by extension, gets similar criticisms: slow, bloated, insecure. For those critics, PHP2Shell is another reason to say, “That’s WordPress for you.” Those are tired talking points, and they miss what makes this discovery significant. AI is changing how vulnerabilities are found, demonstrated, and exploited. That has implications for every platform.

This isn’t really a PHP issue.

PHP2Shell has plenty of company. Some of the most serious security incidents of the past fifteen years have affected entirely different languages, products, and platforms:

• Log4Shell (December 2021). A flaw in Log4j, a Java logging library embedded in an enormous range of enterprise software, scored a perfect 10 out of 10 and set off a global patching scramble that ran for months.⁸
• Microsoft Exchange ProxyLogon (March 2021). Tens of thousands of email servers were compromised, many of them before their owners knew a patch existed.⁹
• MOVEit Transfer (May 2023). A flaw in a file-transfer product used by governments and large institutions led to data theft affecting thousands of organisations.¹⁰
• Drupalgeddon (October 2014) and Drupalgeddon2 (March 2018). Drupal’s security team advised that any site not patched within seven hours of the first announcement should be assumed compromised.¹¹
• Next.js middleware authorization bypass (March 2025). A critical flaw in one of the most popular modern JavaScript frameworks allowed attackers to bypass authorisation checks implemented in middleware.¹²
• React Server Components (December 2025). A critical flaw in React’s server rendering affected specific server packages and frameworks and required teams to track down where the affected code was running.¹³

Then there’s the XZ Utils backdoor, discovered in March 2024. An attacker gained trust within an open-source project and inserted malicious code into a compression library used by Linux distributions. The backdoor could compromise secure remote access on affected systems. Developer Andres Freund uncovered it while investigating unusually slow logins, before the compromised versions reached widespread production use. The warning sign was a small performance problem. Someone paying attention made the difference.

Java, Microsoft Exchange, enterprise file transfer, Drupal, Next.js, React. These problems reach across the software industry, including the modern frameworks often recommended as alternatives to WordPress. Choosing a different platform changes what needs protecting. It doesn’t remove the responsibility to protect it. Someone still needs to know what’s running, follow the advisories, apply the fixes, and check that they worked. That’s the lesson of PHP2Shell, and every incident on this list.

The clock is faster now.

For many vulnerabilities, there was a gap between a vulnerability being disclosed and attackers being able to use it. Turning a research paper into a working exploit took skill and time. That gap is where routine maintenance lived. But that window was never guaranteed. Some flaws were exploited within hours, or before a patch was available.

PHP2Shell is the clearest signal yet that the gap is closing. The same AI tools that helped researchers find and demonstrate these flaws in hours are available to anyone. Cloudflare reported attack traffic adapting as its protections were deployed, which tells you how quickly methods change even if it does not tell you who, or what, was behind each request.¹⁴ Pantheon’s early notices described probing at the platform level. On the sites we manage, which sit behind Cloudflare’s protections, we found no evidence of anything reaching them. That is the system working, and it is not a reason to relax.

Drupal’s seven-hour warning in 2014 was considered alarming at the time. I think it is a reasonable baseline now. The practical consequence for a website owner is simple: the window in which your provider needs to act has shrunk from weeks to hours, and the plan for acting has to exist before the alert arrives. On Wednesday we could move quickly because the inventory already existed, the update paths were already known, the hosting partners were already chosen for exactly this reason, and the firewall was already in front of the sites. None of that can be assembled on the morning it is needed.

AI helps on our side too. It helped me cross-check which sites were affected, read the advisories against our inventory, and work through the update sequence faster than I could have alone. It did not decide anything, and it did not check its own work. We still verified every environment and tested the functions people depend on. That combination, fast tools and accountable people, is what I think good maintenance looks like from here on.

What is at stake is trust.

I want to say something about what happens when a site like yours is actually compromised, because the conversation usually stays abstract until it is not.

Over the years, organisations have come to us for help after their websites were hacked. Some had compromised plugins, others had abandoned themes or code nobody had maintained in years. Getting the website working again was often the smaller part of the problem. The harder work was dealing with the disruption and rebuilding trust.

Picture it for an association. Renewal season opens and the payment form is quietly sending card details somewhere else. Or the member directory is replaced with pharmacy spam and a member notices before you do. Or your database, with every member’s name, email, and employer, is for sale. Now you are drafting the notification letter. You are explaining to the board how long it was happening. You are answering the question every member is thinking, which is whether they can trust you with their information next year.

For a regulator it is sharper still. The public register is the one thing the public needs from you, and the one thing a licensee needs to prove they are in good standing. If it goes offline, or worse, if someone can change what it says, your credibility is the thing on the line. Nobody writes an angry letter about the server. They write it about you.

I am glad to say that in all the years we have been doing this, no website under our active management has been hacked. I am not saying that to boast. I am saying it because the difference between the sites we have repaired and the sites we have protected has never been the platform. It has been whether someone was responsible for watching.

What to expect from your web provider.

As security threats move faster, organisations need practices they can rely on. That includes knowing what their suppliers are responsible for, how quickly they will respond, and what happens when something goes wrong. A security alert shouldn’t be the first time you have that conversation.

A service level agreement, or SLA, puts those expectations in writing. It should be something clients can understand and use, with practical answers about support, maintenance, and security.

Our Service Level Agreement sets out those responsibilities for each service we offer. For a suspected compromise, our initial response target is four hours on a Maintenance Plan and two hours on a WebOps Retainer, measured during support hours. That means acknowledging the issue, assessing its priority, and confirming the next steps. Resolution time depends on what we find. We also aim to assess critical patches within one business day of release, taking severity and exposure into account.¹⁵

Whatever provider you use, you should be able to get answers to four questions without becoming a PHP specialist:

1. Was our site affected? What needed attention, and who was responsible for updating it?
2. Has the fix reached our site? What was installed, when, and how was it checked?
3. Are our important services working? Were forms, renewals, registrations, and other essential functions tested after the update?
4. Is there any follow-up? Are further updates, log reviews, or site-specific checks still needed?

Hosting, maintenance, and ongoing development each cover a different part of keeping a website useful and secure. Hosting provides the infrastructure your website runs on. A managed host may update PHP and protect its platform, while leaving WordPress, plugins, themes, and custom code to whoever maintains the website. Paying for hosting doesn’t necessarily mean someone is looking after the software above it.

Maintenance covers that ongoing care: applying updates, checking for security issues, and testing that supported features still work. Modernising a codebase takes additional development work. Custom code can fall behind even while WordPress and its plugins stay current. Replacing unsupported components, improving older integrations, and adapting to changes in the underlying technology require time and investment beyond routine updates.

That’s where an ongoing development arrangement, such as our WebOps Retainer, gives clients room to plan improvements alongside maintenance. It helps protect the investment already made in the website by addressing ageing code and changing needs before they turn into urgent problems. The scope matters here: clients should know what their plan covers, what needs a separate budget, and who is responsible for identifying the work.

Those answers depend on work done long before the headline: keeping an inventory, assigning responsibility, maintaining access, and having a process for updates and testing. An SLA makes those expectations visible. The day-to-day work is what makes them dependable.

Security is a decision, not a feature.

PHP2Shell was a good week for us, and I want to be careful about how I say that. Good because nothing happened. Good because the system we had already built did what it was supposed to do, and most of our clients learned about it from our email rather than from the news.

That outcome was not luck and it was not WordPress. It was a set of decisions made long before Wednesday: which hosting partners to use, whether to put a firewall in front of every site, whether to keep a current inventory, and whether to pay for someone to be responsible for the software every month, including the months when nothing happens.

Most of the organisations we work with made those decisions years ago. A few are still on hosting-only arrangements, where the server is maintained and the website software is not, and this week was a reminder of what that gap actually means. Moving from basic maintenance to a WebOps arrangement is, in the end, a decision about how much of this you want to be your problem. The websites that fared best this week were the ones whose owners had decided it should be ours.

The pace is not going back to what it was. The tools that found PHP2Shell will find the next one, and the next one may not be in PHP. Whatever platform you run, somebody needs to be watching it, and they need to be ready before the alert lands. That is what maintenance is for. For our clients, it is what they have been paying for all along.