Post cover image

October 22, 2026

PHP2Shell Explained: Understanding CVE-2026–109618 and CVE-2026–109619 from the Memory Up

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, provide an excellent opportunity to understand how seemingly small…

By Yanis BOUDJELIDA

13 min read

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, provide an excellent opportunity to understand how seemingly small mistakes in memory management can eventually become Remote Code Execution vulnerabilities.

Understanding them properly requires more than memorizing that one involves an Out-of-Memory condition and the other a Use-After-Free. We first need to understand how memory, pointers, PHP workers, request lifecycles, and memory allocators interact.

This article builds those concepts from the ground up before connecting them to the vulnerabilities.

1. The concepts you need to understand

Before analyzing the CVEs, we need the following concepts:

  1. Process and process memory
  2. Stack and heap
  3. Memory allocation
  4. Pointers and memory addresses
  5. malloc() and free()
  6. Logical memory release vs physical erasure
  7. Memory allocator
  8. Dangling pointers
  9. Use-After-Free
  10. Memory reuse
  11. Heap grooming
  12. Memory corruption
  13. Out-of-Memory conditions
  14. memory_limit
  15. Partial initialization
  16. Program invariants
  17. Error handling and longjmp()
  18. Global state
  19. Request-scoped memory
  20. PHP workers
  21. Worker persistence
  22. Request lifecycle
  23. mod_php
  24. PHP-FPM
  25. Producer/consumer exploitation patterns
  26. Memory exploitation primitives
  27. Remote Code Execution

Let's examine them one by one.

2. Processes and memory

When PHP executes, it runs inside a process.

A simplified representation is:

PHP process

┌──────────────────────┐
│ Program code         │
├──────────────────────┤
│ Global data          │
├──────────────────────┤
│ Heap                 │
│                      │
│ Dynamic allocations  │
│                      │
├──────────────────────┤
│ Stack                │
│ Local variables      │
│ Function calls       │
└──────────────────────┘

The operating system gives this process its own virtual address space.

Addresses could conceptually look like:

0x1000
0x2000
0x3000
...

These addresses allow the program to locate its data.

3. Stack vs Heap

Two important memory areas are the stack and the heap.

Stack

The stack is mainly associated with function execution and local variables.

For example:

void hello() {
    int age = 22;
}

age can live on the stack.

When hello() returns, its stack frame disappears automatically.

Conceptually:

hello()

STACK
┌──────────┐
│ age = 22 │
└──────────┘

return

STACK
┌──────────┐
│          │
└──────────┘

Heap

The heap is used for dynamically allocated objects whose lifetime cannot simply be tied to a function returning.

Conceptually:

ptr = malloc(100);

could produce:

HEAP

0x5000
┌───────────────────┐
│ 100-byte region   │
└───────────────────┘

ptr = 0x5000

PHP makes extensive use of dynamic memory for strings, arrays, hash tables, objects, request data, parser structures and other runtime information.

Both CVEs discussed in this article are therefore closely related to heap and object lifetime management.

4. Pointers

A pointer is fundamentally a variable containing a memory address.

None

Suppose:

ptr = 0x5000

Then:

ptr
 │
 ▼
0x5000
┌─────────────┐
│ Object A    │
└─────────────┘

The important distinction is:

pointer ≠ object

The pointer contains the location of the object.

This becomes critical when the lifetime of the object and the lifetime of the pointer become inconsistent.

5. Memory allocation

When PHP needs memory, it asks its memory management system for an allocation.

Simplifying heavily:

ptr = malloc(size);

The allocator finds an available region:

Heap

0x1000 [used]
0x2000 [FREE]
0x3000 [used]

and may return:

ptr = 0x2000

Now:

0x2000 [used]

The exact mechanisms used by PHP and the underlying allocator are more complicated, but this model is sufficient for understanding the vulnerabilities.

6. What free() really means

None

Suppose:

ptr = 0x2000

0x2000
┌─────────────┐
│ Object A    │
└─────────────┘

Then the program performs:

free(ptr);

A common misconception is that the memory becomes physically empty.

It does not necessarily.

free() primarily means:

This allocation is no longer owned by the caller and may be reused.

Conceptually:

BEFORE

0x2000 [Object A]

AFTER free()

0x2000 [AVAILABLE]

Some of the old bytes might temporarily remain, while the allocator may also overwrite parts of the region with its own metadata.

The important property is that accessing the allocation through the old pointer is no longer valid.

7. Why the pointer still contains the address

None

This surprises many people.

Consider:

ptr = malloc(...);

free(ptr);

free(ptr) does not generally perform:

ptr = NULL;

Therefore:

Before:

ptr = 0x2000

After:

ptr = 0x2000

The allocator knows that the allocation associated with 0x2000 has been released.

But ptr is just a variable containing the number 0x2000.

It does not automatically know:

"is_free = true"

This distinction is fundamental.

8. The memory allocator

Think of the allocator as a hotel receptionist.

It keeps track of rooms:

Room 20 → occupied
Room 21 → occupied
Room 22 → free
Room 23 → occupied

If somebody requests a suitable room, the receptionist can assign Room 22.

Similarly:

malloc(...)
   ↓
allocator searches for suitable memory
   ↓
returns address

After:

free(ptr);

the allocator can mark that allocation as available for reuse.

This does not invalidate every other variable in the program that happens to contain the same address.

9. Dangling pointers

None

Consider:

ptr = 0x2000

followed by:

free(ptr);

We now have:

ptr
 │
 ▼
0x2000 [FREE]

ptr is called a dangling pointer.

It references memory whose original allocation is no longer alive.

A common defensive pattern is:

free(ptr);
ptr = NULL;

But even that does not solve every lifetime problem if aliases exist:

ptr1 = 0x2000;
ptr2 = 0x2000;

free(ptr1);
ptr1 = NULL;

Now:

ptr1 = NULL

ptr2 = 0x2000
       ↓
       freed allocation

ptr2 is still dangling.

10. Use-After-Free

A dangling pointer becomes especially dangerous when the program uses it.

Hence:

Use After Free.

Sequence:

allocate
   ↓
ptr → Object A
   ↓
free(Object A)
   ↓
ptr still contains address
   ↓
use ptr
   ↓
USE-AFTER-FREE

Sometimes this simply crashes the process.

Sometimes it does something much more dangerous.

11. Memory reuse

Suppose:

ptr = 0x2000

and then:

free(ptr);

The allocator now knows:

0x2000 = available

Later, another allocation occurs.

The allocator may reuse the same region:

new_ptr = 0x2000

Now:

old ptr ──────┐
              ▼
            0x2000
            ┌───────────┐
            │ Object B  │
            └───────────┘
              ▲
              │
new_ptr ───────┘

The old code may conceptually believe:

ptr → Object A

while reality is:

0x2000 → Object B

If the program interprets Object B according to Object A's structure, memory corruption can follow.

12. Heap grooming

None

This leads to an important exploitation concept: heap grooming.

An attacker may try to influence the arrangement of heap allocations.

Imagine:

AAAA | BBBB | CCCC | DDDD

Then BBBB is released:

AAAA | FREE | CCCC | DDDD

A stale pointer still references that location.

If a suitable later allocation occupies it:

AAAA | XXXX | CCCC | DDDD

the stale pointer now references XXXX.

Conceptually:

stale pointer
             │
             ▼
AAAA | XXXX | CCCC | DDDD

The goal of heap grooming is to make memory layout and reuse sufficiently predictable for exploitation.

It is important to understand that a Use-After-Free does not automatically mean RCE. Turning memory unsafety into reliable execution control is usually the difficult part.

13. Memory corruption

Memory corruption occurs when a program's assumptions about its memory are violated.

Examples include:

Buffer Overflow
Use-After-Free
Double Free
Out-of-bounds read/write
Uninitialized memory
Invalid pointer use

The two PHP vulnerabilities discussed here involve different paths toward unsafe memory state.

14. Out Of Memory — OOM

OOM means:

Out Of Memory.

PHP commonly enforces a memory limit such as:

memory_limit = 128M

Suppose PHP has already accounted for approximately:

127 MB

and needs another allocation.

Conceptually:

127 MB used
+
2 MB requested
──────────────
129 MB

limit = 128 MB

The allocation cannot proceed under that limit.

An OOM condition occurs.

OOM itself is not necessarily a security vulnerability.

The vulnerability depends on what state the program is in when the allocation fails and how that failure is handled.

15. Partial initialization

Imagine PHP needs to create:

Structure X

A
B
C
D

Initialization progresses:

A = initialized
B = initialized
C = initializing
D = not initialized

Then an allocation fails.

The structure is now only partially initialized.

A robust design must ensure that other code cannot mistakenly treat:

[A][B][?][?]

as:

[A][B][C][D]

This concept is central to CVE-2026-109618.

16. Program invariants

An invariant is an assumption that programmers expect to always remain true.

For example:

If global_context != NULL,
then global_context points to a fully initialized object.

Code elsewhere can then safely do:

if (global_context != NULL)
    cleanup(global_context);

without rechecking every field.

If an unusual error path leaves:

global_context != NULL

but the underlying structure is incomplete, the invariant has been broken.

The cleanup code is not necessarily wrong by itself.

The problem happened earlier when the system entered a state that was supposed to be impossible.

17. longjmp()

C provides mechanisms such as setjmp() and longjmp() for non-local control flow.

For our conceptual model, think of longjmp() as:

Stop what you are doing and jump back to a previously established recovery point.

Instead of:

Function C
   ↓
return error
   ↓
Function B handles error
   ↓
return error
   ↓
Function A handles error

you can conceptually get:

Function A
   ↓
Function B
   ↓
Function C
   ↓
ERROR
   │
   │ longjmp
   │
   └──────────────► recovery point

This is not inherently insecure.

The danger appears when code between those locations temporarily violates invariants and expects normal control flow to restore them.

18. Request-scoped memory

PHP handles HTTP requests.

A request may cause PHP to allocate memory for:

POST data
uploaded files
strings
arrays
objects
session information
parser metadata
errors
...

Much of that state only needs to exist while the current request is alive.

Conceptually:

Request A begins
      ↓
allocate request memory
      ↓
process request
      ↓
Request A ends
      ↓
release request memory

This distinction becomes essential for CVE-2026-109619.

19. Global state

Some state belongs to the longer-lived PHP runtime or worker rather than exclusively to one request.

Conceptually:

WORKER
│
├── global state
│
├── Request A memory
│
└── other runtime state

A dangerous situation appears when:

global state
     │
     ▼
memory belonging to Request A

Request A eventually disappears.

If the global reference survives, we can get:

global state
     │
     ▼
FREED MEMORY

That is precisely the kind of lifetime mismatch relevant to CVE-2026-109619.

20. PHP workers

None

A worker is a process that handles requests.

For example:

PHP-FPM master
      │
      ├── Worker 1
      ├── Worker 2
      ├── Worker 3
      └── Worker 4

Workers process PHP requests.

Crucially, workers are commonly reused.

Worker 2

Request A
   ↓
finish
   ↓
Request B
   ↓
finish
   ↓
Request C

This improves performance because PHP does not need to create a completely new process for every request.

But it also means that bugs involving improperly reset worker state can cross request boundaries.

21. Request lifecycle

A simplified PHP request lifecycle looks like:

HTTP request
     ↓
request startup
     ↓
input parsing
     ↓
PHP initialization
     ↓
application execution
     ↓
request shutdown
     ↓
cleanup
     ↓
worker reused

Both CVEs become much easier to understand once we ask:

At which stage does the state become inconsistent?

22. mod_php

With mod_php, PHP is loaded directly into Apache.

Conceptually:

Apache process
┌───────────────────────┐
│ Apache                │
│                       │
│ PHP module            │
│                       │
└───────────────────────┘

A request can therefore be handled inside an Apache process containing the PHP runtime.

This integration matters for the demonstrated CVE-2026-109618 exploitation path because of how PHP startup failure and shutdown interact in this environment.

23. PHP-FPM

PHP-FPM separates the web server from PHP execution.

For example:

Internet
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM master
   │
   ├── PHP worker
   ├── PHP worker
   └── PHP worker

Apache can also use PHP-FPM.

The lifecycle and failure behavior therefore differ from mod_php, which can affect exploitability.

24. Producer and Consumer

None

This model is especially useful for CVE-2026-109619.

The producer creates dangerous stale state.

Request A
   ↓
creates state
   ↓
state references Request A memory
   ↓
abnormal path
   ↓
Request A memory released
   ↓
reference survives

The consumer later uses it:

Request B
   ↓
same worker
   ↓
reads stale state
   ↓
Use-After-Free

So:

PRODUCER                     CONSUMER

Request A                    Request B
    │                            │
    ▼                            ▼
create state               same worker
    │                            │
    ▼                            ▼
free memory ───────────► stale state
                             │
                             ▼
                            UAF

25. Exploitation primitives

A memory corruption bug is not synonymous with RCE.

Attackers generally need useful capabilities, often called primitives.

Examples include the ability to:

read memory
write memory
control a pointer
control an object field
influence allocation placement

A simplified exploitation progression is:

memory bug
    ↓
useful memory primitive
    ↓
stronger control
    ↓
control-flow manipulation
    ↓
RCE

The exact exploitation chain depends heavily on the runtime, allocator, build, architecture and mitigations.

26. Remote Code Execution

RCE means:

Remote Code Execution.

An attacker can cause the remote system to execute attacker-chosen code.

Conceptually:

Attacker
   │
   │ network
   ▼
Web server
   │
   ▼
vulnerability
   │
   ▼
memory corruption
   │
   ▼
execution control
   │
   ▼
RCE

RCE does not automatically mean:

root

The resulting code normally starts with the privileges of the compromised process.

For a web service that may be an account such as:

www-data

Further privilege escalation would be a separate step.

Part II — Connecting everything to CVE-2026-109618

None

Now we can understand the first vulnerability properly.

The important concepts are:

memory_limit
      +
OOM
      +
partial initialization
      +
broken invariant
      +
non-local error handling
      +
request shutdown
      =
memory corruption

A simplified sequence is:

HTTP request
      ↓
PHP parses input
      ↓
allocations occur
      ↓
PHP approaches memory_limit
      ↓
internal structure starts changing
      ↓
another allocation is required
      ↓
OOM
      ↓
error handling interrupts operation
      ↓
intermediate state survives
      ↓
request shutdown
      ↓
cleanup assumes valid state
      ↓
memory corruption

The subtle point is that OOM itself is not the vulnerability.

The problem is:

PHP can encounter OOM while internal state is temporarily inconsistent, and a later cleanup path can operate on that state under assumptions that are no longer true.

Why timing the OOM matters

Imagine a 128 MB limit.

An attacker does not conceptually want:

100 MB
↓
huge allocation
↓
OOM

at an arbitrary location.

The interesting condition is:

Memory almost full
        ↓
PHP enters interesting operation
        ↓
state becomes intermediate
        ↓
next allocation fails
        ↓
OOM at vulnerable point

Think of a glass:

Capacity: 128 ml

██████████████████░
126 ml

PHP performs:

+0.5 → OK
+0.5 → OK

internal state changes

+3 → OOM

The OOM occurs while the program is in the sensitive intermediate state.

CVE-2026-109618 in one diagram

Attacker-controlled HTTP input
             │
             ▼
        PHP parsing
             │
             ▼
      memory pressure
             │
             ▼
      partial state
             │
             ▼
       allocation fails
             │
             ▼
            OOM
             │
             ▼
   non-local error handling
             │
             ▼
    broken PHP invariant
             │
             ▼
      request shutdown
             │
             ▼
      unsafe cleanup
             │
             ▼
     memory corruption
             │
             ▼
     possible primitives
             │
             ▼
            RCE

Part III — Connecting everything to CVE-2026-109619

None

The second vulnerability uses a different collection of concepts:

request-scoped memory
        +
persistent worker
        +
global state
        +
free()
        +
dangling reference
        +
next request
        =
Use-After-Free

Suppose Request A creates:

Worker global state

GLOBAL
   │
   ▼
0x5000

0x5000
┌────────────────────┐
│ Request A object   │
└────────────────────┘

Request A finishes.

Its request memory is released:

0x5000
┌────────────────────┐
│       FREE         │
└────────────────────┘

But imagine the worker still contains:

GLOBAL = 0x5000

We now have:

GLOBAL
   │
   ▼
0x5000 [FREE]

This is stale state.

Memory reuse makes it more dangerous

Later:

malloc(...)

may reuse that region:

0x5000
┌────────────────────┐
│ New Object B       │
└────────────────────┘

Now:

GLOBAL ──────┐
             ▼
           0x5000
             ▲
             │
new pointer ─┘

But the old code may interpret that address according to the old object's type and assumptions.

That can lead to memory corruption.

Why the same worker matters

Imagine:

Worker 1
Worker 2
Worker 3

Request A creates stale state inside:

Worker 2

If Request B reaches Worker 1, it does not necessarily see Worker 2's process-local state.

The relevant chain therefore looks like:

Request A
    ↓
Worker 2
    ↓
producer
    ↓
stale state

──────────────

Request B
    ↓
Worker 2
    ↓
consumer
    ↓
Use-After-Free

Worker reuse is therefore fundamental to understanding this vulnerability.

CVE-2026-109619 in one diagram

REQUEST A
                 │
                 ▼
             Worker X
                 │
                 ▼
       request memory allocated
                 │
                 ▼
GLOBAL ──────► Object A
                 │
                 ▼
         abnormal lifecycle
                 │
                 ▼
       Request A memory freed
                 │
                 ▼
GLOBAL ──────► FREE MEMORY
                 │
                 │
           stale reference
                 │
═════════════════╪══════════════════
                 │
                 ▼
             REQUEST B
                 │
                 ▼
          same Worker X
                 │
                 ▼
        stale GLOBAL accessed
                 │
                 ▼
         USE-AFTER-FREE
                 │
                 ▼
         memory corruption
                 │
                 ▼
        possible primitives
                 │
                 ▼
                RCE

Part IV — The fundamental difference

The easiest way to distinguish the vulnerabilities is this:

CVE-2026-109618

Something is used before it has safely finished becoming valid.

Construction:

████████░░░░
        │
        💥 OOM
        │
        ▼
incomplete state
        │
        ▼
later treated as valid

The central concept is:

partial initialization / broken invariant after OOM.

CVE-2026-109619

Something is used after it has stopped being valid.

Object A
   ↓
FREE
   ↓
old reference survives
   ↓
later access
   ↓
UAF

The central concept is:

object lifetime / stale state / Use-After-Free.

A useful memory trick is:

109618
──────────────
TOO EARLY

PHP treats something as usable
before its state is safely established.

109619
──────────────
TOO LATE

PHP continues using a reference
after its underlying memory lifetime ended.

Part V — A completely non-technical explanation

Imagine PHP as a hotel.

The PHP worker is one hotel employee.

Each HTTP request is a customer.

CVE-2026-109618 — The unfinished room

The employee prepares Room 42.

He:

  • cleans the floor,
  • changes part of the bedding,
  • starts preparing the bathroom.

Before everything is finished, the room becomes visible to the hotel's internal workflow.

Then:

The hotel suddenly runs out of supplies.

The employee has to stop immediately.

The room is only half prepared, but another internal process later assumes:

"If Room 42 is in this system, it must be completely ready."

It starts performing operations that only make sense for a properly prepared room.

Things go wrong.

That is CVE-2026-109618:

An unexpected OOM interrupts PHP while internal state is incomplete, but later code can operate under assumptions that state was valid.

CVE-2026-109619 — The old hotel key

Yanis receives:

Room 42

The hotel's system stores:

Yanis → Room 42

Yanis leaves.

The hotel correctly marks Room 42 as available.

But somebody forgot to remove the old reference:

Yanis → Room 42

Alice arrives.

The hotel reuses the available room:

Alice → Room 42

The old record still says:

Yanis → Room 42

If another system trusts that stale record, it now accesses Alice's room while believing it is still dealing with Yanis's room.

That is a Use-After-Free.

In memory:

ptr → 0x5000 [Yanis]
          ↓
         FREE
          ↓
ptr → 0x5000 [available]
          ↓
         reuse
          ↓
ptr → 0x5000 [Alice]

The address did not necessarily change.

What that address represents changed.

That is the heart of CVE-2026-109619.

Final mental model

If you remember only one diagram from this article, remember this one:

PHP2Shell
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼

   CVE-2026-109618              CVE-2026-109619

         OOM                       Request A
          │                            │
          ▼                            ▼
 partial initialization          global reference
          │                            │
          ▼                            ▼
 abrupt error path              memory released
          │                            │
          ▼                            ▼
 broken invariant             dangling reference
          │                            │
          ▼                            ▼
 unsafe cleanup                  Request B
          │                            │
          ▼                            ▼
 memory corruption             same worker
          │                            │
          │                            ▼
          │                      Use-After-Free
          │                            │
          └──────────────┬─────────────┘
                         │
                         ▼
                memory corruption
                         │
                         ▼
              exploitation primitives
                         │
                         ▼
                        RCE

The vulnerabilities look complicated because their exploitation involves PHP internals, allocators and heap behavior.

But their underlying ideas are surprisingly simple:

CVE-2026-109618: PHP can be interrupted while building something and later behave as though that thing was safely completed.

CVE-2026-109619: PHP can retain a reference to something after that thing has already been destroyed.

Those two mistakes — using something before it is safely valid and using something after it is no longer valid — are fundamental classes of memory-safety problems.

Understanding them provides much more value than memorizing these two CVE numbers: the same concepts appear repeatedly across browsers, operating systems, network services, interpreters and security vulnerabilities.