The two bugs are CVE-2026-109618 “RCE via OOM corruption” and CVE-2026-109619 “RCE via stale global state”. We’ll walk through how they work, down to the source lines, and then answer the question we kept asking ourselves while reproducing this in the lab: why did this class of bug exist in PHP for two decades before anyone could turn it into a pre-auth RCE?

Background: how PHP runs a web request

Both bugs only make sense once you hold three facts about PHP’s execution model in mind at once. None of them is exotic, they’re just rarely stated together.

First, a web request has a strict lifecycle. The SAPI (mod_php, FPM, cgi) accepts a connection and calls php_request_startup(): extensions get their RINIT, output layers activate, and critically the request body is parsed, before any application code runs. The script executes, then php_request_shutdown() tears everything down. On the happy path this cycle is airtight: startup completes, shutdown cleans up, in that order.

Second, workers are long-lived but requests are not. A mod_php child or FPM worker serves thousands of requests in one process lifetime. At every request boundary the request heap: every emalloc‘d string, array, object of that request is freed wholesale. But the process’s global state (executor globals EG, session globals PS, core globals PG) persists across requests. Anything that stores a request-heap pointer into one of those globals creates a pointer that outlives the memory it points at, unless something resets it in between. Normally, something does.

Third, memory_limit is enforced by unwinding, not by refusing. PHP’s allocator (ZendMM) tracks every request allocation against a per-request cap. When the cap is hit, the engine doesn’t return an error code to the caller: it aborts the request by jumping. The jump mechanism is zend_bailout(), the longjmp() half of PHP’s zend_try/zend_catch error-control flow, which has been the engine’s answer to “C has no exceptions” since the PHP 4 era. An abort can therefore land at essentially any allocation site in a million lines of C, including, as it turns out, in the middle of request startup, where the state being built is reachable from shutdown but not yet valid.

Hold those three together: a lifecycle that assumes orderly startup-then-shutdown, globals that outlive requests, and an abort that can fire anywhere, then you can see the shape of the problem before we name the CVEs: if the abort fires during startup, the orderly part of the lifecycle never happens, but the globals and the shutdown code still do.

What the two CVEs are…

CVE-2026-109618, the longjmp problem: When PHP exhausts its memory_limit, the allocator historically raised a “safe error”: it printed a fatal error inside a zend_try { } block and then called zend_bailout() , which is a longjmp(), zend_mm_safe_error. A longjmp out of a context that was mid-initialization leaves that context’s memory half-built. And if the request gets shut down anyway, the shutdown code walks that half-built state as if it were valid. On Apache mod_php, that’s exactly what happens: the request shutdown routine runs unconditionally, even when request startup failed.

CVE-2026-109619, the stale global problem. PHP workers are persistent: one process serves thousands of requests, and its global state (executor globals, session globals) survives between them. Some operations publish request-owned pointers into those worker globals and some operations consume them before the next request’s normal initialization would have replaced them. If a fatal error interrupts that publish-and-reset dance, the global keeps pointing into memory that’s already been freed with the request. The next request that touches the global, before initialization, dereferences freed memory: a use-after-free whose contents an attacker can reclaim. The mental model that finally made this click for us: the bug doesn’t live in one request. It lives between two requests, carried by a worker’s globals.

The bug in code

Three functions carry the whole bug. The first is the allocator’s OOM handler, the mechanism behind the abort we just described. This is the old handler, removed by the patch:

static ZEND_COLD ZEND_NORETURN void zend_mm_safe_error(zend_mm_heap *heap,
	const char *format, size_t limit, /* ... */ size_t size)
{
	heap->overflow = 1;
	zend_try {
		zend_error_noreturn(E_ERROR, format, limit, /* ... */ size);
	} zend_catch {
	} zend_end_try();
	heap->overflow = 0;
	zend_bailout();          /* <-- longjmp out of the current context */
	exit(1);
}

src/php-8.5.11-src/Zend/zend_alloc.c:395-420

The bug is in the control flow, not in any single line. The function raises a fatal error through PHP’s error machinery, which itself allocates memory, hence the heap->overflow guard, and then calls zend_bailout(), the longjmp() from the background section: an unwinding jump to whatever zend_try frame is nearest. The implicit assumption is that any context reaching OOM can safely unwind from that point. For most contexts, that holds. For request startup, it doesn’t, and the chain section shows exactly who trips over the wreckage.

The patch replaces this with a delayed OOM (record the error, raise a flag, let the VM handle it at the next safe point) and a hard limit that simply terminates:

/* new in 8.5.12: soft OOM is deferred, not unwound */
EG(delayed_oom).message = zend_string_init(buf, strlen(buf), true);
EG(delayed_oom).state   = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);   /* handled at safe point */

/* new in 8.5.12: hard limit kills the process instead of unwinding */
_exit(137);

src/php-8.5.11-src/Zend/zend_alloc.c

No longjmp, no half-built state for shutdown to trip over. The error still gets reported, it’s just no longer delivered by jumping out of whatever the engine was mid-way through.

The second function is the consumer side of the stale-state bug, one layer up in the session module. It’s the code that dereferences one of those dangling worker globals, before the next request’s initialization would have replaced it:

static void php_session_track_init(void)
{
	zval session_vars;
	zend_string *var_name = ZSTR_INIT_LITERAL("_SESSION", 0);
	/* Unconditionally destroy existing array -- possible dirty data */
	zend_delete_global_variable(var_name);

	if (!Z_ISUNDEF(PS(http_session_vars))) {
		zval_ptr_dtor(&PS(http_session_vars));   /* <-- stale pointer */
	}
	/* ... */
}

src/php-8.5.11-src/ext/session/session.c:253-262

The comment even hints at the hazard “possible dirty data” but the code only guards against stale arrays, not against the pointer itself being stale. PS(http_session_vars) is a worker global; after the abnormal request death it points into the freed request heap, and zval_ptr_dtor runs on it anyway. That’s the exact instruction our gdb session caught freeing a live $_POST key string.

The third is the 8.5-specific producer/consumer pair in Zend/zend.c, the same shape in a different subsystem. PHP 8.5 made fatal-error backtraces default-on, and that convenience feature stores request-owned data in a worker global:

/* producer: any fatal error stores a request-owned backtrace
   into a WORKER global (8.5 default: fatal_error_backtraces=1) */
} else if (EG(fatal_error_backtrace_on) && (type & E_FATAL_ERRORS)) {
	zend_fetch_debug_backtrace(&EG(last_fatal_error_backtrace), 0, ...);
}

/* consumer: the NEXT error report — fatal or not — drops it */
zval_ptr_dtor(&EG(last_fatal_error_backtrace));
ZVAL_UNDEF(&EG(last_fatal_error_backtrace));

src/php-8.5.11-src/Zend/zend.c

Producer and consumer, three lines apart in the same file; and 8.5.11 never resets the global at shutdown. The 8.5.12 patch adds the reset with a comment that reads like a confession: “may be used by zend_error_zstr_at before init_executor”. When the fix’s own comment describes the bug, you know the maintainers understood exactly what they were closing.

How it works: the chain, stage by stage

Everything hinges on one constraint, easy to miss in prose: the producer and consumer requests must land on the same worker, that’s what turns two harmless-looking requests into one use-after-free.

Stage 1. Making PHP run out of memory without breaking any rules

Every PHP install has two size limits for incoming data. post_max_size (8 MB by default) caps how big a request body may be, and memory_limit (128 MB by default) caps how much memory PHP may use while processing it. The trick is to blow past the second without ever tripping the first and the advisory describes three ways to do it, all of which we confirmed in source and in the patch’s own regression tests.

The first exploits a bookkeeping gap. post_max_size is checked against the Content-Length header, the number the client declares. A request sent in chunks (HTTP “chunked” encoding) simply has no such header, so the check passes and PHP keeps reading whatever shows up. We’ve watched real servers happily parse chunked bodies this way.

The second is a compression trick. One part of a multipart form may carry an effectively unlimited number of header lines. Each line costs about 12 bytes on the wire, but inside PHP each one becomes a copied key, a value buffer, and a linked-list entry, roughly eight times the space. So 19 MB of wire headers is enough to exhaust the default 128 MB memory limit. The patch added a regression test for exactly this scenario.

The third rides a PHP feature most sites never use: upload progress. When it’s on (the default), every file in an upload makes PHP decode and re-encode the entire session, thousands of times over for a large upload, until memory runs out [V].

The result looks like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 4096 bytes) in Unknown on line 0

The telling part is in Unknown on line 0: no script was running. PHP died before the application even started; the memory ran out while PHP was still reading the request. The first time we saw that line come back from a server we didn’t build, it was a strange feeling: the machine is telling you, in its own error format, that you’ve exhausted it before its code even woke up.

Stage 2. The cleanup that shouldn’t happen, but does

When PHP aborts a request mid-startup, what happens next depends entirely on the web server setup and this is the pivot of the whole exploit:

• Apache with mod_php runs its normal end-of-request cleanup anyway, even though startup failed. That cleanup now walks over data that was only half-built.

• PHP-FPM does the opposite: the worker process simply exits, taking the broken state with it. Nothing dangerous survives.

• php-cgi behaves like FPM.

That’s why the vendor rates mod_php highest, and why the generic, works-anywhere exploit is a mod_php exploit. FPM can still be exploited, but only through the second bug’s application-phase path (below).

Stage 3. The worker remembers things it shouldn’t

Here’s where the second bug comes in. PHP workers are long-lived: one process handles thousands of requests, and some of its internal bookkeeping: session data, IDs survives between them. During request startup, PHP’s upload-progress feature writes a few pointers into that long-lived memory: where this request’s session data lives, what its session ID is. Normally, cleanup wipes those pointers at the end of the request. On PHP 8.5 there’s a second way in: any fatal error saves a debugging backtrace into the same kind of long-lived storage.

Stage 4. The cleanup that never runs

The cleanup that would erase those pointers never gets its chance. The abort happened before the parser could signal “request finished,” and the session module’s shutdown routine doesn’t run because extensions were never activated. So mod_php frees all of the request’s memory and the worker’s long-lived pointers now aim at memory nobody owns anymore. That’s the whole bug in one sentence.

Stage 5. The next request stumbles into the trap

The attacker sends a second, ordinary-looking request to the same worker. It only needs two ordinary form fields: no files, no oversized anything. Because of how PHP processes uploads, this request touches those stale pointers before the normal startup code would have replaced them. The engine dereferences memory that was freed one request ago.

Watching it happen

This is where we stop summarizing the advisory and show what we saw ourselves. We built a lab based on PHP 8.5.11, mod_php, a single worker, completely default settings and attached a debugger. The stale pointer didn’t point at garbage. It pointed at memory the next request had already reused for its own data, specifically, the name of one of its form fields. PHP then “cleaned up” that pointer anyway, freeing memory the running request was actively using. Seeing that in a debugger was the moment the advisory stopped being abstract.

You don’t even need a debugger, the corruption is visible over plain HTTP. After the two requests, the server’s response contains fragments of raw memory: internal headers, addresses, leftover bytes. That’s an information leak, delivered in the response body.

Two properties make this practical rather than theoretical. First, PHP’s memory manager restarts each request from the same memory layout, so the corruption reproduces identically run after run. That determinism surprised us; we expected heap exploitation to be flakier. Second, the attacker can choose what lands in the freed memory: by shaping the form fields of the second request, we made the leaked bytes spell out our own marker strings . The advisory’s “strategically crafted heap layout” is exactly this.

Detection

If you’re defending PHP infrastructure, here’s what to watch:

1. Log signature (precondition firing). Allowed memory size of ... in Unknown on line 0 showing up at request startup, especially if it repeats, means someone is exercising the CVE-2026-109618 precondition against you. We’ve verified this signature is produced by the attack shape above on vulnerable builds.

2. Configuration exposure. The patch’s own regression tests enumerate the risky settings: session.upload_progress.enabled=1 (default-on, the pre-init consumer), finite memory_limit with default post_max_size (the controllable abort), and on 8.5 fatal_error_backtraces=1 (the backtrace producer/consumer pair). Any of these on an unpatched, internet-facing stack is exposure.

3. Runtime (post-exploitation). The end state of this exploit class is a webshell: alert on PHP worker processes (php-fpm, httpd, apache2, php-cgi) spawning shells, interpreters, or download tools, the Huntress/Florian Roth process-watcher pattern.

Why it survived for two decades

The reachability of this class is an intersection: a SAPI that mishandles failed startup (or an app-phase fatal), a default-on pre-init feature, a heap layout an attacker can shape, and a consumer that fires before initialization. Remove any one and the bug is a crash or a leak, not RCE. Fuzzers struggle with it precisely because the state spans two requests on the same worker, the php-src fuzzer SAPI exercises single requests. And the people best positioned to find it (Stefan Esser’s 2007–2010 era of engine-level UAF research) moved on; the 2017 policy decision to stop treating unserialize() bugs as security issues tells you where the community’s attention went instead, away from engine-internals memory corruption.

Why now? In Project Zero’s RCA template terms “thoughts on how this vuln might have been found” the honest answer has three parts. First, the fuzzer blind spot: the vulnerable state spans two requests on the same worker, and php-src’s fuzzer SAPI exercises single requests, so coverage tooling structurally misses it. Second, variant analysis: the bug class (producer publishes request-owned state into worker globals, interruption skips the reset, consumer fires pre-init) is enumerable once someone names it, the session-upload-progress and fatal-backtrace pairs are instances of the same shape. Third, the reporter credits on the advisories lcfr-hax, sagitzadik-wiz (Wiz), tomash-areion, amyb-oai alongside Calif.IO’s published “Month of AI-Discovered Bugs” methodology, suggest the discovery cost of this bug class just dropped. The bugs were always there; the search changed. We’d put money on more engine-level UAFs surfacing this way in the next couple of years, not because PHP got worse, but because looking got cheaper.

It started with a bug report that led somewhere unexpected.

Our AI had flagged something in GStreamer’s MIDI parser. Valgrind was reporting invalid memory reads. The pipeline was dying with “Internal data stream error.” We had found something worth investigating.

The First Report

We filed a confidential security report to GStreamer: “MIDI Parser Buffer Overflow.” Within hours, one of the core maintainers responded.

“That’s not a crash but expected error behaviour on a broken file,” they wrote. “I can’t reproduce this here. There’s no OOB read with git main or 1.26.8.”

Interesting. The latest version seemed clean. But then they added something that caught our attention: “Also there are clear possibilities for OOB reads in the code though, none of which should be triggered by your exploit file. I’ll provide a fix for those later here.”

They couldn’t reproduce our specific issue on the latest version, but they’d spotted other potential bugs while reviewing the code.

Down the Version Rabbit Hole

We went back to our test environment. Something wasn’t adding up. We ran the same exploit against different GStreamer versions:

• 1.24.2 (shipped in Ubuntu LTS): Valgrind showed OOB reads

• 1.26.0: Valgrind showed OOB reads

• 1.26.8: Clean. No warnings.

The bug was real. It just wasn’t new. Someone had already fixed it between 1.26.0 and 1.26.8.

We reported back with our findings. The response: “The second commit in !8396 fixes the problem here... That fix is included in 1.26.2 and 1.24.13.”

So the bug had been patched upstream six months ago. But here’s the thing: we weren’t testing on bleeding-edge GStreamer. We were testing on Ubuntu 24.04 LTS, the version most people actually use. And Ubuntu 24.04 ships GStreamer 1.24.2, not 1.24.13.

The upstream fix existed. But millions of Ubuntu users were still running vulnerable code.

That was worth digging deeper.

And then came the interesting part.

The Patch That Found More Bugs

The maintainer had attached a patch to our bug report. Not just a fix for the issue we reported, but fixes for other OOB reads they’d spotted while reviewing the code. Our report had prompted them to audit the MIDI parser more carefully.

“Your report at least helped improving other parts of the code,” they wrote.

We decided to test the patch. Could we trigger those “other” OOB reads they’d identified?

Yes. Yes we could.

Within minutes, we had proof-of-concept files that triggered the new vulnerabilities on GStreamer 1.26.8. We shared them back. The maintainer confirmed they worked and that the patch caught them.

“I wonder if you can also get it to read more than 1 byte after the end,” they asked. Challenge accepted.

The Final Count

The back-and-forth with the GStreamer team led us to four distinct Out-of-Bounds Read vulnerabilities:

• CVE-2025-67326: Missing event data length validation

• CVE-2025-67327: Off-by-one error in the variable-length parser

• CVE-2025-67328: Missing boundary check in SysEx event parsing

• CVE-2025-67329: Missing boundary check in meta-event handling

Two of them (67326 and 67327) affect GStreamer 1.26.x and are fixed in 1.26.10. The other two (67328 and 67329) were already fixed in 1.24.13 and 1.26.2, but we requested CVEs anyway because Ubuntu LTS is still shipping 1.24.2.

We’ve published full technical write-ups for each vulnerability, including proof-of-concept scripts you can use to reproduce them:

• https://cve.vyprsec.ai/cve-2025-67326/

• https://cve.vyprsec.ai/cve-2025-67327/

• https://cve.vyprsec.ai/cve-2025-67328/

• https://cve.vyprsec.ai/cve-2025-67329/

Each page includes the exact Python script to generate a malicious MIDI file, the commands to run, and the Valgrind output showing the memory violation.

Why Should You Care?

You might be thinking: “Who even uses MIDI files anymore?”

Fair question. But GStreamer doesn’t care what file you meant to open. If your file manager tries to generate a thumbnail, if your media player scans your library, if any application auto-processes media files, GStreamer’s MIDI parser might get invoked.

GStreamer is everywhere:

• GNOME and KDE desktops

• Media players like Totem and Rhythmbox

• Video editors like Pitivi and OpenShot

• Embedded systems and IoT devices

The attack is trivial: drop a 30-byte file somewhere it’ll get processed. That’s it.

What This Proves

This was a story of persistence and collaboration.

We didn’t stop at the first response. We dug deeper, tested across multiple versions, and when the maintainer shared a patch for related issues, we built proof-of-concept exploits (autonomously) that confirmed the vulnerabilities were real and exploitable. Within minutes…

In the end, we:

• Identified that Ubuntu LTS was shipping a vulnerable version

• Created working PoC exploits for four separate code paths

• Handled the CVE registration process with MITRE

• Published detailed technical write-ups so others can learn and verify

The GStreamer team was responsive and professional throughout. They handled the code fixes. We handled the research, documentation, and disclosure coordination. That’s how security research should work.

The Practical Takeaway

If you’re running Linux, check your GStreamer version:

gst-launch-1.0 --version

Fixed versions:

• 1.24.13 or later

• 1.26.2 or later (1.26.10 for all four CVEs)

As of late December 2025, most distributions haven’t shipped these updates. Track them here:

• Ubuntu: https://ubuntu.com/security/cves

• Debian: https://security-tracker.debian.org/tracker/

• Fedora: https://bodhi.fedoraproject.org/

References

• GStreamer Security Advisory SA-2025-0008: https://gstreamer.freedesktop.org/security/sa-2025-0008.html

• GStreamer Security Advisory SA-2025-0009: https://gstreamer.freedesktop.org/security/sa-2025-0009.html

• Our CVE write-ups with PoC scripts: https://cve.vyprsec.ai

About VyPr AI

We build AI that finds security vulnerabilities. Every report starts a conversation, and sometimes that conversation leads somewhere unexpected.

These four CVEs came from following a trail of clues across multiple GStreamer versions. That’s security research: persistent, collaborative, and always evolving.

Interested in what we might find in your software? Reach out at contact@vyprsec.ai