It has been about a week since PHP2Shell entered the cybersecurity news cycle, and we finally have enough information to look beyond the initial panic.
When CVE-2026-109618 and CVE-2026-109619 were disclosed on October 21, the reaction was immediate. Vendor alerts went out, threat intelligence teams started monitoring for exploitation, hosting providers began rolling out patches, and headlines quickly focused on one very large number: nearly 70% of the web uses PHP.
Naturally, that became the story.
If PHP runs almost 70% of the web and PHP suddenly has two critical unauthenticated Remote Code Execution vulnerabilities, then nearly 70a% of the internet must be vulnerable, right?
Not exactly.
I want to be clear before going any further. PHP2Shell is not a case of the cybersecurity community making something out of nothing. These are legitimate critical vulnerabilities. The PHP Security Team rated both at CVSS 9.2 and advised users to patch immediately. CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog on October 26 after evidence of exploitation in the wild emerged. (PHP Security Advisory, CISA KEV)
The issue I have is not with calling PHP2Shell critical.
It is with confusing technology prevalence, vulnerability exposure, exploitability, and actual business impact as though they are all the same measurement.
They are not.
The “70% of the Internet” Problem
According to W3Techs, PHP is currently used by approximately 69.2% of websites where the server-side programming language can be identified. That is an enormous footprint and helps explain why the disclosure generated so much attention.
But that statistic does not mean 69.2% of the internet was confirmed exploitable.
There is an important difference between saying:
PHP powers nearly 70% of websites where the server-side language is known
and saying:
Nearly 70% of websites can be successfully exploited using PHP2Shell.
Those are very different statements.
At the same time, we should not swing too far in the opposite direction and assume only unusual PHP configurations were affected. PHP itself stated that all PHP installations serving web requests should be considered at risk, including PHP-FPM, Apache using mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP Security Team considered mod_php the highest-risk configuration because researchers demonstrated an unauthenticated attack that could execute before application code even ran.
So yes, the attack surface was broad.
That does not mean the practical risk was identical everywhere.
A server directly exposed to the internet running an unpatched PHP runtime is in a different situation than an application behind a managed Web Application Firewall with strict request controls and an automatically patched runtime.
Architecture matters.
So does operational ownership.
Exposure Is Not the Same as Exploitability
This is where I think PHP2Shell becomes a useful case study for risk professionals.
We often see a vulnerability score and immediately attempt to translate it into business risk.
A CVSS score tells us something important about the technical severity of a vulnerability. It does not tell us whether a specific organization is exposed, whether compensating controls exist, whether exploitation is occurring, or how much financial damage an incident would cause.
PHP2Shell illustrates that distinction extremely well.
Cloudflare, for example, deployed WAF protections before the public disclosure and reported observing attackers modifying payloads in attempts to bypass those controls. Cloudflare still advised customers to patch because its protections were considered defense-in-depth, not a substitute for fixing the vulnerable PHP runtime.
Google Cloud took a similar approach. Some supported serverless PHP environments received automatic base-image updates, while customers operating custom containers or other self-managed deployments needed to rebuild and redeploy their applications themselves.
Two companies could therefore both technically “use PHP” while having dramatically different response requirements.
That distinction was often lost in the early headlines.
Understanding the EPSS Jump
One of the more interesting parts of PHP2Shell was watching the Exploit Prediction Scoring System, or EPSS, react as information became available.
Initially, CVE-2026-109618 carried an EPSS probability of approximately 5.31%, while CVE-2026-109619 sat around 5.76%.
Within the following days, CVE-2026-109618 climbed to approximately 99.98%, while CVE-2026-109619 reached essentially 100%.
That is a massive shift.
But it is important to understand what changed.
The vulnerability itself did not suddenly become more severe.
EPSS is attempting to estimate the probability that a vulnerability will be exploited in the wild. As exploit-related signals, public research, Proofs of Concept, attack telemetry, and other intelligence became available, the probability model changed accordingly.
There is another important detail in the timeline.
CISA added CVE-2026-109618 and CVE-2026-109619 to the Known Exploited Vulnerabilities catalog on October 26. By that point, EPSS had already moved dramatically upward.
So the KEV designation did not cause the EPSS spike.
Instead, both were reacting to the same broader reality: the vulnerabilities were moving from theoretical research into practical exploitation.
This is exactly why I think organizations should resist looking at CVSS, EPSS, or KEV independently.
They answer different questions.
CVSS: How technically severe is the vulnerability?
EPSS: How likely is exploitation in the wild?
KEV: Do we have sufficient evidence that exploitation is actually occurring?
None of those answers the final question:
What does this mean to my organization?
That still requires understanding your environment.
Managed PHP vs. Self-Managed PHP
Initially, I thought the best way to explain PHP2Shell’s real-world impact was to separate small websites from large enterprises.
After looking at the response more closely, I do not think company size is the best dividing line.
Operational ownership is.
Managed Environments
Many organizations rely on hosting providers, serverless platforms, or managed services where someone else controls the underlying PHP runtime.
For those organizations, PHP2Shell may have required relatively little direct intervention.
Google Cloud, for example, automatically updated supported PHP runtimes in some App Engine and Cloud Run configurations. Managed hosting providers could similarly update PHP centrally rather than requiring every customer to manually patch their individual websites.
That does not mean the vulnerability was insignificant.
It means responsibility for patch deployment had been transferred to the platform provider.
Self-Managed Environments
Organizations running their own PHP installations had considerably more work to do.
Security teams needed to:
- Identify every PHP runtime in the environment
- Determine which versions were vulnerable
- Identify internet-facing applications
- Patch supported versions
- Rebuild containers
- Restart PHP workers and web servers
- Validate applications after deployment
- Confirm WAF coverage
- Review logs and telemetry for possible exploitation
Simply installing a package was not necessarily enough.
Google specifically warned organizations that upgrading PHP files on disk does not remove the vulnerable runtime from memory. PHP-FPM, Apache, FrankenPHP, LiteSpeed, and similar worker processes must actually be restarted so that patched binaries replace vulnerable ones.
For highly customized or critical applications, the response becomes even more complicated.
Banks, manufacturers, government systems, healthcare organizations, and other critical environments often cannot simply install a runtime update and hope for the best. They may need accelerated regression testing, emergency change approvals, container rebuilds, application validation, and coordination with third-party vendors.
That is where the operational impact of a vulnerability can differ dramatically from its technical severity.
What Organizations Should Actually Do
The most important guidance is also the simplest:
1. Patch PHP
Upgrade to:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
The PHP Security Team has been very clear that there is no complete configuration-based mitigation for PHP2Shell. Updating to a patched version is the only complete solution.
2. Restart PHP Workers
Do not assume that installing the update means the vulnerability is gone.
Restart PHP-FPM, Apache, FrankenPHP, LiteSpeed, containers, or other web-serving processes to ensure the patched PHP runtime is actually loaded into memory.
3. Use WAF and Edge Controls as Defense-in-Depth
Web Application Firewalls can help reduce exposure while patching takes place.
Cloudflare deployed PHP2Shell protections before disclosure, while Google Cloud and AWS published additional edge-control guidance for customers.
Request-body limits, restrictions on unnecessary multipart uploads, upload limits, and additional traffic inspection may disrupt known attack techniques.
But there is an important caveat.
A WAF does not patch PHP.
These controls buy time and create additional barriers. They should not become an excuse to postpone the actual update.
4. Recycle PHP-FPM Workers
For environments that cannot patch immediately, setting:
pm.max_requests = 1
can provide additional protection against attack paths that require state to persist between multiple requests.
The tradeoff is performance because PHP-FPM must continually create new worker processes.
This should therefore be treated as a temporary defense-in-depth control, not a permanent substitute for patching.
5. Be Careful With Memory Limits
This one is counterintuitive.
For CVE-2026-109618, a traditional PHP memory_limit can actually participate in triggering the vulnerable out-of-memory handling path.
Temporary guidance for systems that cannot immediately patch includes setting:
memory_limit = -1
while controlling overall process memory through containers or cgroups and strictly limiting request sizes at the web-server or proxy layer.
That does not mean organizations should permanently give PHP unlimited memory.
It means the vulnerability exists in PHP’s handling of certain out-of-memory conditions, so a security control that normally sounds reasonable may interact poorly with this particular flaw.
This is a great reminder that remediation needs to be vulnerability-specific.
6. Review Legacy PHP
PHP 8.1 and older no longer receive normal security updates directly from the PHP project.
However, that does not automatically mean every older PHP package remains vulnerable.
Linux distributions and long-term-support vendors may provide backported fixes while retaining an older version number. Organizations running PHP 7.4, 8.0, 8.1, or other legacy branches should verify the patch status with their operating system or support vendor rather than relying exclusively on the version displayed by php -v.
Long term, migration to a supported PHP branch should remain the goal.
One More Wrinkle: CVE-2026-115560
PHP2Shell also demonstrated why vulnerability response rarely ends when the initial patch goes out.
On October 23, PHP published additional guidance regarding CVE-2026-115560, a related Remote Code Execution issue involving PHP’s session upload progress functionality. The issue requires an unusual combination of configuration and application behavior, but it is not addressed by the October 21 PHP2Shell updates.
Until the next regular PHP release, PHP recommends disabling session upload progress where possible:
session.upload_progress.enabled = 0
Organizations that already applied this mitigation as part of the CVE-2026-109619 guidance do not need to make an additional change.
That is another reason vulnerability response needs continued monitoring even after the initial emergency patch is deployed.
The Open-Source Maintenance Problem
The history behind PHP2Shell may ultimately be more important than the vulnerability itself.
The PHP Foundation acknowledged that the first signs of the out-of-memory issue behind CVE-2026-109618 were identified during security work in 2024.
At the time, researchers theorized that exploitation might be possible, but no concrete path to Remote Code Execution had been demonstrated.
The problem was not simply ignored.
Fixing it involved difficult tradeoffs involving backward compatibility, denial-of-service risks, and potential changes across PHP’s large ecosystem of third-party extensions. The PHP Foundation has openly acknowledged that the issue stalled partly because of those technical tradeoffs and because a relatively small group of developers possessed the expertise required to safely modify those parts of the PHP engine.
That is an uncomfortable reality of open-source security.
A project can support enormous portions of the global technology ecosystem while still relying on a comparatively small number of people to maintain extremely complex code.
PHP2Shell should not simply become another argument that open-source software is insecure.
The better question is whether organizations that depend heavily on critical open-source infrastructure are investing enough back into the projects they rely on.
The AI Security Research Shift
There is another part of this story I find especially interesting.
Artificial intelligence played a meaningful role in the modern discovery and validation process.
The PHP Foundation says Calif, OpenAI, Wiz, and other researchers demonstrated practical attack paths that helped establish the true severity of the issues. The Foundation also described using AI-assisted security tools internally to help validate and organize vulnerability reports.
OpenAI reported that Calif used GPT-5.6 Sol as part of the Patch the Planet initiative, while Google said Wiz used a mixture of models and that Gemini 4 Argon contributed to vulnerability discovery, exploit development, detection, and patch validation.
I think this is where security teams should pay very close attention.
AI is reducing the amount of time required to explore complicated attack states, analyze enormous codebases, generate hypotheses, and validate vulnerabilities that might previously have remained theoretical for years.
That benefits defenders.
It also changes the economics of vulnerability research for attackers.
I do not think the answer is to turn CI/CD pipelines over to autonomous AI agents and call the problem solved. Experienced security researchers still need to interpret findings, understand business logic, validate exploitability, and make difficult engineering decisions.
But I do think AI-assisted code review, fuzzing, exploit validation, and adversarial testing will become increasingly important parts of secure software development.
PHP2Shell may be an early example of what that future looks like.
Final Thoughts
PHP2Shell was serious.
The PHP Security Team was right to issue an emergency release. Organizations were right to prioritize patching. CISA’s decision to add both vulnerabilities to KEV confirms that exploitation moved beyond theory.
But the incident also demonstrates why vulnerability management cannot stop at the headline.
Nearly 70% PHP usage does not mean nearly 70% of the internet was successfully exploitable.
A CVSS score of 9.2 does not tell you whether your server is publicly accessible.
An EPSS score approaching 100% does not mean an attacker has a 100% chance of compromising your environment.
A KEV entry tells you exploitation is happening, but it still does not tell you what the financial impact would be to your organization.
Each measurement provides a different piece of the puzzle.
The real work begins when organizations combine those signals with architecture, exposure, compensating controls, asset criticality, operational dependencies, and potential business impact.
That is where vulnerability management becomes risk management.
And PHP2Shell is a pretty good example of why understanding the difference matters.
