Black Hat USA 2026 · Briefings

Burning Tears of
PHP's Memory
Hardening

A fully remote, generic exploit path that survives PHP's newest heap defenses, from one constrained byte.

Yifan Wu · Xiaochuan Yu · Zhiyun Qian · UC Riverside · UC San Diego

This research is 100% LLM-free.

(except for making these slides)

nebula@blackhat: ~/talks/burning-tears

nebula@blackhat:~$ whoami
Frank Wu · Nebula Security
Hacking Linux and Android
Xiaochuan Yu · Nebula Security
Hacking XNU and Browsers
nebula@blackhat:~$ cat recent_work.md
▹ first public nginx RCE · remote, ASLR bypass, generic config
▹ world’s first Android 17 root (GhostLock) · one URL, full device control
▹ first public Android browser → kernel full-chain (IonStack) in 7 years
nebula@blackhat:~$ ./burning_tears.sh --target=php --remote

Securinets CTF quals 2024, the I HATE PHP challenge thread

Thank you Securinets CTF 🥰🥰

1

The CTFAn ordinary PHP challenge.

2

The 0‑dayA real flaw. PHP patched it.an unplanned side‑find

3

The real questionOne defense cracks, all four?

Browser pwn

for(let i=0;i<0x4000;i++){
		foo(true);
}
new ArrayBuffer(0x7f00000);

Kernel pwn

for(int i=0;i<N;i++)
	msgsnd(qid[i],&msg,size,0);

PHP remote

POST /upload.php HTTP/1.1
Host: victim.tld
Content-Length: 8192

data=%00%02%be%ef...

Shadow Pointer

An encrypted copy of every freelist next, re-checked on each allocation.

✕ freelist poisoning

Unlink Prevention

Safe-unlink fd/bk checks on the doubly-linked chunk list.

✕ list-forgery writes

RO Metadata

Allocator hooks in zend_mm_heap made read-only at runtime.

✕ metadata hook hijack

Heap Isolation

Request data ($_GET/$_POST) moved to a separate heap zone.

✕ raw-request spray

~~CVE-2024-2961~~ ~~CVE-2022-31626~~ ~~public CTF chain~~

Aimed at the exact techniques every public PHP exploit relied on.

Each new defense closes exactly one classic technique
freelist, metadata, and raw spray all gone.

PART I

The playing field

How PHP allocates, and why that lets us shape the heap at all, remotely.

Fresh chunk each request, best-fit + LIFO, no cross-request state,
so identical requests build identical heaps.

Anything (raw bytes)

Spray attacker-defined raw memory the interpreter will later trust.

Anywhere (placement)

Put a chosen object at any offset next to the victim, in one request.

Both are hard under the new defenses.
Earning them back is the rest of the talk.

Every step lives in built-in PHP objects, never the allocator, never app classes.

II

Index Forgery

Turning the weakest possible bug, one constrained byte, into a strong primitive.

1-byte overflowvalue constrainedno OOB read

The nightmare bug, yet enough. Works here means it works for almost anything stronger.

Every PHP value is 8 bytes plus a type tag. Control a zval, and you control what PHP believes memory is.

zend_array (HashTable)

+0x00

gc · refcount

+0x0c

nTableMask

+0x10

arData → butterfly

+0x18

nNumUsed · size

+0x38

pDestructor · hijack target

arData is a butterfly

A separate allocation the overflow reaches. arData points to the split: index array on the left half, buckets on the right.

idx

Bucket[0]

Bucket[1]

← index grows | arData → buckets grow →

A zend_array reads from a separate arData buffer, index array in front of the buckets.

hash(key) | mask → a slot → the integer there picks the Bucket. PHP never doubts that integer.

The overflow lands on index[0], not a pointer, just a small integer. One byte moves it far.

A large index reaches memory we sprayed, a fake Bucket holding a fake zval we control.

PHP re-checks the bucket key and hash. We forge a match with the reversible DJBX33A hash, and the lookup passes.

Mark the fake zval refcounted, and a plain read/write does ++ / -- through your pointer, at any address.

Why limited

The value pointer is sprayed as a string, encoding-restricted. We control only its low bytes.

So ++/-- lands near a chosen spot, not anywhere.

value = 0x…??

low-byte overlap

→ nearby sprayed memory

One extra indirection

Steer the constrained value at the type_flags of another zval in a sprayed array.

++/-- on a type tag → make any zval refcounted → decrement anywhere.

fake zval.value ─┐

low-byte steer

└→ zval.type_flags

limited ++/-- → arbitrary ++/--

The out-of-bounds access lands on a fake Bucket that is mostly uninitialized (UBI), only the low bytes of value are string-written; its key is dereferenced into a freed string (UAF), and steering that value pointer gives IF, an arbitrary decrement anywhere.

Different bugs, one waypoint. OOB via Index Forgery and UAF both reach a controlled zval, then run the same ZOP.

III

ZOP

Zend-Oriented Programming, the interpreter's own structures become the gadget set.

From one primitive, everything

arbitrary ++/-- → leak · probe · hijack

Leak

flip a type tag, PHP prints the pointer

Probe

++/-- as an oracle to defeat ASLR

Hijack

a destructor pointer you control

No OOB read. Flip a string zval to a double and the same bytes come back as a number in the response.

The heaps sit near known code, zend_heap by libc, FPM_heap by php-fpm, so we probe from an anchor until a page faults (502).

A forged array\'s refcount hits zero, PHP calls its destructor, and we control both the function and its argument.

IV

Doing it remotely

Everything so far needs a heap layout, built in one shot, with no raw bytes allowed.

Raw request fields are walled off, but the objects the app decodes from them land on the app heap, right where the bug is.

{ "k": "A"*0x3000, "k": "B"*0x4000, "k": target, "k": null }

Each value is allocated, all-but-one freed, an alloc/free script inside one request.

A packed, integer-keyed array stores a flat run of zvals.
Set each value → spray any 8-byte pattern.

0xdeadbeefdeadbeef

0x4141414141414141

0x0700000000000001

…

V

End to end

One real CVE, one constrained byte, fully remote, from HTTP request to shell.

CVE-2024-2961

glibc iconv OOB via a normal PHP app. In practice: one byte, value pinned to 0x48–0x4D.

All four defenses on. No recon request.

Where the work lives

The victim app is a few lines. The exploit is a heap program encoded entirely in one JSON body.

buildspray fake bucket + zvals

placepage-level fengshui

forge1-byte IF → fake zval

triggerdestructor → pc(arg0)

Leak, layout, and hijack all fold into a single HTTP body, there is no second request.

VI

Does it hold up?

Real CVEs, all defenses on, measured for reliability, not a one-off crash.

Target

Goal

Old

Ours

Reqs

Success

CVE-2024-2961

RCE

✗

✓

246

100%

CVE-2022-31626

RCE

✗

✓

285

100%

CVE-2019-6977

SBE

✗

✓

2

100%

CTF Case A ("I hate php" from SecurinetsCTF)

RCE

✗

✓

3

100%

CTF Case B ("php master" from N1CTF)

RCE

✗

✓

371

100%

Old public exploits: dead under hardening.
Rebuilt with IF + ZOP: revived, under 300 requests, 100% over 100 runs.

Already merged & effective: Shadow Pointer · Unlink Abuse Prevention, they forced attackers off freelist poisoning

prototype

Read-only Metadata

Metadata falls, but by then the write is already strong, and the ASLR probe exposes writable structs anyway.

verdict: limited

in development

Further Heap Isolation

Per-type dedicated heaps disrupt remote page-level shaping, the assumption our whole path rests on.

verdict: strong

proposal

Guard Pages

Fixed-size gaps do little here. A randomized variant injects real page-level entropy.

only if randomized

proposal

Freelist Randomization

Reorders slots in a freelist, but page-level spraying still walks past it.

verdict: partial

Isolation + randomization move the needle. Metadata protection helps least.

Patch-hashtable

Check the index stays within num_used. Kills Index Forgery at the source.

0.17%

overhead

Patch-refcnt

Validate the target is an aligned zend_refcounted on the PHP heap. Kills arbitrary ++/--.

8.86%

overhead

What PHP got right

Good freelist hardening. Attackers are forced off the allocator.

What's left

Built-in objects and decoder-driven layout.

If you want a common defense, harden all common paths.

Generic object hardening

Object isolation

Randomization

If you want a common defense, harden all common paths.

Generic object hardening

Object isolation

Randomization

github.com/GhostFrankWu/
PHP-security-research

THANK
YOU

PHP's hardening moved the bar. We showed where it still needs to go, and shipped two fixes toward it.

Burning Tears of PHP's Memory Hardening
Yifan Wu · Xiaochuan Yu · Zhiyun Qian
Artifact + Docker: one-click reproduction
Black Hat USA 2026 Briefings

Burning Tears ofPHP's MemoryHardening

Two researchers, one lab.

It started with a CTF.

One request. That's all you get.

Browser pwn

Kernel pwn

PHP remote

How you used to pwn PHP.

Then PHP fought back.

Shadow Pointer

Unlink Prevention

RO Metadata

Heap Isolation

The old exploits died.

The playing field

Same request, same heap.

What fengshui buys us.

Anything (raw bytes)

Anywhere (placement)

So we stopped touching the allocator.

Index Forgery

One byte in.

Meet the zval.

The real target: arData.

zend_array (HashTable)

arData is a butterfly

A normal lookup.

A normal lookup.

One byte, one redirect.

One byte, one redirect.

Make the fake pass.

Now you own a zval.

But the pointer is constrained.

Why limited

Lift to arbitrary.

One extra indirection

One corrupted index. Four primitives.

OOB and UAF meet here.

ZOP

The interpreter is the gadget set.

From one primitive, everything

Leak

Probe

Hijack

Let PHP print the pointer.

ASLR → just probing.

Hijack via a destructor.

Doing it remotely

Isolation has a gap.

Duplicate keys = a heap script.

Integer arrays are a raw memory editor.

End to end

One real bug, fully remote.

CVE-2024-2961

Where the work lives

Build, place, trigger. Once.

Quick demo.

Does it hold up?

We revived the dead CVEs.

The roadmap, graded.

Read-only Metadata

Further Heap Isolation

Guard Pages

Freelist Randomization

The smallest fix.

Patch-hashtable

Patch-refcnt

Good hardening works.

What PHP got right

What's left

Good hardening works.

THANKYOU

Burning Tears of
PHP's Memory
Hardening

THANK
YOU