PHP2Shell: When an old flaw in the foundation of the web suddenly becomes affordable

A wake-up call from the engine room of the internet

The vulnerabilities known as PHP2Shell are more than just another entry in the long list of critical security flaws. They don't affect a single web application, a specific plugin, or a misconfigured customer portal. They affect the runtime environment itself, on which a large part of the web operates. According to current measurements, PHP is used by 69.3 percent of all websites where the server-side programming language is recognizable. Behind this figure are company websites, online shops, customer portals, government websites, intranets, knowledge bases, and countless interfaces that process orders, appointments, documents, or logistics data in the background.

On October 21, 2026, fixes were released for the two vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619. Both are rated as critical (9.2 out of 10) according to the CVSS 4.0 rating system. The fixes address PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. All versions below these are affected. The earliest known vulnerable path dates back to PHP 5.4.0, released on March 1, 2012. This means the problem has been present in production software for more than fourteen years.

The prevalence of this vulnerability is not the only economically significant factor. The real impact lies in the fact that a weakness that remained undiscovered or at least practically unusable for many years has been transformed into a tangible attack tool in a short time through AI-supported analysis and exploit development. The key message, therefore, is that complexity is no longer a reliable form of protection. What would have previously occupied highly specialized experts for weeks can now be investigated, adapted, and replicated more systematically and quickly. This shifts the cost curve between attack and defense to the detriment of those who fail to modernize their infrastructure rapidly.

The long history of a brief escalation

Public attention focused on a few days in October 2026. However, the technical history is considerably longer. The researchers who discovered some of the flaws see a connection to a vulnerability described by Stefan Esser as early as 2004. Even then, PHP's remote memory limit played a security role. Furthermore, in 2020, a bug was reported where very long variables in multi-part form submissions led to memory exhaustion and temporary files. A related problem was identified during a security audit in 2024, but its exploitability could not be proven at the time.

This is crucial for the assessment. The vulnerability wasn't entirely unknown, but it apparently wasn't considered an immediately exploitable, widespread, and dangerous attack vector. In security practice, the mere existence of a programming error often doesn't determine its priority. The decisive factor is whether an attack can be reliably derived from it. An error whose exploitation seems possible only under unrealistic assumptions or with enormous effort is more likely to be relegated to the back burner. An error that can reliably execute malicious code becomes an emergency matter.

In the summer of 2026, this assessment changed. According to the published chronology, on August 1, 2026, security researchers discovered several independent methods that could lead to remote code execution. On August 11, the first vulnerability was reported to the PHP project. A working proof of concept followed on August 14, and on August 15, the PHP team confirmed its effectiveness. On August 21, the second vulnerability was reported. Simultaneously, another research team independently arrived at findings within the same family of problems. Two months later, the fixes were available.

The timeline reveals a typical pattern in modern software economics. A flaw can remain in a critical core component for years without market participants pricing it in. It only becomes an economic event when its practical exploitability becomes apparent. At that point, however, operators, hosting providers, software manufacturers, authorities, and security service providers must act within hours.

A mistake in handling the exceptional case

PHP2Shell is not a typical vulnerability in a content management system. It's also not due to an insecure password check or a forgotten administration window. The cause lies at the core of the PHP runtime environment—the part of the software that receives requests, manages memory, processes form data, and executes programs.

Put simply, it's about handling exceptional situations. A web request requires memory. PHP limits this memory per request to prevent individual processes from completely saturating a server. If this limit is reached, or if a request is aborted due to a critical error, the runtime environment must clean up its internal data. This is precisely where the problem arose. In certain situations, a request was aborted while internal data structures were only partially prepared. The subsequent cleanup routine, however, treated this incomplete data as if it were valid.

The first vulnerability, CVE-2026-109618, focuses on memory exhaustion. PHP reacted to an out-of-memory error with an abrupt return from the running program context. In some parts of the program, the memory for a request was already accessible for later processing steps at that moment, but not yet fully initialized. If a memory request then failed, an invalid state remained, which PHP could process further when terminating the request. This is valuable for attackers because the processing of form data begins even before the actual application code. Even a simple website can be vulnerable as a result, despite its own program code being cleanly written.

The second vulnerability, CVE-2026-109619, affects stale global state between requests. A PHP worker process handles many requests sequentially. During a request, it may reference data that belongs only to that single request. These references must be reset before the memory is released. If an operation is aborted due to a critical error, this step can be skipped. The worker process continues while still referencing memory that has already been released. If a subsequent request reaches this state before the normal initialization replaces it, a so-called use-after-free error occurs.

Technically, those responsible describe this as an interplay between producer and consumer. The producer leaves behind a potentially dangerous state, which the consumer later accesses. Both events must occur within the same work process. Multiple work processes and the regular recycling of processes reduce the probability of success per request, but do not eliminate the underlying condition. This illustrates why an attack, while complex, is by no means theoretical. Those who can automate and repeat attempts can transform a low success rate per request into a significant success across many requests.

It is noteworthy that the same basic structure appears in various forms. A program segment publishes or modifies a state, then performs an error-prone operation, and should only subsequently clean up or acknowledge the changes. An abrupt termination prevents this final step. Later, another program segment relies on a state that is no longer valid. This pattern is more economically significant than a single error because it points to a systemic weakness in error handling. The now-published fix therefore addresses the root cause. It replaces the abrupt return to the previous state upon memory exhaustion with a controlled termination at a safe point in program execution. If a second, higher memory limit is reached, the process terminates immediately.

This fundamentally changes the logic. PHP no longer attempts to clean up a potentially corrupted state after an error. Instead, the runtime environment prevents this state from even reaching the critical cleanup phase. This is a typical lesson learned from memory errors in system software: error paths are not marginal cases, but rather critical, safety-critical pathways.

From programming error to remote access

For companies, one question is crucial: Does an attacker need to already have access to the system? In critical cases, the answer is no. The assessments classify the attacks as network-based, without requiring permissions or user interaction. At the same time, the attack complexity is considered high, and certain prerequisites are necessary. This combination is precisely what makes PHP2Shell so insidious. The attack can be launched from the internet, but it is not equally successful in every environment.

At an abstract level, the exploit follows a simple logic. An attacker attempts to force the runtime environment into an error state using specially crafted web requests. They then exploit the fact that PHP reuses incomplete or already released internal data. If the memory allocation is manipulated into a suitable form, a crash can lead to data leaks or even the execution of arbitrary code. The researchers combined several of these vulnerabilities into an attack tool. With this, they demonstrated code execution without authentication on current container environments of WordPress, Drupal, and Joomla.

These examples are not an exhaustive list. The affected software resides beneath the applications. Therefore, in principle, any application running on a vulnerable PHP version and in a suitable execution environment can be at risk. Further investigations have confirmed code execution without prior authentication for MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony, and WHMCS. The potential impact thus ranges from corporate websites, webmail, and collaboration tools to e-commerce platforms, developer frameworks, and hosting management systems.

A key difference lies in the server architecture. With Apache using mod_php, the cleanup phase of a request is executed even if the request itself fails. This makes certain application-independent attacks particularly dangerous. In contrast, PHP-FPM terminates a child process if the request attempt fails. This eliminates some attack vectors but doesn't automatically protect against all variations. Code execution has been confirmed for session management under both mod_php and PHP-FPM, although the FPM approach depends on a specific application operation. There are also indications of potential vulnerabilities for FrankenPHP and LSAPI, but these have not been fully validated in all cases.

For risk management, this leads to a sobering, but uncomfortable, realization. A simple inventory of whether a company uses WordPress, Drupal, or a proprietary system is insufficient. Crucial factors include the PHP version, the integration with the web server, the activated extensions, the configuration, the upstream security systems, and the applications actually accessible from the internet. This complexity makes security assessments more expensive. For attackers, however, they are becoming increasingly automatable.

What's at stake in a successful attack

The immediately confirmed damage is the execution of code with the privileges of the web worker process. While this may sound limited at first, it is significant in practice. This process often has access to application files, configuration files, database connections, caches, uploaded documents, and interfaces to payment, shipping, or CRM systems. Whoever controls it can modify content, leave backdoors, exfiltrate data, or prepare further attacks within the internal network.

The second dimension of damage is memory leakage. Under certain conditions, attackers can read data from the memory of a PHP process without first gaining full control of the server. This memory can contain passwords, authentication tokens, API keys, and certificates, including those from other requests or the server itself. Economically, this is particularly dangerous because a single data leak can enable subsequent attacks. A stolen API key can grant access to a cloud service. A session token can allow the takeover of an administrator account, and a certificate can undermine trust in a digital identity.

Availability is another crucial factor. Attacks that generate memory pressure can crash processes or disrupt services. For an online retailer, even a brief outage means lost revenue, abandoned orders, and additional support costs. For a logistics company, disrupted portals can delay notifications, shipment tracking, or coordination with partners. In manufacturing and industry, a compromised web application can become an entry point into interconnected supplier, service, or documentation systems.

The cost structure of such incidents is well documented. According to a recent analysis of 602 affected organizations, the average cost of a data breach in Germany in 2026 was €4.25 million, compared to €3.87 million the previous year. Industrial companies in Germany suffered the highest losses, averaging €7.02 million. They were followed by technology companies at €5.65 million and the financial sector at €5.64 million. These figures cannot be directly applied to PHP2Shell, as they encompass different types of attacks. However, they illustrate the significant economic impact that a successfully exploited vulnerability can have.

The time dimension is also relevant. Data leaks in Germany existed for an average of 160 days, of which 121 days were spent until discovery and 39 days until containment. Worldwide, the average was 247 days. Especially with vulnerabilities that allow code execution, early detection is crucial in determining whether an incident remains limited or whether attackers gain a foothold undetected. A patch closes the door to new attacks but does not remove an already installed backdoor.

The quasi-in-house solution: How Xpert.Digital closes operational gaps in B2B marketing and sales – Smart Content-Driven Business - Image: Xpert.Digital

Xpert.Digital is a data-driven B2B industry hub led by Konrad Wolfenstein . The company acts as an external, quasi-in-house solution for industrial partners, closing operational gaps in marketing, content, and sales – without requiring additional resources on the client side.

More information here:

• The quasi-in-house solution: How Xpert.Digital closes operational gaps in B2B marketing and sales – Smart Content-Driven Business

A race that began even before the patch

The release did not occur under controlled laboratory conditions. Information about the vulnerabilities leaked to the public before the planned disclosure date. A major infrastructure provider activated its web application firewall protection rules at 3:02 UTC on October 21, approximately nine hours before the scheduled public disclosure. Later that morning, the first attacks were reported, and attackers modified their requests to circumvent the protection rules. Hosting partners and honeypot networks also reported attempted attacks.

It is important to make a clear distinction: attempted attacks are not automatically successful compromises. As of late evening on October 21, no successful compromise had been publicly confirmed. The vulnerabilities were also not yet listed in the catalog of known exploited vulnerabilities maintained by the US Cybersecurity and Information Security Agency (CISA) at that time. However, this is no cause for complacency. In the early stages of a security incident, visibility remains limited, and many successful attacks are only detected days or weeks later.

Public authorities were also affected. Several websites, including those of the Free State of Bavaria and the Bavarian police, were temporarily unavailable on Wednesday afternoon for security reasons. Such precautionary shutdowns reflect the realities of business operations. When a core component is compromised, even uncertainty about the level of risk can cause outages. The resulting costs arise not only from attacks but also from security measures, audits, emergency maintenance, and limited accessibility.

Why the reach is greater than the statistics

The percentage of websites using PHP is only the first metric. The version distribution is more economically relevant. According to current data, 65.2 percent of PHP websites use version 8, 27.0 percent version 7, 7.7 percent version 5, and 0.1 percent version 4. More than a third of PHP websites are therefore not running on the current major version. This doesn't automatically mean that every one of these websites is exploitable. However, it does show the extent of legacy technology.

A particularly problematic aspect is that the fixes were only released for supported development branches. For older, unmaintained versions, the solution isn't a simple security update, but often a migration. This entails testing, compatibility risks, adjustments to extensions, and sometimes the replacement of entire applications. What begins as a short-term emergency measure can become a modernization project for some companies.

On the day of the patch, tens of thousands of instances running the then-current, but vulnerable, versions were discovered using publicly visible server identifiers. For versions 8.5.11, 8.4.26, 8.3.35, and 8.2.34 alone, the number of detected instances ranged between 23,000 and 50,000. These counts are incomplete, as many servers do not disclose their version. However, they illustrate the scale of the problem: even impeccably maintained systems were still vulnerable on the morning of the patch.

Artificial intelligence lowers the barrier to entry

The real paradigm shift lies in the role of artificial intelligence. The researchers involved used modern AI models for debugging, exploit development, attack detection, and validation of fixes. According to them, the complexity of the attack chain was previously at the limit of what human researchers could practically implement. With AI, working attacks could be adapted to multiple applications within hours.

This point is economically fundamental. Many security decisions are implicitly based on the assumption that vulnerabilities that are difficult to exploit are of lower priority. This assumption becomes invalid when attacks no longer need to be developed manually for every environment. Models can analyze failed attempts, generate variants, and adapt to different versions, configurations, and memory layouts. Complexity thus transforms from a protective barrier into a cost factor that machines are increasingly reducing.

At the same time, it would be too simplistic to portray AI as a universal tool that can find all flaws without human expertise. The discovery relied heavily on specialized knowledge of PHP's security history and a targeted hypothesis about where related flaws might lie. The models accelerated analysis and variant generation, but they did not replace an understanding of the target. This is both good and bad news for defenders. They can use the same tools to test their software. However, attackers with specialized knowledge gain a powerful productivity boost.

The overall state of cybersecurity reinforces this finding. In the latest major analysis of data breaches, the exploitation of vulnerabilities became the most important entry point for the first time, accounting for 31 percent of attacks. This surpassed stolen credentials. At the same time, third parties were involved in 48 percent of data breaches. According to this study, AI can reduce the time between the discovery and exploitation of a vulnerability from months to hours. Another study shows that attackers used AI in more than one in four cases. Attacks can therefore be launched for a few thousand US dollars, while defense and remediation cost millions.

This illustrates the new asymmetry of the digital economy. The marginal cost of an additional attack attempt is approaching zero. Conversely, every successful attack incurs high costs: forensic investigation, recovery, legal counsel, communication, customer support, production downtime, and loss of trust. This asymmetry is not new. However, PHP2Shell makes it visible across a particularly broad layer of infrastructure.

The foundation belongs to everyone, but hardly anyone pays for its upkeep

PHP2Shell also exposes a structural weakness of the open-source model. Basic technologies like PHP generate enormous macroeconomic benefits. Companies save on licensing costs, developers find a large ecosystem, agencies can implement projects quickly, and hosting providers operate standardized environments for millions of customers. The benefits are widely distributed. In contrast, the costs for security research, maintenance, backporting, and crisis coordination often fall to comparatively small teams.

Economically, this is a classic public goods problem. When many benefit from well-maintained infrastructure, but no one wants to bear the full cost alone, underinvestment occurs. The consequences only become apparent during a crisis. In the case of PHP2Shell, this problem was mitigated through cross-industry coordination. Researchers, PHP developers, AI providers, cloud providers, content delivery networks, and security companies jointly prepared fixes, detection rules, and transitional measures.

This collaboration was effective, but it shouldn't be mistaken for a permanent operating model. A security architecture that relies on the timely cooperation of a few large platforms remains vulnerable to leaks, delays, and blind spots. In the wake of the disclosure, a leading AI provider announced it would provide $1 billion in subsidized access to security tools for defenders with limited resources. At the same time, it anticipates a significant increase in vulnerability discoveries in the coming months. This underscores the core of the problem: if AI dramatically increases the number of discovered vulnerabilities, the capacity for assessment, remediation, and delivery must also grow.

This creates a new calculation for companies. Those who rely heavily on open source should not only consider security as a cost center of their own IT, but also as part of the supplier risk. Software bills of materials, reliable update paths, maintenance contracts with agencies and hosting providers, and support for key open-source projects thus become questions of corporate resilience.

Winners, losers, and the new safety return

The economic impact is unevenly distributed. Initially, the beneficiaries are providers who can deploy protection immediately and centrally. Content delivery networks, web application firewalls, managed hosting providers, and security service providers are gaining importance because they stand between the internet and the originating server. The markets reacted accordingly: Shares of a major infrastructure provider rose by 5.52 percent to $307.79 on the day of the disclosure. This does not imply that security incidents are inherently good business for providers. However, it does demonstrate that capital markets highly value the ability to quickly secure broad customer bases.

The biggest losers are organizations with fragmented, poorly documented, or outdated infrastructure. This includes many small and medium-sized enterprises, associations, municipalities, educational institutions, and mid-sized companies with websites that have evolved organically over years. Often, there's a shop, a dealer portal, a product database, or an applicant tracking system, the maintenance of which is outsourced to an external agency. In a crisis, the first steps are to determine who has access, which PHP version is running, what dependencies exist, and whether an update will damage the application. These search costs are real, but they don't appear in any budget.

This is where the real return on investment in security lies. Investments in inventory management, patching capabilities, test automation, and disaster recovery processes seem unremarkable as long as nothing happens. But in an event like the PHP2Shell attack, they determine whether a company can act within hours or remains in uncertainty for days. According to current cost data, the comprehensive use of AI and automation in security reduces average damages in Germany from €4.87 million to €3.34 million. The difference of €1.53 million doesn't prove the benefit of every single measure. However, it strongly indicates that responsiveness has measurable economic value.

For insurers and finance professionals, PHP2Shell also serves as a cautionary tale. A single flaw in a widely used core component can affect many policyholders simultaneously, creating a cumulative risk. Those assessing cyber risks will increasingly focus on how quickly companies roll out critical updates, whether they are using unsupported software, and whether emergency procedures are being practiced. As a result, premiums will increasingly reflect operational discipline.

Why only buy time with interim solutions

The developers make it clear that only updating to a corrected PHP version is a complete solution. Transitional measures can reduce the risk for individual attack vectors, but their effectiveness remains limited. For example, removing the PHP memory limit eliminates the predictable limit exploited by certain confirmed attacks. However, this also increases the risk of individual requests consuming excessive memory and disrupting operations. Disabling the progress indicator for uploads in sessions and, in PHP 8.5, critical error tracing, can interrupt certain confirmed attack vectors. However, this does not fully address other vulnerabilities.

Even upstream firewalls are just an additional layer of protection. They can block known attack patterns, but attackers deliberately modify their requests to bypass rules. Furthermore, such rules only provide protection if the originating server is not directly accessible from the internet. A company that relies solely on a web application firewall is merely postponing the problem instead of solving it.

The recommendation to drastically limit the number of requests per workflow clearly illustrates the economic trade-off. A process that restarts after each request reduces the chance of a malicious state propagating to a subsequent request. However, it consumes resources and increases server load. Security here is not an abstract virtue, but rather a balancing act between risk, infrastructure costs, and user experience.

Law, trust, and liability in a serious situation

If a vulnerability is successfully exploited, the damage quickly extends beyond IT. If personal data is compromised, those responsible in the European Union must report the breach to the competent supervisory authority without undue delay and, where feasible, within 72 hours. This applies if the breach is likely to result in a risk to the rights and freedoms of natural persons. In cases of a high risk, the data subjects must also be notified. Thus, a technical error becomes a matter of governance, documentation, and communication.

Assessing memory leaks is particularly difficult. A company may not know exactly what data an attacker has extracted from memory. If session tokens, keys, or access credentials were compromised, proactive data rotation may be advisable. This creates additional work for partners, interfaces, and customers. The damage then lies not only in the data loss but also in the need to technically rebuild trust.

This aspect is particularly important for B2B companies. After a known infrastructure incident, customers, suppliers, and logistics partners don't just ask whether an update has been installed. They want to know if there are any indications of a compromise, whether access credentials have been renewed, which systems were affected, and whether partner data might have been compromised. Companies that can respond quickly and transparently to these questions protect not only their IT but also their market position.

What companies should do now in an economically smart way

The first priority is taking stock. Companies need to know where PHP is running, which version, on which server, behind which proxy, and in which execution environment. This includes not only the main website but also microsites, landing pages, test systems, partner portals, internal tools, legacy installations, and systems at agencies or hosting providers. Forgotten test environments, in particular, are a typical entry point for vulnerabilities because they are rarely actively maintained.

The second priority is updating to a corrected version and restarting all work processes. Where an immediate update isn't possible, transitional measures can help. However, these should have a clear deadline and clearly defined responsibilities. For unsupported versions, migration planning is unavoidable. Companies should then assess whether the affected application needs to continue operating in its current form, or whether its functionality can be consolidated, deactivated, or replaced with a more maintainable solution.

The third priority is checking for traces of a potential attack. An update eliminates the vulnerability, but not an existing compromise. Unusual crashes, error messages, new files, changed configurations, unknown processes, or suspicious connections should be investigated. For systems with sensitive data, renewing passwords, keys, and tokens may be advisable.

The fourth priority is strategic in nature. PHP2Shell should not be treated as an isolated special case, but rather as a stress test for the entire vulnerability management system. How long does it take for a company to know if it is affected? Who decides on emergency updates? Is there a test environment where updates can be tested quickly? Are the contracts with service providers designed to accommodate such response times? These questions will be more decisive for resilience in the future than the number of installed security products.

A practical example illustrates the difference. A medium-sized industrial company operates a website with a product catalog, a dealer portal, and an internal service portal. If it can be proven that all three applications are running in a centrally managed environment with current PHP versions, the update can be installed after a brief check, and monitoring can be intensified. However, if it is unknown that the service portal is running on an old server from a previous agency, a routine measure becomes a risk to customer data, service processes, and supply chain communication.

The real lesson from PHP2Shell

A sober assessment reveals that PHP2Shell is neither the end of the world nor a typical patch day. The fixes are available, major infrastructure providers reacted quickly, and no successful mass compromise was publicly documented in the initial hours. At the same time, several developments are converging here that structurally increase the risk. These include a widely used core component, a large number of outdated versions, the premature disclosure of details, and a technology that makes sophisticated attacks cheaper.

The clearly reasoned perspective is therefore this: The most important economic effect of PHP2Shell is the reassessment of technical debt. Outdated software was long considered an efficiency problem that could be postponed. In the age of AI-powered vulnerability research, it is becoming an immediate liability, operational, and reputational risk. Companies that understand their digital infrastructure, update it quickly, and practice emergency responses achieve a measurable return on security. Conversely, those who rely on the complexity of an attack as protection are betting on a barrier that is currently crumbling.

From visibility to trust: Your scalable path with Xpert.Digital - Image: Xpert.Digital

In industrial B2B, sustainable business relationships rarely emerge overnight. They develop step by step – through visibility, professional relevance, recurring touchpoints, and growing trust. Xpert.Digital's 4-stage model addresses precisely this: It offers a structured path that begins with a manageable entry point and can evolve into deeper collaboration in business development if needed.

Instead of relying on loud marketing promises, this model puts the relationship at the forefront. Companies start with clearly defined, easily calculable measures and then decide, based on their own experience, how far they want to expand the collaboration. A key factor for this undisturbed trust-building process: The platform completely avoids annoying advertising ads, so the editorial focus remains solely on the companies' expertise.

More information here:

• From visibility to trust: Your scalable path with Xpert.Digital

☑️ Our business language is English or German

☑️ NEW: Correspondence in your native language!

Konrad Wolfenstein

I and my team are happy to be available to you as your personal advisor.

You can contact me by filling out the contact form here [email protected]:or simply call me at +49 7348 4088 965. My email address is

I'm looking forward to our joint project.

☑️ SME support in strategy, consulting, planning and implementation

☑️ Creation or realignment of the digital strategy and digitization

☑️ Expansion and optimization of international sales processes

☑️ Global & Digital B2B trading platforms

☑️ Pioneer Business Development / Marketing / PR / Trade Fairs