PHP2Shell I Patched My Partners Websites. The Real Nightmare Is Just Beginning.

There is something deeply concerning about a critical vulnerability in software that powers a huge part of the internet: the people who need to patch it most are often the people who will never hear about it.

PHP2Shell has put the security of PHP based infrastructure under the spotlight. After reviewing the vulnerability and its implications, I patched my own infrastructure, updated all my partners’ websites, and took self-hosted tools offline when I couldn’t confirm that a security fix was available.

But I keep coming back to a much bigger question.

What happens to the millions of websites, applications, and servers that won’t be patched?

Some administrators are already responding. Others haven’t seen the advisory. Some don’t know which PHP version their websites are running. Others are using abandoned applications, forgotten VPS instances, outdated hosting environments, or control panels that manage their own separate PHP runtimes.

That is why I believe PHP2Shell could become an internet-wide security crisis. Call it an approaching cybersecurity armageddon if you want but the underlying problem is real: a security fix only protects a system when someone actually installs it.

What is PHP2Shell?

PHP2Shell refers to two reported PHP vulnerabilities:

• CVE-2026-109618
• CVE-2026-109619

These vulnerabilities concern the PHP runtime itself, rather than a single CMS or plugin. The reported impact includes the potential for unauthenticated remote code execution in affected configurations.

That distinction is important.

Updating WordPress does not update PHP. Updating a Laravel application does not update its runtime. Updating an operating system does not necessarily update a separately managed PHP installation supplied by a hosting control panel.

If the underlying runtime remains vulnerable, an otherwise well-maintained application can still be exposed.

For technical details and the applicable fixed releases, consult the official PHP security announcements.

I have already patched all my partners’ websites.

I didn’t want to wait and hope this issue would somehow pass without affecting the systems I help maintain.

I also reviewed the self-hosted tools I depend on. Where I couldn’t confirm that an appropriate security fix was available, I took the affected tools offline rather than leave them exposed while waiting for their maintainers.

This is not always the most convenient decision. Taking a service offline can disrupt workflows, integrations, and access to useful tools. But convenience is not a sufficient reason to knowingly leave a potentially vulnerable service exposed to the internet.

My approach was straightforward:

• Patch the systems for which a suitable update was available.
• Verify the PHP runtime actually serving each website.
• Review self-hosted applications and their dependencies.
• Take tools offline when I couldn’t establish that they were adequately protected.
• Wait for verified fixes before restoring affected services.

Patching is not just running an update command and assuming the job is finished. It means checking what actually changed and confirming that the services in production are running the corrected software.

Why I am worried about the rest of the internet

My own infrastructure and my partners’ websites are only a tiny part of the picture.

The internet contains an enormous number of PHP applications, many of which are maintained by small businesses, freelancers, volunteer administrators, or nobody at all.

Consider the different environments that may be affected:

Forgotten websites. A business website may have been deployed years ago and left running because it still works. Nobody checks its PHP release, and nobody monitors security advisories.

Shared hosting. Website owners often assume their hosting provider handles everything. Sometimes the provider does manage PHP updates; sometimes the responsibility is split between the provider, the customer, and the application maintainer.

Self-hosted applications. Home labs and small servers can contain exposed dashboards, file managers, monitoring systems, and other services whose maintainers haven’t published a compatible fix.

Outdated control panels. A server may have an updated operating system but continue running a separately managed PHP runtime that needs its own security update.

Abandoned software. Some applications no longer have an active maintainer. Even when a vulnerability is confirmed, there may be no patch to install.

The dangerous combination is a remotely reachable vulnerable service, an available exploitation path, and an administrator who doesn’t know the service needs attention.

We should not assume that every PHP website is exploitable, or that a mass compromise is inevitable. Actual exposure depends on the affected code paths, deployment, configuration, and available mitigations.

But we also shouldn’t underestimate the challenge of getting a security fix installed across a vast, decentralized ecosystem.

The patching gap is the real crisis

A vulnerability disclosure starts a race between defenders and attackers.

Maintainers need to understand the problem, develop and test a fix, package it, and distribute it. Administrators then need to learn about the update, identify affected systems, install it, restart services where necessary, and verify the result.

Every stage introduces delay.

Large organizations may have asset inventories, vulnerability scanners, incident-response teams, and defined patching procedures. A small website owner may have nothing beyond a hosting account and an email address they rarely check.

Some administrators won’t know whether they are running the affected PHP branch. Others may believe that updating their CMS automatically updates the runtime. Some will simply postpone the work because the website appears to be functioning normally.

That is how a critical vulnerability can remain a problem long after a fix exists.

The release of a patch does not mean the internet is patched.

And the systems that remain exposed may not belong to careless administrators. They may belong to people who never received the information, lack the technical resources to act, or depend on a vendor that has not yet supplied a compatible update.

Plesk and multiple PHP installations: an important detail

For anyone managing websites through Plesk, there is an additional detail worth checking.

Plesk can manage PHP runtimes separately from the operating system’s PHP packages. A server can therefore have a patched system PHP installation while a website continues to use an older Plesk-managed runtime.

On a Plesk server, check the version of the actual Plesk PHP binary, for example:

/opt/plesk/php/8.2/bin/php -v

Also inspect the PHP handler assigned to each domain and verify the version used by its PHP-FPM service.

Don’t assume that a package update succeeded simply because the command completed. Check the installed version, the applicable vendor advisory, and the runtime serving the website.

What website owners should do now

If you manage PHP websites or self-hosted applications, use this as a prompt to review your infrastructure.

1. Inventory every PHP runtime. Include websites, APIs, containers, control-panel-managed installations, and bundled runtimes.
2. Check the official security advisory. Identify the affected branches and fixed versions that apply to your environment.
3. Install supported security updates. Use your operating system, hosting panel, or application vendor’s supported update process.
4. Verify the production runtime. Check what the website actually executes, not just what is installed on the command line.
5. Reduce exposure where necessary. Restrict access or temporarily disable services that cannot be patched and cannot be kept online safely.
6. Review logs for suspicious activity. Look for unexplained processes, unexpected file changes, unusual outbound connections, and other indicators of compromise.
7. Reassess credentials if compromise is suspected. Rotate potentially exposed secrets from a trusted environment and investigate before returning a compromised host to production.

If you cannot obtain a fix for a critical vulnerability, contact the vendor and follow its mitigation guidance. A firewall or access restriction may reduce exposure, but it is not equivalent to a software fix.

Could PHP2Shell trigger a cybersecurity Armageddon?

I can’t honestly claim that a global wave of compromises is inevitable. That would require evidence about the number of exposed systems, exploit availability, attacker activity, and the effectiveness of mitigation efforts.

But I do think the possibility of widespread consequences deserves serious attention.

PHP has a large and diverse installed base. Its applications run on everything from carefully maintained enterprise infrastructure to inexpensive shared hosting accounts and forgotten servers. Getting all of those environments patched is a much harder problem than releasing a corrected version.

If attackers find reliable ways to exploit vulnerable deployments at scale, the consequences could extend beyond individual websites. Compromised servers can become footholds for further attacks, sources of stolen credentials, or infrastructure for malicious activity.

The question isn’t whether every PHP website will fall. It is how many exposed systems will remain online, how quickly defenders can identify them, and how effectively administrators can respond.

That is the part that concerns me most.

Update November 10, 2026: Exploitation Is No Longer Just a Theoretical Concern

When I originally published this article on October 21, there was no publicly confirmed evidence of successful exploitation of PHP2Shell in real-world attacks.

That situation has since changed.

Security researchers initially reported exploitation attempts without being able to confirm successful compromises. However, subsequent investigations and security advisories have reported successful exploitation.

On November 3, Singapore’s Cyber Security Agency (CSA) published an alert confirming active exploitation of PHP2Shell vulnerabilities against internet-exposed management interfaces of affected Palo Alto Networks firewalls.

This is an important development, but it is equally important to understand what it does and does not mean. It does not establish that millions of PHP websites have been compromised, nor does it mean every vulnerable PHP installation is equally exposed. The reported attacks involve particular affected products and configurations.

Nevertheless, it confirms that this vulnerability is not something administrators can safely dismiss as a theoretical security issue.

And there is another lesson worth remembering.

The absence of publicly reported exploitation today does not mean a vulnerability will remain unexploited tomorrow.

We have seen this pattern repeatedly across cybersecurity. Vulnerabilities can remain relevant for years after disclosure, with attackers continuing to discover new targets, develop more reliable exploitation techniques, and reuse old vulnerabilities in new attack campaigns.

Sometimes, the most dangerous period for an unpatched system is not the day a vulnerability is disclosed, but months or even years later, when administrators have forgotten about it and attackers are still looking for it.

That is precisely why I chose to patch my infrastructure and my partners’ websites immediately rather than wait for evidence of active exploitation.

A vulnerability does not become dangerous only when attackers start using it. It is already a risk when an exposed, vulnerable system remains unpatched.

The lesson remains the same: patch early, verify your infrastructure, and never mistake the absence of known attacks for evidence of safety.