Understanding the October 2026 PHP security issue, its root causes, and open-source collaboration are helping strengthen the PHP ecosystem.

PHP has been powering the web for decades. From WordPress and Drupal to Laravel applications, enterprise platforms, and APIs, it remains one of the most widely used server-side programming languages.

But October 2026 brought an important reminder to the PHP ecosystem:

Even if your application code is secure, the runtime executing that code might not be.

On October 21, 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities that could allow unauthenticated attackers to execute code remotely on vulnerable servers.

The vulnerabilities were named PHP2Shell and assigned:

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

Both received a CVSS v4.0 severity score of 9.2.

What makes this incident particularly interesting is that the vulnerabilities were not caused by a poorly written Laravel controller, an insecure API endpoint, or an outdated Composer package.

They were rooted in PHP’s internal memory management and request lifecycle.

Let’s understand what happened, why it happened, and what we can learn from it as PHP developers.

1. What actually happened?

Security researchers at Wiz Research discovered two critical vulnerabilities in the PHP core engine.

The vulnerabilities could allow attackers to execute arbitrary code on affected servers without authentication.

This is particularly concerning because PHP is not just an application framework. It is the underlying runtime responsible for processing HTTP requests, managing memory, handling sessions, and executing application code.

Consequently, a vulnerability in the PHP engine can affect multiple applications running on the same vulnerable infrastructure.

The PHP team released security updates for the following branches:

PHP branchFixed versionPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35

The issue also affects older PHP branches, although their support and patch availability depend on the distribution or maintenance provider.

The important distinction is that these vulnerabilities exist below the application layer.

Your application might follow best practices, validate every request, use prepared SQL statements, and implement strong authentication. That does not automatically protect it from a vulnerability in the PHP runtime.

Source: PHP official security announcement.

2. Understanding the root cause

To understand these vulnerabilities, we need to look beyond everyday PHP development.

Most PHP developers work with objects, arrays, functions, classes, and frameworks. However, PHP itself is implemented in C.

The PHP engine manages memory, initializes internal structures, processes requests, and releases resources.

The two vulnerabilities exposed weaknesses in how PHP handles memory and internal state during exceptional execution paths.

Let’s examine them separately.

3. CVE-2026–109618: Remote Code Execution through Out-of-Memory corruption

Root cause: Incorrect handling of partially initialized internal request data during memory exhaustion.

PHP provides a configuration directive called:

memory_limit

For example:

memory_limit = 128M

This limits the amount of memory a PHP script can consume.

Imagine an application receiving a large multipart HTTP request containing file uploads and form fields.

During request processing, PHP allocates memory and initializes internal data structures to store information about the incoming request.

Now consider what happens when PHP reaches its configured memory limit while processing that request.

The engine can interrupt execution through its out-of-memory handling mechanism.

The problem discovered by researchers was that this interruption could happen while internal request data was only partially initialized.

When PHP subsequently performed cleanup, it could incorrectly treat incomplete internal data as valid.

This created an opportunity for memory corruption.

Why is this dangerous?

Think about a situation where a program attempts to release memory that was never properly initialized.

The memory location may contain unexpected data, potentially left over from previous allocations.

If an attacker can influence the surrounding memory layout and the request-processing sequence, this can become more than a simple application crash.

It can potentially become a path to arbitrary code execution.

The underlying engineering problem

The important issue is not simply that PHP ran out of memory.

Applications must be able to handle memory exhaustion safely.

The deeper problem was the interaction between:

  • Memory allocation.
  • Partial initialization of internal structures.
  • Exceptional control flow.
  • Resource cleanup.

This is a classic memory-safety problem.

4. CVE-2026–109619: Remote Code Execution through stale global state

Root cause: Internal request state surviving after the memory it depends on has been released.

This vulnerability involves another important concept in systems programming: object lifetime and memory ownership.

PHP processes requests using internal runtime structures.

Some server configurations reuse workers to handle multiple requests rather than starting a completely new process for every request.

Imagine the following sequence:

  1. A worker begins processing Request A.
  2. PHP creates internal request-related state.
  3. An exceptional condition occurs, such as a fatal error.
  4. The memory associated with part of that request is released.
  5. Some internal state still retains a reference to that released memory.
  6. The same worker receives Request B.
  7. Before normal initialization resets everything, the stale state can be accessed.

This creates a use-after-free-style memory safety problem.

What is a use-after-free vulnerability?

Consider a simplified C example:

int *data = malloc(sizeof(int));
*data = 100;
free(data);

// Dangerous: accessing released memory
printf("%d", *data);

After calling free(), the program should no longer use that memory through the old pointer.

However, the pointer still exists.

It now references memory that the program no longer owns.

The memory might subsequently be reused for something else.

This is known as a use-after-free vulnerability.

In PHP2Shell, the problem was more complicated than this simplified example. It involved internal PHP request state surviving beyond the lifetime of its backing memory.

The interesting part: AI-assisted vulnerability research

One of the most interesting aspects of PHP2Shell is how the vulnerabilities were discovered.

According to Wiz Research, the underlying weaknesses had existed in the PHP codebase for more than a decade.

Finding the problematic code was only part of the challenge.

Researchers also needed to understand how memory was allocated, how internal structures were reused, and how multiple weaknesses could be combined into a working exploit.

This required considerable investigation and experimentation.

AI-assisted research helped reduce that complexity.

Wiz reported using several AI systems, including Gemini 4 Argon and GPT-5.6 Sol, alongside its own research tools.

These systems helped researchers investigate code paths, explore memory-management behaviour and develop and validate exploit techniques.

This particularly interesting from a software engineering perspective.

For years, AI discussions in development have focused primarily on generating code, writing tests and improving productivity.

But this research demonstrates another important direction:

AI can also help us understand, investigate and improve the security of the software we already depend on.

5. A positive example of open-source collaboration

Another important aspect of this incident was the coordinated response.

The discovery involved collaboration between Wiz Research, the PHP security team and other technology organizations.

The researchers followed a responsible disclosure process, allowing the PHP team to investigate and prepare fixes before the public release.

The wider ecosystem also contributed guidance, detection and mitigation support.

This is one of the strengths of mature open-source communities.

PHP is used across millions of applications and countless infrastructure environments.

No single company or development team can independently understand every deployment configuration.

Open collaboration makes it possible to identify problems, share knowledge and improve the technology for everyone.

The PHP team’s coordinated security releases across multiple branches are a good example of the maintenance work required to support a widely used programming language.

Security is not just about discovering vulnerabilities.

It is also about how effectively the community responds to them.6. What should PHP developers and engineering teams do?

The first priority is to update affected PHP installations.

The PHP security team recommends upgrading to the patched releases:

PHP 8.5.12+
PHP 8.4.27+
PHP 8.3.36+
PHP 8.2.35+

Check the actual PHP runtime used by your web server, not just the CLI version:

php -v

For PHP-FPM deployments, also verify the PHP-FPM service and its installed package version.

For Docker-based applications, check the PHP image:

FROM php:8.4.27-fpm

Rebuild and redeploy the image after updating.

Remember that changing a Dockerfile alone does not update containers that are already running.

Additional security checks

1. Review memory configuration

Check:

memory_limit
post_max_size
upload_max_filesize

The PHP security advisory recommends specific temporary configuration changes to reduce exposure to the memory-corruption attack path.

These are supplementary measures, not substitutes for patching.

2. Review session upload progress

The PHP advisory also recommends:

session.upload_progress.enabled = 0

This helps block confirmed attack paths associated with stale internal state.

Apply this at the server or PHP-FPM configuration level and restart the workers.

3. Review your PHP version support policy

PHP 8.2 reaches end of life on December 31, 2026.

Teams still running PHP 8.1 or older should pay particular attention to their maintenance arrangements and plan an upgrade.

4. Check your infrastructure

Do not assume that updating the application dependencies updates PHP itself.

A forgotten container or staging server can remain vulnerable even after the main application has been updated.

6. An interesting aspect: How AI changed vulnerability research

One particularly interesting aspect of this incident is how the vulnerabilities were discovered and investigated.

According to Wiz Research, the underlying weaknesses had existed in PHP for more than a decade.

The researchers highlighted how frontier AI models substantially reduced the time and effort required to understand these complex memory-management issues and develop working exploits.

This is an important development for the software engineering industry.

AI is increasingly becoming a tool for both defensive security research and offensive vulnerability discovery.

It can help researchers:

  • Analyse large codebases.
  • Identify suspicious memory-management patterns.
  • Trace complex execution paths.
  • Understand interactions between internal components.
  • Investigate potential exploit conditions.
  • Develop and validate proof-of-concept exploits.

However, there is another side to this development.

If AI makes vulnerability discovery easier, it can also reduce the time available for organizations to identify and fix security problems before attackers exploit them.

Security teams will increasingly need to treat vulnerability management as a continuous engineering responsibility rather than an occasional maintenance activity.

Conclusion

PHP2Shell is an important security discovery, but I believe the bigger story is about engineering progress.

A weakness that existed in the PHP codebase for many years was investigated, demonstrated, responsibly disclosed and addressed through coordinated security releases.

It also showed how AI can contribute to vulnerability research and how open-source collaboration can help protect a widely used technology.

For PHP developers, the lesson is not to lose confidence in the language or the ecosystem.

It is to become more informed about the systems we build on.

We should continue writing clean application code, but also invest time in understanding runtimes, memory management, infrastructure, testing and security practices.

Good software engineering is not about assuming that nothing will go wrong. It is about building systems, processes and teams that can identify problems, respond effectively and continuously improve.

And that is what makes a mature software ecosystem stronger over time.

Further reading

  1. PHP Official Security Advisory — October 21, 2026
  2. Wiz Research — PHP2Shell: Critical PHP vulnerabilities
  3. CERT-EU — Critical Vulnerabilities in PHP
  4. Qualys — PHP2Shell: Find, Mitigate, and Patch

Disclaimer: This article is an educational explanation of publicly disclosed vulnerabilities. Technical details and mitigation recommendations should always be checked against the official PHP security advisories and the exact runtime deployed in your environment.