The Execution Boundary. Where a request ends.

Research brief

Recent PHP disclosures make this problem concrete. CVE-2026-109618 describes out-of-memory interruption leaving invalid state for cleanup; CVE-2026-109619 describes worker-retained references to released request memory. Null Breach investigates a structural response: prevent request-owned references from surviving their lifetime, rather than relying on every failure path to reset them correctly. Published PHP security updates remain the immediate protection; ZR-41 is not a verified fix for either CVE.

The intended benefit for users is a safer web built on stronger execution boundaries. Server-side isolation is only one part of that goal: it does not establish that a destination is trustworthy, block phishing or malware, or make browsing anonymous. The current terminal retrieves sources; it does not isolate destination pages or certify them as safe. A site's use of PHP alone is not evidence that it is vulnerable.

PHP's request model is one of the reasons it has lasted. A request arrives, a script runs from the top, and when the response is sent, the engine discards what the script built. For decades this shared-nothing rhythm has hidden a great deal of complexity: developers rarely think about lifetimes, because the end of the request is a universal answer to the question of when something goes away.

That answer is less universal than it looks. Persistent connections, opcode caches, long-running worker servers, preloading, and native extensions with their own global state all stretch the boundary between one request and the next. Each mechanism is reasonable in isolation. Together they mean that "the request ended, so the state is gone" is a property the deployment has to maintain, not a property the language guarantees.

PROTOCOL ZR-41 is the name we use for a design study that makes that boundary a first-class object. Its runtime concept, the Vessel Engine, would execute PHP-compatible programs after lowering them into ZIR, the Zero Intermediate Representation, where every operation that touches memory or the outside world says so explicitly. None of this exists as a shipped runtime. The pages in this series describe the design, its assumptions, and how it could be evaluated honestly.

Language versus implementation

It helps to separate two things that are often discussed as one. PHP the language is the observable behaviour a program can rely on: how values compare and convert, how arrays copy, what references alias, when destructors run, what exceptions propagate, which warnings are raised. PHP the implementation is the reference engine that produces that behaviour: its value representation, reference counting, allocator, executor, and the extension API through which C code joins the process.

Most compatibility questions are about the first. Most lifetime and memory-safety questions are about the second. A different execution foundation is only interesting if it can preserve the first while changing the second, and the hard part is that a surprising amount of the language is defined by what the implementation happens to do. Destructor timing follows from reference counting. Copy-on-write is invisible until a reference forces separation. Error messages, warning order and the exact point at which a coercion fails are all observable, and real applications and test suites depend on them.

So the research does not start from "rewrite PHP in a safer language". It starts from a list of observable behaviours, asks which of them depend on implementation choices, and asks what a bounded, explicit design must do to reproduce each one.

Mutable state and aliasing

PHP values look simple: scalars, strings, arrays, objects, and resources. Underneath, arrays are value types with copy-on-write sharing, objects are handles to shared mutable instances, and the & operator turns a variable slot into a reference that several names can update. A single function can mix all three.

Aliasing is where intuition breaks. A by-reference foreach leaves the loop variable bound to the last element after the loop finishes. An array that contains a reference keeps that slot shared even when the array itself is copied. Static variables and class statics hold state across calls within a request, and in a worker model they can hold it across requests unless something resets them. Any design that wants to say "this request owns this memory" must account for every route by which two names can reach the same mutable cell.

Lifetime boundaries

The reference engine frees most values deterministically when their reference count reaches zero, and collects cycles separately. Destructors are therefore observable events with an order. A design that changes the memory strategy, for example to region allocation released at request end, has to decide what happens to destructors that the original program expected to run mid-request, and must reproduce that timing where programs depend on it.

Error unwinding

Exceptions unwind frames, run finally blocks, and release locals on the way out. Fatal errors terminate the script but still run shutdown functions and, in many cases, destructors. Each of those paths can touch files, sockets and buffers. An execution layer must define what remains valid during unwinding and what must already be released, or teardown becomes a second, less tested program.

Native extensions

Much of what PHP applications use every day is written in C: database drivers, image processing, compression, cryptography, internationalisation. Extensions share the address space and can hold global state, cache pointers, or allocate memory outside any request's accounting. They are the largest region of the system that a design in this space cannot simply reason about, and it is more honest to draw a boundary around them than to pretend they fit inside a proof.

Cleanup and long-running workers

In a classic deployment, process recycling and per-request teardown cover a lot of mistakes. Worker-mode servers change the trade-off: the application boots once and serves many requests, which removes bootstrap cost but makes every global, static and singleton a potential carrier of state from one visitor's request into the next.

Frameworks that support worker mode add reset hooks, and operators add limits such as restarting a worker after a fixed number of requests. These are practical mitigations, but they are conventions. Nothing in the execution model distinguishes request-owned state from process-owned state, so the correctness of the reset depends on every library cooperating.

Null Breach treats this as a design input. If request-owned memory is a distinct region with a known owner, the runtime can invalidate it as a unit. If process-wide state must exist, it should be immutable after boot or reachable only through a service with an explicit interface. Cleanup stops being a hope and becomes an operation with a defined cost.

The Sealed Execution Contract

The Sealed Execution Contract is the small set of properties every other part of ZR-41 is designed to serve. It is phrased as obligations on the runtime, not on application authors.

1. A request owns its mutable execution region. Every mutable value a request creates lives in a region associated with that request. No other request can obtain a mutable path into it.
2. External effects require explicit authority. Reading a file, opening a socket, querying a database or reading the clock happens only through a capability the request was granted. Without the capability the effect does not occur, and the program observes a defined failure.
3. Termination invalidates request-owned resources. When a request completes, fails, is cancelled or exhausts its budget, its region, handles and capabilities become invalid together, and release is bounded in time.

The contract deliberately says nothing about performance and nothing about which PHP features are supported. Those are separate questions, answered on the compatibility matrix. What it fixes is the shape of every other decision: if a feature cannot be implemented without breaking one of the three clauses, the design must either confine it behind a service, mark it unsupported, or state precisely where the clause stops applying.

What this research does not claim

• It does not claim that a Vessel Engine exists, runs PHP applications, or is faster or safer than any shipping PHP runtime.
• It does not cite or rely on specific vulnerability reports. The motivation is structural: lifetimes, aliasing and ambient authority are hard to reason about in any large native runtime.
• It does not claim that writing an engine in a memory-safe language yields PHP compatibility, or that it removes the need to trust native extensions.
• The NULL TERMINAL on this site is a web-search tool for reading sources. It does not implement any property described here.

Continue with From Source to Sealed Operations for the pipeline, or Authority Has a Lifetime for the boundary design.