A Critical PHP Vulnerability Does Not Run on This Site

A critical PHP vulnerability is what operators searched on October 21, 2026, after the PHP project moved an emergency release forward by a day. Two bugs in the interpreter, each scored 9.2, can lead to remote code execution. On Apache with mod_php, one of them was shown to run code from an unauthenticated request, before application code. This page is the house account of that release: what failed, why a remake in Rust does not carry that interpreter, and what dldeploy.com and the MATA home computer actually run instead.

The primary note is the PHP Foundation's account of the release. The language this site is built in is Rust. The crates are the Janus family at Remade With Rust. The computer a local device is aimed at is Home on MATA.

What the critical PHP vulnerability is

Both bugs sit in machinery almost every PHP request touches: memory management and error handling. They are tracked as CVE-2026-109618 and CVE-2026-109619. The project rates each at 9.2. A leaked score of 10.0 was wrong. The coordinated release had been set for October 22. On October 20 the identifiers began circulating with a wrong clock time, so the project published early and shipped the fixes at 14:00 UTC on October 21.

Two ways a worker keeps bad state

The first bug is an out-of-memory path. If a request hits memory_limit at the wrong moment, PHP can leave internal data only partly initialized and later treat it as valid. On Apache with mod_php, the project says an unauthenticated request can reach that before any application code runs, and that code execution was demonstrated with default settings. The same class of execution was also shown on PHP-FPM through application code.

The second bug is leftover state. A fatal error at the wrong point can leave a worker pointing at memory that belonged to a previous request. A later request on that same worker can use it. A use-after-free and a worker crash were confirmed, and code execution was demonstrated against a real application on Apache with mod_php. A critical PHP vulnerability of this shape is serious because the next request is not the attacker's request. It is whoever the worker handles next.

Who still has to patch

The fixes are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Everything from PHP 5.4 through 8.5.11 was in scope. PHP 8.1 and older are end of life and did not receive a project fix. A host that cannot move those lines is still carrying the critical PHP vulnerability. Reports on October 21 said exploitation attempts were already hitting sensors, after a short video of a proof of concept circulated and was pulled. This page stops at that impact. It does not repeat the steps.

Why a remake in Rust is the difference

The bugs are in a C interpreter that keeps request memory alive across a worker's life. Remade With Rust is the house that writes the replacement software in Rust, where that interpreter is not the runtime. dldeploy.com is one of the things already built that way. The pages are prerendered by a Rust program. nginx serves the files. A request for a Learn page does not enter PHP, so the critical PHP vulnerability has no object here.

The page a visitor receives

The production image is nginx with a folder of HTML, CSS, and images copied in at build time. There is no PHP module in that image. There is no FastCGI socket to a PHP pool. The Learn index is those files. A critical PHP vulnerability needs a PHP worker to mis-handle. A static file does not have a memory_limit, a request arena, or a worker that recycles another visitor's state.

That is a narrower claim than "Rust cannot be broken." It is the claim the deploy matches. The same pattern is why a pure Rust alternative to the cloud refuses to be a skin on someone else's application server. The device path and the site path are both meant to be code this house can read.

What Rust does not close

A critical PHP vulnerability is a memory bug in C. Rewriting a website in Rust removes that interpreter from the website. It does not remove every C dependency on every board. Janus firmware that has run on the bench still sits on ESP-IDF. The radio blob is Espressif's. A logic bug in Rust still ships as a logic bug. The honest line is the one in the image: this origin does not run PHP. A household that also runs WordPress, or any other PHP app, on some other host is still on the patch list above.

What the home computer is doing instead

The MATA home computer is not a PHP application with a plugin directory. A board minted with rusty_esp_mid carries a did:mata. It joins the LAN and speaks the protocol Home already uses to list a device, described in the MATA Home integration. Sign-in on this site is a wallet signature checked locally, written up as sign in with MATA. None of those steps load the PHP interpreter the critical PHP vulnerability is about.

A device, not a script runtime

The home computer's job, on MATA, is the household: adopt a device, keep the key with the owner, stay on the LAN. That is a different failure domain from a shared PHP worker. One visitor's request cannot leave stale interpreter state for the next visitor, because there is no interpreter. The Connect vision is the mesh half of the same idea. The pages are files.

The limits that stay

The home computer's media view is not wired to a Janus stream yet. Reach from outside the house is written for some boards and not measured. Development firmware can still keep a device key in a plaintext partition. Those are real gaps. They are not the critical PHP vulnerability, and they are not fixed by pretending the site runs a patched PHP. Operators who do run PHP should move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or off the end-of-life lines. This origin's protection is simpler: the worker those bugs need is not in the building.