PHP2Shell: Two Critical PHP Vulnerabilities Put Millions of Websites at Risk

Two critical memory-corruption vulnerabilities in PHP can allow unauthenticated remote code execution, even when the application itself contains no exploitable bug. Here’s how PHP2Shell works, why it matters, and what administrators need to do.

There is something particularly unsettling about a vulnerability that doesn’t require a mistake in your application.

You can write clean PHP. You can validate every input, escape every output, keep your dependencies updated, and follow every secure coding guideline.

And still, an attacker might compromise your server through a vulnerability in the PHP interpreter itself.

That is what makes PHP2Shell such a significant security disclosure.

On October 21, 2026, the PHP development team released emergency updates addressing two critical vulnerabilities:

CVE-2026-109618: Remote code execution through out-of-memory corruption.
CVE-2026-109619: Remote code execution through stale global state.

Both carry a CVSS v4.0 score of 9.2 (Critical).

The vulnerabilities affect PHP’s internal memory management and request lifecycle. Under vulnerable conditions, attackers can execute code without authentication or access sensitive information left in process memory.

Researchers have demonstrated successful exploitation against WordPress, Drupal, and Joomla. But none of those applications is the underlying cause.

The vulnerability is in PHP itself.

And that changes the scale of the problem.

Why PHP2Shell Is Such a Serious Vulnerability

PHP remains one of the foundations of the modern web.

According to W3Techs statistics referenced by the researchers, PHP powers approximately 70% of websites whose server-side programming language is identified.

That figure describes PHP’s overall market presence, not the percentage of websites confirmed to be vulnerable or exploitable.

Nevertheless, the potential attack surface is enormous.

PHP supports applications ranging from small personal blogs to major e-commerce platforms, enterprise applications, content-management systems, and government websites.

Popular software built on PHP includes:

WordPress
Drupal
Joomla
Magento / Adobe Commerce
Laravel applications
Symfony applications
Moodle
MediaWiki
Nextcloud

The important detail is where PHP2Shell exists.

Most application-security vulnerabilities arise because an application processes untrusted input incorrectly.

Examples include SQL injection, command injection, authentication bypass, and insecure deserialization.

PHP2Shell operates at a lower level.

The vulnerabilities affect how PHP initializes, maintains, and releases internal memory while handling HTTP requests.

In certain scenarios, exploitation can occur before the application starts executing its own PHP code.

This means that even a trivial application could be exposed if it runs on a vulnerable runtime and an exploitable server configuration.

For an attacker, this is an attractive target. Instead of finding a vulnerability in every individual PHP application, they can investigate weaknesses shared by many applications running on the same underlying technology.

Understanding the Two PHP2Shell Vulnerabilities

PHP2Shell refers to two related vulnerability classes involving memory corruption.

Although the vulnerabilities share similarities, their underlying failure modes are different.

CVE-2026-109618: Remote Code Execution Through Out-of-Memory Corruption

PHP includes mechanisms to stop scripts when they consume excessive memory.

The memory_limit setting is one such mechanism.

Normally, a memory allocation failure should terminate the relevant operation safely.

However, PHP historically used a mechanism based on longjmp() to escape from certain fatal error conditions.

This allows execution to jump out of the current context without following the ordinary function-return sequence.

That behavior becomes dangerous when the interrupted operation has not finished initializing or cleaning up internal structures.

Consider the following simplified lifecycle:

PHP begins processing an incoming HTTP request.
Internal structures are allocated and initialized.
A memory allocation fails.
PHP aborts the current operation.
Some internal data remains partially initialized.
The request-shutdown procedure attempts to process that invalid data.

The critical weakness occurs when shutdown code treats invalid or incompletely initialized memory as legitimate internal state.

This can produce memory corruption.

Depending on the execution environment and the attacker’s ability to influence memory layout, the result may be a process crash or potentially arbitrary code execution.

Why Apache mod_php Is Particularly Exposed

One of the most important findings concerns Apache deployments using mod_php.

In this architecture, PHP executes inside Apache worker processes.

The PHP security advisory explains that the request-shutdown procedure can execute even when request initialization fails.

Consequently, an attacker-controlled HTTP request can trigger the vulnerable condition during PHP’s own request processing, before application-specific code begins.

Researchers confirmed full unauthenticated remote code execution against affected mod_php configurations with default settings.

This is significant because application-level input validation cannot protect code that has not yet started running.

PHP-FPM behaves differently.

When request startup fails, PHP-FPM can terminate the affected worker, avoiding that particular cleanup path. However, other out-of-memory conditions after successful startup may still reach unsafe states.

The PHP advisory treats PHP-FPM as potentially susceptible to this vulnerability class, while distinguishing the demonstrated mod_php exploit from paths that had not been fully validated for that specific CVE.

Different PHP execution environments have different exploit conditions. None of that is a reason to delay patching.

CVE-2026-109619: Remote Code Execution Through Stale Global State

The second vulnerability involves PHP retaining references to memory that has already been released.

This is a classic memory-safety problem commonly known as a use-after-free.

PHP workers can handle multiple HTTP requests during their lifetime.

Although individual requests have their own memory allocations, some internal global state persists inside the worker.

That state must be reset correctly when a request finishes.

The problem arises when a reference to request-owned memory survives after the request has ended.

A subsequent request may then access the stale reference.

A simplified sequence looks like this:

Request A initializes internal PHP state.
A fatal error interrupts an operation before cleanup completes.
Request A ends and its memory is released.
The worker retains a reference to the released memory.
Request B reaches an operation that accesses this stale reference.
PHP processes memory that no longer belongs to the original object.

An attacker who can influence the sequence of operations and the relevant memory layout may be able to turn this condition into memory corruption or remote code execution.

Researchers also demonstrated scenarios where sensitive process-memory contents could be exposed without first obtaining code execution.

That distinction matters.

A vulnerability that leaks authentication tokens or other secrets may be highly consequential even when it does not produce a shell.

Session Upload Progress and Request Lifecycle

One particularly interesting attack path involves PHP’s session upload-progress functionality.

This feature can interact with session state while multipart HTTP requests are being processed.

Importantly, some of this processing occurs before normal request initialization.

The researchers showed how interrupted session processing could leave internal state that a subsequent request might incorrectly reuse.

Other identified paths involve fatal-error backtraces, diagnostic handling, and related runtime state.

The underlying issue is broader than one configuration option or one session feature.

It is a failure to guarantee that request-owned memory cannot be accessed after its lifetime ends.

This is precisely why the PHP team chose to address the underlying lifecycle problems rather than patch only individual demonstrated exploit paths.

Why This Is Not Just Another WordPress Vulnerability

A critical distinction needs to be made.

WordPress, Drupal, and Joomla were used to demonstrate exploitation, but that does not mean researchers discovered the same application vulnerability in all three platforms.

The common vulnerable component was PHP.

Wiz Research demonstrated unauthenticated remote code execution against representative deployments of these CMS platforms using vulnerable PHP environments.

Those demonstrations establish that exploitation is possible in practical application stacks.

They do not establish that every installation of those platforms can be exploited identically.

Factors influencing exploitation include:

PHP version and build.
Web-server integration.
Available PHP extensions.
Memory-management behavior.
Application execution paths.
Runtime configuration.
Worker lifecycle.
Frontend HTTP request handling.

This distinction is essential for evaluating risk correctly.

A server running a vulnerable PHP version needs urgent attention, but the specific exploitability of an individual deployment can depend on environmental conditions.

At the same time, security teams should not wait for an attacker to reproduce the exploit against their exact infrastructure before applying the official fix.

The Role of AI in Discovering PHP2Shell

Perhaps the most interesting aspect of this disclosure is how the vulnerabilities were investigated.

PHP2Shell represents a major example of AI-assisted vulnerability research against mature, widely deployed software.

Researchers from Calif, Wiz, and OpenAI independently contributed findings and exploit research, with the PHP security team coordinating the fixes.

The research used frontier AI models, including GPT-5.6 Sol and Gemini 4 Argon.

Wiz also reports using its own AI-assisted research environment, Wiz Atlas.

But it would be inaccurate to say that an AI model independently discovered, exploited, and fixed PHP without human expertise.

Experienced researchers selected targets, investigated memory behavior, verified findings, developed exploitation strategies, and coordinated responsible disclosure.

AI accelerated parts of that work.

Why AI Made a Difference

Memory-corruption exploitation requires understanding details that can vary substantially across environments.

A researcher may need to reason about object lifetimes, memory allocation, execution flow, process state, and environmental differences.

Even after identifying a memory-safety bug, converting it into a reliable exploit can require extensive experimentation.

AI agents can help with:

Navigating large native-code repositories.
Understanding complex control flow.
Identifying related error-handling paths.
Generating and evaluating hypotheses.
Assisting with debugging.
Comparing behavior across versions.
Developing and validating candidate patches.

The Wiz team reports that AI assistance substantially reduced the effort required to adapt its research across different PHP environments.

This is important because some vulnerabilities remain unexploited not because they are inherently safe, but because turning them into reliable attacks requires significant expertise and effort.

AI may be changing the amount of effort needed to cross that barrier.

That is a much more important development than simply generating more vulnerability reports.

A Vulnerability With a Long History

The PHP Foundation’s account of this incident is particularly revealing.

The underlying out-of-memory problem did not suddenly appear in 2026.

Related concerns had been identified years earlier.

In 2024, a security audit organized through OSTIF and carried out by Quarkslab uncovered evidence associated with the out-of-memory problem.

A concrete remote exploitation path had not yet been established.

Developing a safe fix was also difficult.

The PHP security team faced competing requirements involving compatibility, performance, third-party extensions, and the possibility that a proposed fix could introduce new problems.

Work stalled.

The PHP Foundation has publicly acknowledged that resource limitations and its decision-making process contributed to the delay.

That admission is important.

Maintaining a language runtime used by a substantial portion of the internet is a tremendous responsibility.

Yet deep security work in open-source infrastructure frequently depends on a relatively small number of specialists.

Once the 2026 research demonstrated practical remote code execution, the urgency changed dramatically.

The problem was no longer an obscure memory-management concern with uncertain impact.

It was a confirmed critical vulnerability affecting a foundational software component.

The Disclosure Timeline

Date	Development
2024	Earlier security audit investigates the out-of-memory issue
July 30, 2026	Calif begins its PHP research engagement
August 11	Calif and OpenAI independently report critical findings related to the root cause
August 19–24	Wiz identifies and reports additional exploitation paths
September	Further research and coordinated patch development continue
October 20	CVE identifiers circulate before the planned disclosure
October 21	PHP publishes emergency security updates and technical advisories

The disclosure process also encountered difficulties.

According to the PHP Foundation, information circulated publicly before the intended release date, and early proof-of-concept material began spreading.

The project accelerated the security release while distributors and infrastructure providers prepared updates.

Cloudflare reported observing attack traffic before the official public disclosure and deployed protective rules.

At the time of the PHP Foundation’s release statement, its security team had not identified a functional public exploit in the proof-of-concept material it reviewed.

These observations describe different types of evidence. Attack traffic does not automatically mean a successful compromise.

Still, this is a warning about how quickly a coordinated disclosure window can narrow.

Are Attackers Exploiting PHP2Shell?

As of October 22, Cloudflare has publicly reported traffic targeting PHP2Shell.

The company says attackers adjusted their requests in an effort to evade deployed protections.

That provides evidence of active exploitation attempts.

However, it is important to distinguish several states:

Vulnerability confirmed: Researchers have demonstrated that the underlying flaw exists.

Remote code execution demonstrated: Researchers reproduced code execution in controlled environments.

Exploitation attempted in the wild: Security telemetry shows traffic attempting to trigger the weakness.

Successful real-world compromise confirmed: Investigators have evidence that a production system was actually compromised.

These are not interchangeable statements.

At the time of writing, the public information reviewed supports confirmed vulnerability exploitation in research environments and observed attack attempts against internet-facing systems.

It does not establish a verified count of successfully compromised production servers.

Given the scope of PHP deployment and the availability of technical details, administrators should not assume that waiting for such confirmation is a reasonable risk-management strategy.

Which PHP Versions Are Vulnerable?

The PHP project released patched versions on October 21, 2026.

PHP branch	Vulnerable versions	First fixed version
PHP 8.5	Earlier than 8.5.12	8.5.12
PHP 8.4	Earlier than 8.4.27	8.4.27
PHP 8.3	Earlier than 8.3.36	8.3.36
PHP 8.2	Earlier than 8.2.35	8.2.35
PHP 8.1 and older	Affected legacy versions	Vendor backport or supported-version upgrade required

The issue affects PHP versions dating back to the PHP 5.4 era, although the specific vulnerability paths and conditions differ.

PHP 8.1 and older are no longer supported by the upstream PHP project.

The PHP security team has published minimal source backports for certain older branches, while some Linux distributions and commercial support providers supply their own patched packages.

PHP 8.2 is also approaching end of life on December 31, 2026.

What About Linux Distribution Packages?

There is an important operational detail.

A Linux distribution may backport the security fix without changing PHP’s upstream version number to one of the releases listed above.

Therefore, a version string alone may not establish whether a vendor-maintained package contains the fix.

Administrators should verify both the installed package version and the security status published by their distribution or hosting provider.

Do not assume that every older-looking version string represents an unpatched package.

And do not assume that an application framework upgrade also updates PHP.

How to Check Your Environment

The first priority is identifying which PHP runtime is actually serving web requests.

1. Check the Installed PHP Version

On a server where PHP is available through the command line:

php -v

This displays the PHP CLI version.

However, the PHP command-line interpreter may not be the same installation used by Apache, PHP-FPM, or another application runtime.

A server may contain multiple PHP versions simultaneously.

For that reason, administrators should also check their web-server configuration and the PHP processes serving each application.

2. Identify PHP Worker Processes

On a Linux system, an initial process inventory can help:

ps -eo pid,user,comm,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'

This is a discovery step, not a complete vulnerability assessment.

Identify the PHP version, package, and configuration associated with each active worker.

3. Check Container Images

If applications use Docker or Kubernetes, review the PHP runtime version inside every deployed image.

Do not rely exclusively on the image tag.

Tags may move, and running containers may still use older images.

The relevant question is which patched PHP runtime is present in the actual deployed artifact.

4. Verify Distribution Security Updates

Consult the security advisory for the distribution or hosting provider.

For managed hosting, request confirmation that the PHP runtime has been updated or that an equivalent vendor-supported backport has been applied.

If the environment contains legacy PHP versions without a supported security-update path, prioritize migration.

How to Protect Your Servers Against PHP2Shell

The PHP security team is explicit:

Installing a fixed PHP release is the only complete remediation.

Other configuration measures may reduce exposure to specific exploitation paths, but they cannot guarantee protection against every variant.

1. Update PHP Immediately

Upgrade every affected runtime to the relevant fixed release or install the equivalent vendor-provided security package.

Restart Apache, PHP-FPM, and other long-running PHP processes as appropriate.

Verify that all workers are running patched code.

This includes production servers, staging environments, development infrastructure exposed to external users, containers, and managed application platforms.

2. Review Temporary Memory-Limit Mitigations Carefully

The PHP security advisory describes temporarily setting:

memory_limit = -1

This can remove the predictable PHP-level memory-limit failure involved in certain demonstrated attack paths.

However, it does not eliminate the underlying vulnerability.

It also changes resource-exhaustion behavior.

Without an appropriate operating-system memory boundary, a PHP worker may consume excessive memory and affect server availability.

The PHP team recommends carefully designed container or cgroup controls when this mitigation is necessary.

This should be treated as an emergency risk-reduction option for administrators who understand the operational consequences, not as a universal recommendation for production PHP configuration.

3. Disable Session Upload Progress if Unnecessary

One of the confirmed vulnerability paths involves PHP’s session upload-progress functionality.

Applications that do not require it can consider disabling:

session.upload_progress.enabled = 0

The setting must be applied administratively before the relevant request processing occurs, and affected workers must be restarted.

This blocks a demonstrated attack path, but does not protect against all variants of PHP2Shell.

4. Restrict Unnecessary Request Complexity

Review limits on:

HTTP request body size.
Multipart form submissions.
Uploaded file sizes.
Input nesting depth.
Input-variable counts.
Request-processing resources.

These limits may reduce attack opportunities involving excessive memory consumption.

However, they must be compatible with legitimate application functionality.

They are defense-in-depth controls, not replacements for the patch.

5. Use WAF Protections as an Additional Layer

Cloudflare announced mitigations covering PHP2Shell.

Other security providers may offer equivalent protections.

WAF rules can reduce exposure to known attack techniques, particularly when administrators cannot immediately upgrade.

But memory-corruption vulnerabilities can have multiple exploitation paths.

A WAF rule does not make a vulnerable interpreter safe.

6. Reduce the Impact of a Compromised PHP Worker

Apply least privilege to the PHP execution environment.

Use separate service accounts where appropriate.

Avoid giving web workers unnecessary access to:

Sensitive configuration files.
Cloud administrative credentials.
Deployment secrets.
Other applications on the same host.
Privileged operating-system functionality.

SELinux, AppArmor, container isolation, and appropriate filesystem permissions can help constrain the consequences of successful exploitation.

How to Investigate Possible PHP2Shell Attacks

Because these vulnerabilities involve request handling and memory corruption, conventional application logs may not contain a complete explanation of what happened.

Security teams should correlate several sources of evidence.

HTTP and Web-Server Logs

Look for unusual patterns involving multipart requests, repeated failures, and unexpected behavior preceding worker crashes.

Potential indicators include:

Repeated unusual POST requests.
Unexpected bursts of HTTP 500 responses.
Malformed or unusually complex multipart requests.
Repeated requests associated with PHP worker failures.

These are investigative signals, not proof of exploitation.

PHP Error Logs

Investigate unexplained memory-exhaustion errors and fatal failures.

Particularly relevant messages may include:

Allowed memory size exhausted

However, memory errors can also result from legitimate application problems.

They should be interpreted alongside other evidence.

Worker and Process Behavior

Investigate:

Unexpected PHP worker crashes or restarts.
Web-server processes spawning shells or download utilities.
Unusual child processes.
Unexpected outbound connections.
Changes to files or scheduled tasks.

Application and Credential Integrity

If compromise is suspected, investigate whether attackers established persistence.

Check for unfamiliar PHP files, modified plugins, unexpected administrative accounts, and unauthorized changes to application configuration.

Consider the possible exposure of credentials that may have been accessible in PHP process memory.

Patching a vulnerability does not remove a backdoor installed before the update.

Where compromise is suspected, preserve forensic evidence and follow a structured incident-response process.

Why PHP2Shell Reminds Me of Heartbleed and Log4Shell

Security researchers often compare major vulnerabilities with earlier internet-scale incidents.

Two obvious historical references are Heartbleed and Log4Shell.

Heartbleed demonstrated how a flaw in a widely used cryptographic library could expose sensitive process memory.

Log4Shell demonstrated how unexpected functionality inside a common software dependency could create remote-code-execution risks throughout the software ecosystem.

PHP2Shell shares some characteristics with both.

Like Heartbleed, it can expose sensitive memory.

Like Log4Shell, it affects foundational software used across countless applications.

But the exploitation mechanisms are fundamentally different.

PHP2Shell involves complex memory-lifecycle failures and the interaction of request handling with error recovery.

It would be premature to conclude that its real-world impact will equal or exceed those historical vulnerabilities.

Nevertheless, it deserves a similar level of operational seriousness.

The broader lesson is consistent:

The security of an application depends on much more than the code its developers wrote.

What PHP2Shell Tells Us About the Future of Vulnerability Research

There are three observations I consider particularly important.

1. Mature Software Still Contains Deep Vulnerabilities

PHP has existed for decades.

Its code has been examined by security researchers, developers, commercial security firms, and automated tools.

Yet these issues persisted.

The explanation is not necessarily that researchers were careless.

Some vulnerabilities are extremely difficult to turn into reliable exploits.

They depend on subtle timing, object lifetimes, memory allocation, and interactions between components.

Security analysis cannot stop at obvious input-validation mistakes.

2. AI Is Changing the Economics of Exploit Development

A vulnerability previously considered too complex to exploit reliably may become more practical as analysis tools improve.

AI-assisted research can accelerate reverse engineering, code navigation, hypothesis testing, and debugging.

It can also help defenders discover variants and verify fixes.

This is a dual-use development.

The same improvements that help defenders identify critical weaknesses may eventually help attackers exploit them.

We should expect defenders to have less time between technical disclosure and attempted exploitation of certain vulnerabilities.

3. Open-Source Security Needs More Than Automated Findings

The PHP Foundation’s disclosure also illustrates a structural challenge.

A powerful AI system can identify a potential bug.

But someone must still determine whether the finding is real.

Someone must understand its root cause, develop a compatible fix, test affected versions, coordinate distributors, and prepare the ecosystem.

Those activities require people with deep knowledge of the software.

If AI increases the volume of vulnerability findings, the pressure on small maintainer teams will only grow.

The long-term solution cannot simply be generating more reports.

We also need sustainable funding, better testing infrastructure, coordinated disclosure, and more effective ways to validate security fixes.

Final Thoughts

PHP2Shell is a serious vulnerability disclosure.

Two critical weaknesses in the PHP interpreter can enable unauthenticated remote code execution and memory disclosure under affected conditions.

The vulnerabilities reach beneath application frameworks and can compromise systems even when application developers have followed secure coding practices.

The immediate recommendation is straightforward:

Identify affected PHP installations, apply the official security updates, verify running workers, and investigate suspicious activity.

But the longer-term lesson is more interesting.

For years, the complexity of finding and exploiting certain memory-corruption vulnerabilities acted as a practical barrier.

AI-assisted security research may be reducing that barrier.

That does not mean automated exploitation has become trivial.

It means that some attacks that previously required exceptional effort may now become achievable by smaller teams with powerful tools.

Defenders need to adapt accordingly.

We should stop treating vulnerability discovery, exploitability, and remediation as isolated activities.

A vulnerability is not resolved simply because an advisory exists.

It is not necessarily exploitable merely because a vulnerable component is installed.

And it is not remediated simply because someone reports that a patch was deployed.

Security requires understanding the full technical context and verifying the actual outcome.

PHP2Shell is another reminder that what protects us is not the complexity of software, but our ability to understand, test, and secure it.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the collective name for two critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619, involving unsafe memory handling and request-lifecycle state.

Can PHP2Shell be exploited without authentication?

Yes. Researchers demonstrated unauthenticated remote code execution against affected PHP deployments, including Apache mod_php configurations and representative CMS installations.

Does PHP2Shell affect WordPress?

WordPress installations using vulnerable PHP runtimes may be affected. The issue is in PHP itself, rather than in WordPress application code. Actual exploitability depends on the deployment and applicable vulnerability path.

Does PHP-FPM prevent PHP2Shell?

No. PHP-FPM’s worker lifecycle prevents certain demonstrated startup-related paths, but researchers have confirmed remote code execution through application-dependent paths. PHP-FPM installations must also be patched.

Is PHP2Shell being exploited in the wild?

Cloudflare reported observing attack traffic targeting the vulnerabilities before public disclosure. That confirms exploitation attempts, but not a verified count of successful production compromises.

Can a WAF prevent PHP2Shell?

WAF protections may block known techniques, but they do not completely remediate vulnerabilities in the PHP runtime. Installing a patched PHP release remains essential.

Which PHP versions fix PHP2Shell?

The first fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Some distributions provide backported patches using their own package-version schemes.

Did AI discover PHP2Shell?

AI-assisted research contributed substantially to identifying, developing, and validating exploitation paths. Human researchers, PHP maintainers, and security organizations performed investigation, coordination, and patch development.